CWE-571 is the mirror image of its sibling: an expression that always evaluates to true. The if branch always runs, and any else path is dead.
This one can be worse for security. A check written to restrict access that is always true lets everyone through. A guard meant to skip work that is always true skips it every time.
MITRE lists it as not language specific, with quality degradation as the consequence, varying by context.
How it happens
Common causes:
- Tautologies.
x < 5 || x >= 5. - Assignment instead of comparison. In C style languages,
if (x = 1)assigns and then tests a nonzero value. - Wrong logical operator.
if (role != "admin" || role != "owner")is true for every value. - Constants. A flag that never changes.
The record's example is a Java inventory method that checks whether a product is in the store or the warehouse, intending to run special handling when it is in neither. The logic is arranged so the fall through case cannot occur as intended. A compact version of the classic operator mistake:
// Vulnerable: always true, every role passes
if (!role.equals("admin") || !role.equals("owner")) {
// meant: deny anyone who is neither
denyAccess();
}
For any value, at least one of the two inequalities holds, so denyAccess() runs for everyone, admins included. The reverse error, with && and == mixed up, can make a deny rule always false and an allow rule always true. Either way the author's intent is lost.
What an attacker gains
MITRE lists quality degradation only. The real consequence depends on what the condition controls. When it guards authorization, validation or rate limiting, an always true condition can mean the control does nothing.
How to find it
Automated static analysis can find some instances, per MITRE. Compilers warn about assignments in conditions and about tautological comparisons. Tests that exercise the else branch will fail if it is unreachable. Review boolean logic with a truth table when the condition has more than two terms.
How to fix it
MITRE's mitigation: refactor the code, or determine whether the code is missing a condition that could cause the expression to become false.
- Write down what should be true and what should be false.
- Rebuild the condition, using De Morgan's laws if it helps.
- Add tests for the true and false cases, especially at the boundaries.
- Enable tautology and assignment in condition warnings.
// Fixed: deny only when the role is neither admin nor owner
if (!role.equals("admin") && !role.equals("owner")) {
denyAccess();
}
The free in-browser scan at gold.safeguard.sh/scan lists the dependencies in your manifest. No login is needed, the file stays on your machine, and it handles up to 100 dependencies.
Quick check
What is the classic cause?
A wrong logical operator, such as joining two inequalities with OR, which is true for every input.
Why can this be a security issue?
If the condition guards access or validation, an always true result can let every request through or skip the control.
