CWE-450 covers interfaces that can read the same user input more than one way, then choose the less secure reading without asking.
Imagine a field that accepts a value in two formats, and the product silently treats an ambiguous entry as the permissive option.
How it happens
Ambiguity is built in when a UI accepts free-form input and has several valid parses. The designer picks a default without thinking about which default is safer. The user never learns a choice was made.
What an attacker gains
MITRE lists the consequence as varying by context. If the product resolves ambiguity toward the weaker setting, a user or an attacker who supplies the ambiguous input gets the weaker behavior.
How to find it
The record has no detection methods and no observed CVEs. Review each input handler and ask whether any input has more than one meaning. Test ambiguous inputs and check which interpretation wins.
How to fix it
MITRE's mitigations focus on input validation:
- Assume all input is malicious. Use an accept known good strategy: a list of acceptable inputs that strictly conform to the specification. Reject anything else, or transform it into something that does.
- Validate length, type, range of values, missing or extra inputs, syntax, consistency across related fields, and business rules.
- Do not rely only on looking for malicious inputs, because that tends to miss at least one.
- Decode and canonicalize input to the application's internal representation before validating, and do not decode the same input twice.
For the UI case, add one rule of your own: when input is ambiguous, ask the user, or pick the more secure meaning.
Quick check
Why prefer an allowlist over a denylist?
A denylist tends to miss at least one undesirable input, especially as the environment changes. An allowlist rejects whatever you did not explicitly accept.
