The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.

What CVEs are caused by CWE-359?

180 recorded CVEs are attributed to CWE-359, including CVE-2023-36018, CVE-2024-49765, CVE-2022-0482.

How is CWE-359 detected?

Architecture or Design Review: Private personal data can enter a program in a variety of ways:

What are the consequences of CWE-359?

Exploiting CWE-359 can lead to: Read Application Data.

Is CWE-359 actively exploited?

180 recorded CVEs are caused by CWE-359; none are currently in CISA's KEV catalog of actively exploited flaws.

CWE-359: Exposure of Private Personal Information to an Unauthorized Actor (Privacy violation)

RadicalNotion.AI

How to prevent it

Practical mitigations for CWE-359, grouped by where in the lifecycle they apply.

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.

Implementation

Operation

Attack Surface Reduction

Some tools can automatically analyze documents to redact, strip, or "sanitize" private information, although some human review might be necessary. Tools may vary in terms of which document formats can be processed.

When calling an external program to automatically generate or convert documents, invoke the program with any available options that avoid generating sensitive metadata. Some formats have well-defined fields that could contain private data, such as Exchangeable image file format (Exif), which can contain potentially sensitive metadata such as geolocation, date, and time [REF-1515] [REF-1516].

Code examples

Illustrative examples from MITRE showing how the weakness appears in code.

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 example

csharp

pass = GetPassword();

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.

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

Vulnerable example

xml

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

Vulnerable example

java

locationClient = new LocationClient(this, this, this);

In 2004, an employee at AOL sold approximately 92 million private customer e-mail addresses to a spammer marketing an offshore gambling web site [REF-338]. In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated.

CWE-359: Exposure of Private Personal Information to an Unauthorized Actor

Overview

Real-world CVEs

Common consequences

How it happens

When it is introduced

Applies to

How to prevent it

How to detect it

Architecture or Design Review

Automated Static Analysis

Automated Static Analysis

Code examples

Illustrative examples

Terminology & mappings

Alternate terms

Mapped taxonomies

Attack patterns

Frequently asked questions

References

Stay ahead of CWE-359

Overview

Real-world CVEs

Common consequences

How it happens

When it is introduced

Applies to

How to prevent it

How to detect it

Architecture or Design Review

Automated Static Analysis

Automated Static Analysis

Code examples

Illustrative examples

Related weaknesses

Parent

Terminology & mappings

Alternate terms

Mapped taxonomies

Attack patterns

Frequently asked questions

References

Stay ahead of CWE-359