CWE-697, Incorrect Comparison, is a pillar level weakness: the product compares two entities in a security-relevant context and the comparison is wrong. MITRE describes three ways. The comparison checks one factor incorrectly. It should consider several factors but skips at least one. Or it checks the wrong factor entirely.
How it happens
Observed examples from the record:
- CVE-2021-3116: a Python based HTTP proxy uses the wrong boolean operators, producing an incorrect comparison that identifies an authentication failure only if all three conditions are met instead of any one of them.
- CVE-2020-15811: a proxy uses a substring search instead of parsing the Transfer-Encoding header, allowing request splitting and cache poisoning.
- CVE-2016-10003: a proxy performs an incorrect comparison of request headers, leading to an information leak.
The first is a logic slip you can see in a few lines. An illustration:
# Vulnerable: failure only when ALL conditions hold
if no_user and no_password and no_token:
deny()
# Fixed: failure when ANY required credential is missing
if no_user or no_password or no_token:
deny()
The second teaches a broader lesson. A substring search for a header value is not the same as parsing the header. "chunked" appearing somewhere in the text does not mean the header says chunked.
What an attacker gains
MITRE says impact varies by context, because the wrong comparison leads to whatever weakness the check was guarding against. In the examples that was authentication bypass, request splitting, cache poisoning and information disclosure.
How to find it
MITRE notes static analysis can find some instances by modelling data and control flow. Add tests that give each condition its own failing case. Review any security decision that uses string containment, loose equality or compound boolean logic.
How to fix it
- Parse structured values before comparing them. Do not search them as text.
- Spell out the intended truth table and test every row.
- Use strict equality, and constant time comparison for secrets.
- Compare the right factor: the parsed, normalized value, not the raw one.
Quick check
Why is a substring search on a header risky?
Because the text can match without the header meaning what you think, and different parsers can disagree about it.
