Contact Us

Broken Access Control

Field: Security · Also called: access control failure, authorization failure, OWASP A01

Broken access control is a failure of an application to enforce what each user, process, or device is permitted to do, so that someone can read, change, or delete data, or perform functions, outside their intended permissions.

Access control is the decision to permit or deny a request. NIST SP 800-162 defines it as “the decision to permit or deny a subject access to system objects (network, data, application, service, etc.).” In an application, authentication establishes who the user is, and access control, also called authorization, decides what that user may do. Access control is broken when that decision is missing, made in the wrong place, or made on information the user controls.

The OWASP Top 10 describes it this way: “Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside the user’s limits.”

Authentication is not access control

Authentication answers who the user is. Access control answers what that user is authorized to do. OWASP’s Authorization Cheat Sheet puts it this way: “Authorization is distinct from authentication which is the process of verifying an entity’s identity.”

A common failure treats the first as if it were the second: the application checks that a request comes from a logged-in user and nothing more, so any user who can sign in can do anything the application can do. Reading another customer’s records, editing them, or calling an administrative function then needs no more than a valid account. The cheat sheet describes horizontal privilege escalation, “being able to access another user’s resources,” as “an especially common weakness that an authenticated user may be able to take advantage of.” Insecure direct object reference, below, is the most familiar version of this gap: the user’s identity was verified, but the request was never checked against what that identity is allowed to do.

Common forms

OWASP’s list for this category includes:

  • Insecure direct object reference (IDOR, CWE-639). The application uses an identifier from the request, such as an account number in a URL, without checking that the record belongs to the user. Changing ?acct=1001 to ?acct=1002 returns someone else’s account.
  • Missing checks on functions. An administrative page or API endpoint is hidden from the menu but not protected, so anyone who knows or guesses the URL can use it. OWASP calls requesting such pages directly “force browsing.”
  • Privilege escalation. Acting as a user without logging in, or gaining privileges beyond those of the logged-in user, such as administrator access.
  • Metadata manipulation. Replaying or tampering with a JSON Web Token, a cookie, or a hidden form field to raise privileges.
  • Missing access controls on API requests, especially for POST, PUT, and DELETE.
  • CORS misconfiguration that lets untrusted origins call an API on the user’s behalf.
  • Violating least privilege, where access that should be granted only to particular capabilities, roles, or users is available to anyone.

The 2025 category also covers server-side request forgery (CWE-918) and cross-site request forgery (CWE-352).

Prevention

OWASP’s prevention guidance starts from where the check runs: “Access control is only effective when implemented in trusted server-side code or serverless APIs, where the attacker cannot modify the access control check or metadata.” Its first recommendation is to deny by default: except for public resources, a request is refused unless a rule allows it. Its other recommendations include implementing access control mechanisms once and reusing them throughout the application, enforcing record ownership in the data model rather than letting users create, read, update, or delete any record, logging access control failures, and using well-established toolkits that provide simple, declarative access controls.

OWASP also says that “developers and QA staff should include functional access control in their unit and integration tests.” Those tests have to cover what each role must not be able to do, such as one customer changing the ID in a URL to view another customer’s invoice, not only what it should. Abuser stories and a threat model of the application’s roles help identify those cases.

History

The 2013 OWASP Top 10 listed insecure direct object references (A4) and missing function level access control (A7) separately. The 2017 edition merged them into A5, Broken Access Control. In the 2021 edition it moved from fifth to first, with OWASP reporting that “94% of applications were tested for some form of broken access control.” It remained first in the 2025 edition, where OWASP reported that “100% of the applications tested were found to have some form of broken access control,” across 40 mapped CWEs.

Sources

See also

Go deeper

Articles