CWE-446 is about a lie told by an interface. The UI does not correctly enable or configure a security feature, yet its feedback leads the user to believe the feature is secure.
Any product with a settings screen can hit this: browsers, routers, admin consoles, SaaS dashboards.
How it happens
The screen and the system underneath disagree. MITRE gives two illustrations. A user ticks a box to turn on encrypted communications, and encryption is never enabled. Or a user writes a "restrict ALL" access rule and the product implements only "restrict SOME".
The observed example is CVE-1999-1446: the list of visited URLs was not cleared when the user chose the Clear History option.
What an attacker gains
MITRE lists the consequence as varying by context. The real harm is the false sense of security. People stop looking for protection they believe is already there, and the attacker benefits from the exposed gap.
How to find it
The record has no detection methods. Test the settings, not just the screen. After toggling a feature, verify the effect from outside: scan the port, inspect the traffic, read the stored configuration, try the forbidden action.
How to fix it
MITRE lists no formal mitigations. Reasonable steps:
- Make the UI read back the true state of the system after a change, rather than echoing the input.
- Show an error when a setting fails to apply.
- Add automated tests that flip each security setting and check the real result.
Quick check
Is a green checkmark proof that a feature works?
No. It only shows what the UI believes. Confirm the effect at the system level.
