CWE-424 is a product that does not sufficiently protect all possible paths a user can take to reach restricted functionality or resources. It is about coverage: the control exists, but not on every route.
How it happens
A developer blocks the obvious route, such as a menu link or a directory listing, and assumes the job is done. Another route, such as a direct URL, a different API method or an old endpoint, reaches the same resource unchecked.
MITRE's example is a web based document collaboration tool whose access control prevented listing hidden directories but not direct requests to files in them (CVE-2022-29238).
What an attacker gains
Per the record: bypassing protection mechanisms and gaining privileges or assuming identity. The attacker reads or changes what the control was meant to guard.
How to find it
The record lists no detection methods. Practical checks:
- Pick a protected resource and list every way to reach it: by URL, by ID, by search, by export, by API, by an older version.
- Request it directly from an account that should not have access.
- Review routing code for checks that depend on how the user arrived.
How to fix it
- Check authorization at the resource, every time, not at the navigation layer.
- Deny by default, and allow only explicitly.
- Retire or lock down old routes and test endpoints.
- Add tests that request each protected file or action directly without permission.
A common pattern
Teams often add a feature flag, a new API version or a mobile endpoint beside an old web page. The permission check gets written for the new route. The old route still exists, still works, and checks nothing. Attackers compare versions, read client code and try the older paths. A route inventory that maps each path to its authorization rule makes gaps visible.
Quick check
Is hiding a listing a security control?
No. A listing only helps people find things. Access to the thing itself must be checked separately.
