Generation of Error Message Containing Sensitive Information

What the flaw is

This weakness appears when an application turns an internal failure into a message that discloses too much, such as stack traces, file paths, SQL fragments, configuration values, object names, or other implementation detail. The user sees the clue, but the real audience is often an attacker collecting intelligence.

That disclosure can happen in APIs, web apps, batch jobs, authentication flows, or any component that formats exceptions poorly. The issue is not the error itself, but the decision to surface sensitive internals to an untrusted party instead of separating user-facing output from diagnostic detail.

Why exposed errors are dangerous

Verbose errors reduce an attacker’s uncertainty. They can reveal software versions, code structure, environment names, table or field names, dependency behavior, or the exact place where validation failed. Small clues often make later exploitation faster, more accurate, and less noisy.

Even when no direct secret is printed, the response can still help reconnaissance by confirming which paths exist, which controls triggered, or whether a guessed parameter, account, or object ID is valid. Well-known weakness catalogues treat this as a serious information disclosure pattern, especially when the same message appears repeatedly during probing.

How secure systems handle error output

Good practice is to give the requester a generic, stable error and keep the detailed diagnostic record in protected server-side logs. That separation preserves usability while reducing the chance that internal state, credentials, or implementation detail escapes into a browser, client app, or integration response.

Teams usually also standardise exception handling so failures are consistent across services. In application security guidance, this aligns with removing unnecessary detail from runtime messages and treating error content as part of the attack surface, not just a developer convenience.

What defenders review after a disclosure event

When this flaw is found in production, defenders should inspect whether the message exposed secrets, session data, tokens, keys, database details, or enough structural information to support follow-on exploitation. The response should include a review of where the message came from and whether the same pattern exists in adjacent services or environments.

If the error exposed usable secrets or operational identifiers, the incident may require more than a code fix. Rotation of affected credentials, invalidation of sessions, and review of logs for probing or exploitation attempts may all be necessary, depending on what was revealed.

Risk and Threat Considerations

Exposed error content is valuable because it lowers the cost of reconnaissance and can shortcut an attacker’s path to a more precise exploit. A single verbose response can reveal enough internal detail to help with input tampering, injection tuning, access-path discovery, or targeted enumeration.

Failure mechanism: The application leaks sensitive state through exception text, debug output, or framework-generated error pages instead of suppressing the detail before it reaches the client.

Impact: Attackers gain clues that can accelerate exploitation, reveal secrets or environment data, and increase the likelihood of successful follow-on compromise.

Practitioner Guidance

Why practitioners should care: Error handling is a security control, not just a usability feature. If response text is inconsistent across environments, it often means the production path is still exposing debug behavior or unreviewed exception content.

What to watch for: Treat stack traces, raw exception objects, framework error pages, and templated messages as sensitive output until proven otherwise. Route detail to access-controlled logs, and keep the external response generic and predictable.

Related resources from NHI Mgmt Group

• What is the difference between sensitive information disclosure in LLMs and retrieval-augmented generation data leaks?
• What breaks when MCP elicitation is used for sensitive information?
• How can organisations tell whether an AI system is leaking sensitive information?
• How can organisations test whether a chatbot is leaking sensitive information?