CWE-447 is a security control that exists only on the surface. A UI function for a security feature appears to be supported and gives feedback suggesting it works, but the underlying functionality is not implemented.
Unlike a broken feature, this one looks fine. That is what makes it dangerous.
How it happens
A common path is that the interface and the engine evolve separately. A checkbox or a command keyword is added to the front end, and the matching logic never ships, or ships for some configurations only. The observed examples in MITRE show it clearly:
- CVE-2000-0127: a GUI configuration tool did not enable a security option when a checkbox was selected, although the option was honored when set manually in the configuration file.
- CVE-2001-0863 and CVE-2001-0865: a router did not implement a specific keyword when it was used in an ACL, allowing filter bypass.
- CVE-2004-0979: a web browser did not properly change a security setting when the user set it.
What an attacker gains
MITRE lists the consequences as varying by context and an unexpected state. In the router cases, that meant traffic the administrator believed was filtered passed through anyway.
How to find it
The record lists no detection methods, but its mitigation points to the answer: test. For every security option in the UI, run a test that turns it on and then proves the behavior changed. For ACL or firewall rules, send traffic that should be blocked.
How to fix it
From the MITRE entry:
- Perform functionality testing before deploying the application.
Add to that, as common sense:
- Do not ship a UI control until the feature behind it works.
- If a feature is not supported in some mode, disable or label the control, so people are not misled.
- Have the UI read the live setting back after saving.
Quick check
How would you catch a checkbox that does nothing?
Write a test that enables it and then checks the system's behavior, such as blocked traffic or an encrypted connection, not just the saved value.
