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

Description: 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.

Extended Description: There are many types of sensitive information that products must protect from attackers, including system data, communications, configuration, business secrets, intellectual property, and an individual's personal (private) information. Private personal information may include a password, phone number, geographic location, personal messages, credit card number, etc. Private information is important to consider whether the person is a user of the product, or part of a data set that is processed by the product. An exposure of private information does not necessarily prevent the product from working properly, and in fact the exposure might be intended by the developer, e.g. as part of data sharing with other organizations. However, the exposure of personal private information can still be undesirable or explicitly prohibited by law or regulation. Some types of private information include: Government identifiers, such as Social Security Numbers Contact information, such as home addresses and telephone numbers Geographic location - where the user is (or was) Employment history Financial data - such as credit card numbers, salary, bank accounts, and debts Pictures, video, or audio Behavioral patterns - such as web surfing history, when certain activities are performed, etc. Relationships (and types of relationships) with others - family, friends, contacts, etc. Communications - e-mail addresses, private messages, text messages, chat logs, etc. Health - medical conditions, insurance status, prescription records Account passwords and other credentials Some of this information may be characterized as PII (Personally Identifiable Information), Protected Health Information (PHI), etc. Categories of private information may overlap or vary based on the intended usage or the policies and practices of a particular industry. Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.


Alternate Terms: ::TERM:Privacy violation::TERM:Privacy leak::TERM:Privacy leakage::

Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Mobile:TECHNOLOGY PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Architecture and Design:NOTE:OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.::PHASE:Implementation::PHASE:Operation::



Common Consequences: ::SCOPE:Confidentiality:IMPACT:Read Application Data::

Detection Methods: ::METHOD:Architecture or Design Review:DESCRIPTION: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.:EFFECTIVENESS:High::METHOD:Automated Static Analysis:DESCRIPTION: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.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Requirements:DESCRIPTION: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.::PHASE:Architecture and Design:DESCRIPTION: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.::




Notes: ::TYPE:Maintenance:NOTE:This entry overlaps many other entries that are not organized around the kind of sensitive information that is exposed. However, because privacy is treated with such importance due to regulations and other factors, and it may be useful for weakness-finding tools to highlight capabilities that detect personal private information instead of system information, it is not clear whether - and how - this entry should be deprecated.::