CWE-1090, Method Containing Access of a Member Element from Another Class, applies to object oriented code where a method directly reaches into a member of a different class.
MITRE describes this as a sign of poor encapsulation. The entry is a quality issue with no direct security implications and is prohibited for mapping real vulnerabilities.
How it happens
A class exposes its fields, and another class reads or writes them directly instead of calling a method.
// Smell: Checkout edits Account internals directly
class Checkout {
void charge(Account a, long cents) {
a.balance = a.balance - cents; // no check, no audit
}
}
The rule that a balance cannot go negative lives, or should live, inside Account. Every outside class that touches the field has to remember it.
// Better: the owner enforces its own rules
class Account {
private long balance;
void debit(long cents) {
if (cents > balance) throw new IllegalStateException("insufficient funds");
balance -= cents;
}
}
What an attacker gains
Nothing directly. MITRE lists reduced maintainability and increased analytical complexity, with an indirect effect on how quickly vulnerabilities can be found and fixed. The security angle is real in a quiet way: invariants spread across many classes are easy to break in one of them.
How to find it
Code metrics and static analysis can report coupling between classes. In review, look for public fields and for code that chains through objects to reach state.
How to fix it
- Make fields private and expose behavior, not data.
- Move logic to the class that owns the data.
- Use immutable value objects where state should not change.
Quick check
Why does encapsulation help security review?
Rules such as limits and validation sit in one place, so a reviewer checks one class rather than every caller.
