CWE-766: Critical Data Element Declared Public
The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.
Last updated
Overview
This issue makes it more difficult to maintain the product, which indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities. It also might make it easier to introduce vulnerabilities.
Common consequences
What can happen when CWE-766 is exploited.
Read Application Data, Modify Application Data
Affects: Integrity, Confidentiality
Making a critical variable public allows anyone with access to the object in which the variable is contained to alter or read the value.
Reduce Maintainability
Affects: Other
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
How to prevent it
Practical mitigations for CWE-766, grouped by where in the lifecycle they apply.
Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering.
How to detect it
Automated Static Analysis
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
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The following example declares a critical variable public, making it accessible to anyone with access to the object in which it is contained.
Vulnerable example
public: char* password;Safe example
private: char* password;The following example shows a basic user account class that includes member variables for the username and password as well as a public constructor for the class and a public method to authorize access to the user account.
Vulnerable example
#define MAX_PASSWORD_LENGTH 15Safe example
class UserAccountHowever, the member variables username and password are declared public and therefore will allow access and changes to the member variables to anyone with access to the object. These member variables should be declared private as shown below to prevent unauthorized access and changes.
Illustrative examples
Real CVEs that MITRE cites as examples of this weakness.
- CVE-2010-3860 — variables declared public allow remote read of system properties such as user name and home directory.
Terminology & mappings
Mapped taxonomies
- CLASP: Failure to protect stored data from modification
- The CERT Oracle Secure Coding Standard for Java (2011): Declare data members as private and provide accessible wrapper methods (OBJ01-J)
- Software Fault Patterns: Unexpected access points (SFP28)
- OMG ASCMM (ASCMM-MNT-15)
Frequently asked questions
Common questions about CWE-766.
- What is CWE-766?
- The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.
- How do you prevent CWE-766?
- Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering.
- How is CWE-766 detected?
- Automated Static Analysis: 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.)
- What are the consequences of CWE-766?
- Exploiting CWE-766 can lead to: Read Application Data, Modify Application Data, Reduce Maintainability.
References
- MITRE CWE definition (CWE-766) (opens in a new tab)
- CWE-766 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-766
Get alerted the moment a new CWE-766 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.