The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.
View on MITREThis 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.
Making a critical variable public allows anyone with access to the object in which the variable is contained to alter or read the value.
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.
No detection method information available for this CWE.
The following example declares a critical variable public, making it accessible to anyone with access to the object in which it is contained.
Instead, the critical data should be declared private.
The following example declares a critical variable public, making it accessible to anyone with access to the object in which it is contained.
Instead, the critical data should be declared private.
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.
However, 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.
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.
However, 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.
variables declared public allow remote read of system properties such as user name and home directory.
View DetailsCWE-766: Critical Data Element Declared Public is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product declares a critical variable, field, or member to be public when intended security policy requires it to be private. 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.
If exploited, CWE-766 (Critical Data Element Declared Public) it can compromise Integrity, Confidentiality and Other, leading to outcomes such as Read Application Data, Modify Application Data and Reduce Maintainability.
Recommended mitigations for CWE-766 include: 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.
CWE-766 commonly affects C++, C# and Java. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-766, including CVE-2010-3860. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
A CWE (Common Weakness Enumeration) like CWE-766 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.