Broken access control: the top risk a filter can barely see

Figures are from the A01:2025 page; the change for server-side request forgery is in the 2025 introduction.

OWASP lists the common forms.

• Access open by default. Least privilege is not applied, so anything not explicitly closed is open.
• Checks bypassed by editing the request. A URL, a parameter, internal state or an API call is changed until the check no longer applies.
• Another account reached by its identifier. Changing an account or record number in the request returns someone else's data.
• Write operations without checks. An API protects reading but not POST, PUT or DELETE.
• Privilege escalation. Acting without signing in, or acting as an administrator while signed in as a user.
• Tampered tokens and cookies. Metadata such as a JWT, a cookie or a hidden field is replayed or altered to raise privileges.
• Cross-origin access left open. A CORS policy lets untrusted origins call the API.
• Forced browsing. Authenticated or privileged pages are reachable by guessing their address. Its file-system relative is path traversal.

Privilege escalation is broken access control in its most direct form: a user acts as someone with more rights. Vertical escalation reaches functions meant for a higher role, such as an administrator panel; horizontal escalation reaches another user's data at the same level.

Both look ordinary in a request. The defence is the same as for the rest of the category: check the role and the ownership on the server for every request, never only in the page the user was shown.

In OWASP's first example, an application uses an account number from the request to look up an account and never checks that it belongs to the caller. The attacker changes the number. The request is well formed, the parameter is a number where a number is expected, and nothing in it is unusual.

That is the core difficulty. The difference between a permitted request and a forbidden one is who sent it and who owns the object, and both facts live in the application's data, not in the request.

Two parts of the category do leave traces. Forced browsing produces requests for paths such as administrative consoles or backup files that ordinary visitors never ask for, and request forgery puts an internal address into a parameter that should hold an external URL.

Server-side request forgery happens when an application fetches a URL supplied by the user and can be pointed somewhere the user could never reach directly: an internal service, a metadata endpoint, a private address. The server makes the request with its own network position and privileges.

The 2025 edition folded it into broken access control, because the result is the same: the attacker reaches what they were not permitted to. It remains its own weakness, CWE-918, and it is a separate item, API7, in the OWASP API Security Top 10.

A filter can match requests that put internal addresses or unusual schemes into URL parameters. The fix is in the application: allow only the destinations it needs, and refuse the rest after resolving the address. The attack in full is on SSRF.

Every measure OWASP lists is implemented in the application.

• Deny by default. Everything except public resources starts closed.
• One access-control mechanism, reused. Built once and applied everywhere, with cross-origin access kept to a minimum.
• Ownership checked on records. Access follows who owns the record, not a blanket right to read or write a type.
• Nothing to browse. Directory listing off; metadata such as .git and backups kept out of the web root.
• Failures logged and rate limited. Repeated access-control failures raise an alert, and limits on APIs slow automated attempts.
• Sessions and tokens ended properly. Server-side sessions end at logout; stateless tokens stay short-lived.

OWASP also asks for access-control checks in unit and integration tests, which is the only place a missing check reliably shows up before release.