Skip to content

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Overview

CWE-200 is the parent category for the information-exposure family: a product reveals data - credentials, PII, internal paths, stack traces, configuration, session tokens, or business logic - to an actor who is not authorized to see it. MITRE marks CWE-200 as discouraged for direct vulnerability mapping because it describes a technical impact (loss of confidentiality) shared by hundreds of more specific weaknesses, rather than a root cause a developer can act on directly. Information exposure is often the first step in a multi-stage attack: reconnaissance data (paths, versions, internal IDs) feeds directly into a later, more damaging exploit.

Relationship to Other CWEs

CWE-200's own parent is CWE-668 (Exposure of Resource to Wrong Sphere) in MITRE's Research Concepts view: the wider family in which a resource of any kind, not just information, reaches a sphere it should not. Go there when what crossed the boundary was a handle, a connection, or a block of memory rather than data a reader can look at. CWE-668 is a router in the same way this page is, so the destination will be one of its children, such as CWE-402 for an inherited descriptor or CWE-732 for permission bits, rather than CWE-668 itself.

Downwards, treat this page as a router, not a fix. If a scanner or manual finding names (or clearly matches) one of the entries below, use its dedicated page instead - the root cause and primary defense differ by mechanism:

  • CWE-200 (this page) - the parent: sensitive data reaching an actor not authorized to see it, with no more specific mechanism named
  • CWE-201 - Insertion of Sensitive Information Into Sent Data (HTTP responses, API payloads, serialized objects)
  • CWE-209 - Generation of Error Message Containing Sensitive Information (stack traces, verbose exceptions)
  • CWE-215 - Insertion of Sensitive Information Into Debugging Code
  • CWE-359 - Exposure of Private Personal Information to an Unauthorized Actor
  • CWE-497 - Exposure of Sensitive System Information to an Unauthorized Control Sphere
  • CWE-532 - Insertion of Sensitive Information into Log File (MITRE files this under CWE-538 in the research view and under CWE-200 only in the simplified mapping view)
  • CWE-538 - Insertion of Sensitive Information into Externally-Accessible File or Directory (a backup, config, or VCS file reachable in the webroot)

MITRE also lists CWE-203 (Observable Discrepancy), CWE-213 (Exposure of Sensitive Information Due to Incompatible Policies), CWE-1273 (Device Unlock Credential Sharing), CWE-1295 (Debug Messages Revealing Unnecessary Information), and CWE-1431 (cryptographic state exposure via hardware module outputs) as further children with no page here yet.

Use this page only when a finding is reported generically as "Information Exposure" or "Sensitive Data Exposure" without a more specific CWE, or as background for understanding what the family has in common.

OWASP Classification

A01:2025 - Broken Access Control

Risk

Low to Critical: The impact depends on what is exposed and to whom:

  • Reconnaissance: attackers learn system architecture, technologies, file paths, and database structure, which shapes later attacks
  • Credential and secret theft: exposed passwords, API keys, or tokens lead directly to account or system compromise
  • User enumeration: distinguishing "valid user, wrong password" from "no such user" lets an attacker build a target list
  • Privacy and compliance impact: direct exposure of PII, financial data, or health records can violate GDPR, HIPAA, or PCI DSS
  • Escalation: disclosed internal IDs, paths, or business logic often feed a second-stage vulnerability (path traversal, IDOR, targeted exploit selection)

Remediation Steps

Core Principle: Never return sensitive or internal information to an actor unless it is explicitly required for that actor's authorized function. Build responses, logs, and error output from an allowlisted exposure model, not from whatever internal state happens to be available.

Identify What Is Exposed and Where

  • Locate the exposure: the specific response, log entry, error message, header, or file where the data surfaces
  • Classify the data: credentials, tokens, PII, stack traces, internal paths, internal IDs, business logic, configuration
  • Identify the audience: who can reach this data - only the actors entitled to it, any authenticated user, or the anonymous internet
  • Trace the source: where the data originates (database record, exception, environment variable, filesystem) and every transformation between there and the exposure point

Apply an Allowlist Exposure Model (Primary Defense)

  • Define what is safe to return, not what to hide: build responses from an explicit allowlist of fields, never by serializing an internal object and trying to redact the sensitive parts after the fact
  • Authorize before returning: confirm the requesting actor is both authenticated and permitted to see this specific data, not just that the data exists
  • Use identical responses for "not found" and "not authorized": prevents an attacker from using response differences to enumerate valid resources or users

Apply Defense in Depth

  • Generic user-facing errors, detailed server-side logs: never return stack traces, SQL errors, or file paths to a client; log full detail server-side with a correlation ID
  • Secure configuration: disable debug mode and verbose output in production, remove development artifacts (.git, .env, backup files) from anything web-accessible, disable directory listing
  • Sanitize logs: never write passwords, tokens, full card numbers, or PII to logs, even at debug level
  • Security headers: suppress or genericize headers that fingerprint server software/version

Test the Fix

  • Trigger the original condition (invalid input, forced error, unauthorized request) and confirm no sensitive data appears in the response, header, or accessible log
  • Confirm the "not found" and "not authorized" cases are indistinguishable to an unauthorized caller
  • Re-scan with the tool that reported the finding to confirm it is resolved

Common Vulnerable Patterns

// VULNERABLE - pseudo-code
response = serialize(internal_record)
send_to_actor(response)
// internal_record contains fields never intended for this actor
// (credentials, tokens, internal IDs, other users' data)

Why this is vulnerable: the serializer decides what leaves, and its default is everything it can read. Nobody chose to include the credential: the code says "send the record", and which fields that means depends on the record's shape, not on any decision at this line. A reviewer has no statement of intent to check, and a field added to the record later ships to the actor without this code changing at all.

Because this is the parent of the family, a finding here is usually a pointer rather than an answer. The useful question is which actor is on the other side and what they were entitled to: the same line is harmless between two internal services and a breach when the caller is unauthenticated. Nothing fails when it goes wrong, either. The response is a success, tests that assert on the fields they care about still pass, and the defect is visible only in the payload itself.

Secure Patterns

// SECURE - pseudo-code
if not authorized(actor, internal_record):
    send_to_actor(generic_not_found_response)
else:
    response = build_from_allowlist(internal_record, ALLOWED_FIELDS)
    send_to_actor(response)

Why this works: Authorization is checked before any data leaves the system, and the response is built from an explicit allowlist rather than a full internal object. There is no field that reaches the actor unless it was deliberately included, so adding a new internal field later cannot silently expose it.

Common Pitfalls

  • Fixing "CWE-200" instead of the real weakness: patching the specific field or message a scanner flagged without identifying which child weakness (201, 209, 359, 532, and so on) actually caused it - the same mistake recurs elsewhere because the root cause was never addressed.
  • Redacting after serialization instead of allowlisting before it: stripping a few known-sensitive fields from an already-built response object still exposes any field nobody thought to redact; a new field added later ships exposed by default.
  • Returning a different status code or timing for "not authorized" vs "not found": even without message differences, a 403 vs 404 split, or a measurably slower authorization check, lets an attacker enumerate valid resources or users without ever seeing plaintext data.
  • Treating a masked or truncated value as safe: partial redaction (last four digits, a hashed value with a fast/no-salt algorithm, a truncated token) can still be sensitive depending on what it enables - verify the specific exposure against its own weakness, not against a generic "looks redacted" heuristic.

Additional Resources