Sensitive Data in Response

This is a common pattern in APIs built on top of an ORM: a backend serializer takes an entire database record and returns it as JSON, and the frontend simply reads the two or three fields it actually displays, discarding the rest. The bug is that the rest was still sent over the wire. Password hashes, internal status flags, admin notes, and other fields that were never meant to leave the server end up sitting in a response that looks, from the UI's perspective, completely normal, because nothing about the visible interface hints that extra data came along with it.

• REST APIs / GraphQL with ORM-shaped serializers

• Inspect API responses for fields not visible in UI

• No specific payload - observation-based

When authenticated profile available, inspect /api/* responses for fields whose names match sensitive regex (password, hash, ssn, secret, token, apikey, internal, debug). Emit informational findings.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• Many fields named 'token' are user-facing CSRF tokens.
• Filter by content (entropy, length).

Manual Testing Methodology

Here is a systematic approach to identifying Sensitive Data in Response vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Sensitive Data in Response specifically, trigger error conditions deliberately (malformed input, missing parameters, invalid content types) across every endpoint, and diff full API responses against what the client UI actually uses to spot over-fetched fields.

Compare the response against your baseline, looking specifically for stack traces, internal paths, query fragments, or extra object fields appearing in a response that a production client was never meant to receive.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Sensitive Data in Response, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Information disclosure covers a wide range of severity on its own — a verbose error message, a debug endpoint left enabled in production, or an API response that returns more fields than the client needs can each range from a minor hygiene issue to a direct path toward a more serious exploit, depending on exactly what leaks.

Stack traces and debug output routinely reveal framework versions, internal file paths, and database query structure that meaningfully narrow down what an attacker needs to guess for a follow-on attack like SQL injection or a known-CVE exploit. API responses that over-fetch — returning an entire internal object instead of an explicit response schema — have repeatedly leaked fields like internal user IDs, other users' partial data, or feature flags that were never meant to be client-visible.

Because each individual disclosure often looks low-severity in isolation, this class is frequently under-triaged relative to its role as a reconnaissance and chaining primitive in a larger attack.

Prevention and Secure Coding

Preventing Sensitive Data in Response takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Generic errors to the client, full detail server-side only. Return a generic error message and a correlation ID to the client; log the full stack trace and context server-side where the client can't reach it.

Disable debug/development modes in production. Framework debug modes, verbose stack traces, and admin/debug endpoints should be unreachable in a production deployment, enforced by configuration that's verified as part of the deploy process, not just documented.

Explicit response schemas. Define exactly which fields an API response returns rather than serializing an internal model object directly — this prevents new internal fields from becoming externally visible the moment someone adds them to the model.

Strip identifying metadata. Remove version banners, framework comments, and internal hostnames from responses and headers where they serve no client-facing purpose.