CWE-1097, Persistent Storable Data Element without Associated Comparison Control Element, describes a storable data element that does not have all the functions or methods needed to support comparison.
MITRE marks it as a quality issue with no direct security implications and prohibits it for mapping real vulnerabilities.
How it happens
A class is saved to a database or cache, then used as a key, put in a set, or sorted. The class never defines equality or ordering, so the language falls back to comparing identity.
// Smell: no equals or hashCode
class Session {
String userId;
String token;
}
Set<Session> active = new HashSet<>();
active.add(new Session("u1", "abc"));
active.contains(new Session("u1", "abc")); // false
Two sessions with the same content are treated as different. Duplicates pile up, and a check such as "is this session already revoked" can answer no when it should answer yes.
// Fix: define equality and a matching hash
@Override public boolean equals(Object o) {
return o instanceof Session s && userId.equals(s.userId) && token.equals(s.token);
}
@Override public int hashCode() { return java.util.Objects.hash(userId, token); }
What an attacker gains
MITRE lists reduced reliability, from incorrect or unexpected comparison results, and notes that if an attacker can reach the code, the problem might introduce a vulnerability. The risky cases are comparisons used for decisions: revocation lists, allow lists and duplicate checks.
How to find it
Static analysis can flag types used as keys without equality methods. Tests that store, reload and compare objects will expose it quickly.
How to fix it
- Define equality, hash and ordering together for any type that is stored or used as a key.
- Prefer records, data classes or value types that generate them for you.
- Test a round trip: save, load, compare.
Quick check
Why does a missing equality method matter for revocation lists?
A lookup compares objects by identity, so a reloaded entry never matches, and a revoked item can look as if it is not on the list.
