Critical Data Element Declared Public

Incomplete Base
Structure: Simple
Description

This vulnerability occurs when a critical piece of data—like a variable, field, or class member—is mistakenly declared as public when it should be kept private according to the application's security design.

Extended Description

Declaring sensitive data as public breaks fundamental security principles like encapsulation and least privilege. It directly exposes critical information, such as internal state, configuration secrets, or authentication tokens, to any other part of the codebase or, in some languages and contexts, to external actors. This creates a clear and immediate attack surface, making it trivial for an attacker to read or modify data that should be strictly controlled. Beyond the direct security flaw, this practice severely damages code maintainability and security hygiene. It becomes difficult to track how and where this critical data is being used or altered, scattering logic that should be centralized. This "spaghetti code" effect makes identifying the root cause of bugs or vulnerabilities more time-consuming and increases the risk of introducing new security weaknesses during future development or refactoring.

Common Consequences 2
Scope: IntegrityConfidentiality

Impact: Read Application DataModify Application Data

Making a critical variable public allows anyone with access to the object in which the variable is contained to alter or read the value.

Scope: Other

Impact: Reduce Maintainability

Detection Methods 1
Automated Static AnalysisHigh
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.)
Potential Mitigations 1
Phase: Implementation
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.
Demonstrative Examples 2
The following example declares a critical variable public, making it accessible to anyone with access to the object in which it is contained.

Code Example:

Bad
C++
c++
Instead, the critical data should be declared private.

Code Example:

Good
C++
c++
Even though this example declares the password to be private, there are other possible issues with this implementation, such as the possibility of recovering the password from process memory (Storing Passwords in a Recoverable Format).

ID : DX-212

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.

Code Example:

Bad
C++
c++

// if the username and password in the input parameters are equal to*

c++
c++
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.

Code Example:

Good
C++
c++
Observed Examples 1
CVE-2010-3860variables declared public allow remote read of system properties such as user name and home directory.
References 1
Automated Source Code Maintainability Measure (ASCMM)
Object Management Group (OMG)
01-2016
ID: REF-960
Applicable Platforms
Languages:
C++ : UndeterminedC# : UndeterminedJava : Undetermined
Modes of Introduction
Implementation
Taxonomy Mapping
  • CLASP
  • The CERT Oracle Secure Coding Standard for Java (2011)
  • Software Fault Patterns
  • OMG ASCMM