CWE-359 Base Incomplete

Exposure of Private Personal Information to an Unauthorized Actor

This vulnerability occurs when an application fails to adequately protect sensitive personal data, allowing access to individuals who either lack proper authorization or haven't provided necessary…

Definition

What is CWE-359?

This vulnerability occurs when an application fails to adequately protect sensitive personal data, allowing access to individuals who either lack proper authorization or haven't provided necessary consent for its use.
At its core, this weakness is about broken access control around private user information. This happens when developers don't properly enforce who can see data like addresses, financial details, health records, or identification numbers. The system might mistakenly expose this data through insecure APIs, direct object references, misconfigured permissions, or by leaking it in error messages or logs. Preventing this requires a 'need-to-know' enforcement strategy. Implement strict authorization checks that verify a user's identity and permissions for every data request, regardless of how it's made. Always apply the principle of least privilege, encrypt sensitive data at rest and in transit, and ensure personal information is never stored or logged unnecessarily. Regular access control audits and penetration testing focused on user data paths are essential for catching these oversights.
Vulnerability Diagram CWE-359
Exposure of Private Personal Information App stores PII: name, DOB, email, address, health Surfaces analytics events ←PII URLs /users/123/email 3rd-party scripts read DOM no minimization 3rd parties advertisers, SDKs, scrapers, subpoena/breach PII is reachable through analytics, logs, URLs and third-party SDKs.
Real-world impact

Real-world CVEs caused by CWE-359

No public CVE references are linked to this CWE in MITRE's catalog yet.

How attackers exploit it

Step-by-step attacker path

  1. 1

    The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored, the getPassword() function returns the user-supplied plaintext password associated with the account.

  2. 2

    The code in the example above logs a plaintext password to the filesystem. Although many developers trust the filesystem as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.

  3. 3

    This code uses location to determine the user's current US State location.

  4. 4

    First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:

  5. 5

    During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:

Vulnerable code example

Vulnerable C#

The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored, the getPassword() function returns the user-supplied plaintext password associated with the account.

Vulnerable C# 
pass = GetPassword();
  ...
  dbmsLog.WriteLine(id + ":" + pass + ":" + type + ":" + tstamp);
Secure code example

Secure pseudo

Secure pseudo 
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
  const safe = validateAndEscape(input);
  return executeWithGuards(safe);
}
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist

How to prevent CWE-359

  • Requirements Identify and consult all relevant regulations for personal privacy. An organization may be required to comply with certain federal and state regulations, depending on its location, the type of business it conducts, and the nature of any private data it handles. Regulations may include Safe Harbor Privacy Framework [REF-340], Gramm-Leach Bliley Act (GLBA) [REF-341], Health Insurance Portability and Accountability Act (HIPAA) [REF-342], General Data Protection Regulation (GDPR) [REF-1047], California Consumer Privacy Act (CCPA) [REF-1048], and others.
  • Architecture and Design Carefully evaluate how secure design may interfere with privacy, and vice versa. Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted.
Detection signals

How to detect CWE-359

Architecture or Design Review High

Private personal data can enter a program in a variety of ways: - Directly from the user in the form of a password or personal information - Accessed from a database or other data store by the application - Indirectly from a partner or other third party If the data is written to an external location - such as the console, file system, or network - a privacy violation may occur.

Automated Static Analysis High

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Plexicus auto-fix

Plexicus auto-detects CWE-359 and opens a fix PR in under 60 seconds.

Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.

Get a demo Try Plexicus free
Frequently asked questions

Frequently asked questions

What is CWE-359?

This vulnerability occurs when an application fails to adequately protect sensitive personal data, allowing access to individuals who either lack proper authorization or haven't provided necessary consent for its use.

How serious is CWE-359?

MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.

What languages or platforms are affected by CWE-359?

MITRE lists the following affected platforms: Mobile.

How can I prevent CWE-359?

Identify and consult all relevant regulations for personal privacy. An organization may be required to comply with certain federal and state regulations, depending on its location, the type of business it conducts, and the nature of any private data it handles. Regulations may include Safe Harbor Privacy Framework [REF-340], Gramm-Leach Bliley Act (GLBA) [REF-341], Health Insurance Portability and Accountability Act (HIPAA) [REF-342], General Data Protection Regulation (GDPR) [REF-1047],…

How does Plexicus detect and fix CWE-359?

Plexicus's SAST engine matches the data-flow signature for CWE-359 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.

Where can I learn more about CWE-359?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/359.html. You can also reference OWASP and NIST documentation for adjacent guidance.

Related weaknesses

Weaknesses related to CWE-359

CWE-200 Parent

Exposure of Sensitive Information to an Unauthorized Actor

This weakness occurs when an application unintentionally reveals sensitive data to someone who shouldn't have access to it.

CWE-1258 Sibling

Exposure of Sensitive System Information Due to Uncleared Debug Information

This vulnerability occurs when hardware fails to erase sensitive data like cryptographic keys and intermediate values before entering…

CWE-1273 Sibling

Device Unlock Credential Sharing

This vulnerability occurs when the secret keys or passwords required to unlock a device's hidden features are shared between multiple…

CWE-1295 Sibling

Debug Messages Revealing Unnecessary Information

The product's debug messages or logs expose excessive internal system details, potentially revealing sensitive information that could aid…

CWE-1431 Sibling

Driving Intermediate Cryptographic State/Results to Hardware Module Outputs

This vulnerability occurs when a hardware cryptographic module leaks sensitive internal data through its output channels. Instead of only…

CWE-201 Sibling

Insertion of Sensitive Information Into Sent Data

This vulnerability occurs when an application sends data to an external party, but accidentally includes sensitive information—like…

CWE-203 Sibling

Observable Discrepancy

This vulnerability occurs when an application responds differently to unauthorized users based on internal conditions. Attackers can…

CWE-209 Sibling

Generation of Error Message Containing Sensitive Information

This vulnerability occurs when an application reveals sensitive details about its internal systems, user data, or environment within error…

CWE-213 Sibling

Exposure of Sensitive Information Due to Incompatible Policies

This vulnerability occurs when a system's data handling aligns with the developer's security rules but accidentally reveals information…

Resources

Further reading

Ready when you are

Don't Let Security
Weigh You Down.

Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.