Broken Access Control: Checking Who Can Do What

Broken Access Control is the first category I explored in more detail while reading the OWASP Top 10:2025.

My notes for this topic center on a simple question: is the person making a request allowed to do this particular thing to this particular resource?

That question applies to much more than an administrator page. It also applies to viewing an account, editing a record, downloading a document, and calling an API.

Authentication and authorization

Authentication establishes who a user is. Authorization determines what that user is permitted to do.

A successful login can be part of an access-control decision, but the application still needs to check whether the authenticated user has the right permission for the requested action and resource.

For example, two customers may both be signed in. Each may be allowed to view their own invoices. That does not give either customer permission to read the other's invoices.

A record identifier is only part of the request

Imagine a customer portal that returns an invoice using an identifier in the request. The server finds the matching invoice and returns it.

The missing step could be the ownership check. Before returning the invoice, the application needs to determine whether this user is allowed to access it. A record existing in the database does not establish that permission.

A hard-to-guess identifier can make enumeration more difficult, but access control still needs to hold if someone learns an identifier that belongs to another customer.

The same question applies to changes. If a user cannot read someone else's invoice but can update or delete it through another endpoint, the access controls are incomplete.

The interface cannot enforce the whole policy

Hiding an administrator button can help the interface reflect a user's role. The server still needs to reject unauthorized requests to the action behind that button.

Requests can reach an application without following the intended sequence of screens. An API endpoint might also be used by several clients. The authorization decision needs to happen in a trusted part of the application whenever the protected operation is requested.

This is why the OWASP guidance emphasizes server-side enforcement and consistent access-control mechanisms.

Prevention ideas from the reading

A few principles give this category a useful structure:

Deny access unless it is allowed. Public resources can be intentionally public. Protected resources should require an explicit permission decision.
Give each role only the access it needs. A support role, customer role, and administrator role may need different capabilities.
Check the resource as well as the role. Ownership and tenant boundaries can matter even when users have the same role.
Apply checks consistently. Alternate endpoints and different operations on the same resource need the appropriate checks too.
Test rejected requests. Tests should cover the cases where access must fail, as well as the cases where it should succeed.

Logging denied requests can also help identify unusual behavior. Those logs need appropriate protection and a way to draw attention to patterns that require investigation.

Questions for my study notes

For a hypothetical account or document feature, I would start with:

Which users and roles should be allowed to use it?
Which records should each user be able to access?
Where does the server enforce those decisions?
Do read, create, update, and delete operations have the right checks?
What happens when the user is signed out, has a different role, or belongs to a different tenant?

These questions make the category more concrete. They also show why a working login and a well-organized interface are only part of the overall access-control design.

My takeaway

The key point in this part of my reading is the relationship between the user, the action, and the resource. All three need to be considered when deciding whether a request is allowed.

Next in the series is Security Misconfiguration, where the focus moves to the settings and environments that support an application.

Sources and further reading