CWEweakness
CWE-493 Critical Public Variable Without Final Modifier
High
Official page ↗
- Abstraction
- Variant
- Structure
- Simple
- Status
- Draft
- Likelihood of exploit
- High
- Languages
- C++, Java, Object-Oriented
- CWE version
- 5.0
Description
The product has a critical public variable that is not final.
Common consequences
• Integrity: Modify Application Data — If a field is non-final and public, it can be changed once the value is set by any function that has access to the class that contains the field. The object could potentially be tampered with. This could lead to a vulnerability if other parts of the program make assumptions about the contents of the field.
• Confidentiality: Read Application Data — The object could potentially allow the object to be read.
Potential mitigations
• [Implementation] Declare all public fields as final when possible, especially if it is used to maintain internal state of an Applet or of classes used by an Applet. If a field must be public, then perform all appropriate sanity checks before accessing the field from your code.
Detection methods
• 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.)
Related
Child of · CWE (1)
- CWE-732 Incorrect Permission Assignment for Critical Resource weakness
Referenced by CWE · child of (1)
- CWE-500 Public Static Field Not Marked Final weakness
Referenced by OWASP · mapped cwe (1)
- A05:2025 Injection Top 10 2025