Sensitive Information Disclosure via Public Assets

During a web application security assessment, we discovered that the

/app/assets/i18n/en.json endpoint—intended for UI localization—was publicly

accessible without authentication. The file contained far more than

translation strings: it exposed 133+ internal database field names, entity

structures, and business operation labels. A simple curl request returned 40KB

of internal system metadata that directly mapped to the application's data

model.

Escalation to Precision Attacks

Although no user data was directly exposed, the schema disclosure created

multiple escalation paths:

1. The attacker retrieves the public translation file containing field names

like investorId, managerId, amount, currency, externalId, and rolloverId.

2. SQL injection becomes surgical — Blind injection attempts typically have

~10% success rate (guessing field names). With exact schema knowledge, success

rate jumps to ~90%. Attacker crafts: ' UNION SELECT investorId, amount,

currency FROM accountRequestEntity--

3. Business logic vulnerabilities surface — Exposed operations like

skipTransactionFees, skipReturningFunds, and doNotApplyEarlyWithdrawalFee

reveal exploitable workflow bypasses.

4. API enumeration accelerated — Field names hint at API structure:

accountRequestEntity suggests /api/accountRequest/create,

/api/accountRequest/{id}, etc.

In other words, a "harmless" translation file became a complete reconnaissance

package, eliminating the guesswork attackers normally face.

The Flow

Public Asset → Schema Exposure → SQL Injection / Business Logic Abuse

Why This Is Key in Modern Web Apps

- Localization files often contain internal metadata — Developers map database

fields to UI labels, inadvertently documenting the entire schema.

- "Public" doesn't mean "safe" — Static assets are often excluded from

security reviews; attackers know this.

- Schema knowledge is force multiplier — Every subsequent attack (SQLi, IDOR,

parameter tampering) becomes easier with known field names.

- Regulatory implications — Exposing internal architecture may violate GDPR

Article 32 (adequate technical measures) and enable attacks that breach PII.

That's why Sensitive Data Exposure (OWASP A02:2021) and Security

Misconfiguration (OWASP A05:2021) consistently rank as top risks.

Recommended Fix (technical detail)

Require authentication for internal assets

- Sensitive configuration and localization files should not be publicly

accessible:

app.use('/app/assets/', authenticate, (req, res, next) => {

if (!req.user?.isAuthenticated) {

return res.status(401).json({ error: 'Authentication required' });

}

next();

});

Sanitize translation files

- Separate internal field mappings from public UI labels:

// BAD: Exposes schema

{ "accountRequestEntity": { "investorId": "Investor ID", "managerId": "Manager

ID" }}

// GOOD: Generic labels only

{ "labels": { "idField": "ID", "amountField": "Amount" }}

- Keep schema mappings server-side; frontend receives only display text.

Audit all public endpoints

- Enumerate every publicly accessible file: *.json, *.xml, *.yaml, *.config

- Review each for sensitive information: field names, API keys, internal URLs,

business logic hints.

Defense in depth

- Even if schema leaks, parameterized queries prevent SQL injection

- Input validation and WAF rules catch common injection patterns

- Principle of least privilege limits damage from any single exposure