Broken Access Control: OWASP's Number One Risk, Explained

Broken access control has been the number one category in the OWASP Top 10 since 2021, and it stayed there in 2025. Authentication answers "who are you?" Access control answers "what are you allowed to do?" Most serious application breaches involve getting the second question wrong.

Forms of broken access control

• Horizontal privilege escalation: accessing another user's data at the same privilege level, often through IDOR.
• Vertical privilege escalation: a normal user performing admin actions.
• Missing function-level checks: admin API endpoints that the UI hides but the server does not protect.
• Forced browsing: visiting unlinked URLs such as /admin or /internal/reports.
• Parameter tampering: changing role=user to role=admin in a request.
• Multi-tenant leakage: data from one organisation visible to another.
• CORS misconfiguration that lets malicious sites read authenticated responses.
• SSRF, included in this category in the 2025 edition.

A typical example

The frontend shows an "Invite admin" button only to admins. The API endpoint behind it looks like this:

app.post("/api/team/invite", requireLogin, async (req, res) => {
  await inviteUser(req.body.email, req.body.role);
  res.sendStatus(204);
});

It checks that the user is logged in, not that they are an admin. Any user can call it directly and invite themselves a new admin account.

Principles of strong access control

1. Deny by default. Every endpoint requires an explicit permission.
2. Enforce on the server. The UI hiding a button is not security.
3. Centralise decisions. One policy layer or library, not checks copied into each handler.
4. Check ownership and tenancy for every object, not just the user's role.
5. Log access control failures and alert on spikes.
6. Invalidate sessions and tokens when permissions change.

Designing an authorisation layer

A simple, effective pattern for SaaS:

// One place that answers "can this user do this to this resource?"
function can(user, action, resource) {
  if (resource.orgId !== user.orgId) return false;
  return PERMISSIONS[user.role]?.includes(action) ?? false;
}

Every handler calls it, and tests cover every role and action combination. More complex products may use attribute-based access control or a dedicated policy engine, but the principle is the same.

Testing access control

Effective testing builds a matrix: every role against every endpoint and action, across at least two tenants. It also includes requests the UI never makes, such as calling admin endpoints as a normal user or changing role parameters. This is where traditional scanners fail completely, because they do not understand who should be allowed to do what.

SecurityInfinity agents test authenticated workflows across roles and tenants, verify unauthorised access, and give the precise fix. Start free.

Frequently asked questions

What is the difference between authentication and authorisation?

Authentication verifies identity. Authorisation decides what that identity is allowed to do. Broken access control is an authorisation failure.

Why do scanners miss access control bugs?

Scanners do not know your business rules. They cannot tell that a response containing another customer's data is wrong.

Does using a framework prevent broken access control?

Frameworks provide tools, but developers must apply them consistently. Most access control bugs come from a missing check on one endpoint.