Broken Access Control: Risks and Remediation

Broken access control encompasses a class of vulnerabilities in which an application fails to enforce restrictions on what authenticated or unauthenticated users are permitted to do or access. Ranked #1 in the OWASP Top Ten (2021), it represents the most prevalent category of application security failure found in real-world web applications. The consequences range from unauthorized data disclosure to full administrative account takeover, making it a central concern for organizations operating under PCI DSS, HIPAA, and NIST-aligned security programs.

Definition and scope

Access control is the mechanism by which an application enforces that users can only perform actions or view resources that they are explicitly authorized to access. Broken access control occurs when those enforcement mechanisms are absent, misconfigured, or bypassable.

NIST SP 800-53 Rev. 5, control family AC (Access Control), defines access enforcement as a mandatory control requiring systems to enforce approved authorizations for logical access to information and resources. When application code fails to implement these checks consistently, the result is a broken access control condition.

The scope of broken access control extends across three principal categories:

1. Vertical privilege escalation — A lower-privileged user accesses functionality reserved for higher-privileged roles (e.g., a standard user invoking admin-only API endpoints).
2. Horizontal privilege escalation — A user accesses resources belonging to another user at the same privilege level (e.g., modifying another customer's order by altering a numeric ID in a request).
3. Context-dependent access failures — Access restrictions that apply in one workflow state are bypassed by manipulating application state, URL parameters, or HTTP methods outside the intended flow.

This category is distinct from authentication and authorization security failures that prevent valid users from logging in — broken access control specifically concerns what happens after authentication succeeds.

How it works

Most broken access control vulnerabilities arise from the mismatch between server-side trust assumptions and client-supplied inputs. Applications commonly store object identifiers, role flags, or resource paths in URLs, cookies, or request bodies. When the server fails to re-validate each request against the requesting user's actual permissions, any user capable of manipulating those values can exceed their authorized scope.

The attack surface typically involves:

1. Insecure Direct Object References (IDOR) — A resource is identified by a predictable value (integer ID, UUID, filename) directly in the request, and the server returns the resource without confirming ownership.
2. Missing function-level access control — Administrative routes (e.g., /admin/deleteUser) are not protected by server-side role checks, relying instead on the interface simply not displaying the link to unauthorized users.
3. HTTP method override abuse — An endpoint enforces access control on GET but not on PUT or DELETE, allowing privilege escalation through method substitution.
4. Metadata and JWT manipulation — Access control decisions are derived from claims embedded in tokens or cookies that the client can forge or modify when signing and validation are absent. This intersects directly with JSON Web Token security failures.
5. Path traversal and URL bypass — Access restrictions on /admin are circumvented by requesting /Admin, /admin/, or /%2fadmin, exploiting inconsistent normalization.

OWASP's Testing Guide (WSTG-ATHZ) categorizes authorization testing as a discrete discipline within web application security testing, with specific test cases for each bypass technique.

Common scenarios

E-commerce order manipulation — A customer changes the order_id parameter from 10032 to 10031 in a REST API call. The server returns the full order details — including shipping address and payment method — of a different customer, constituting a horizontal escalation.

Admin function exposure — A healthcare portal exposes a /reports/export-all-phi endpoint. The endpoint is excluded from navigation menus for non-admin users but performs no server-side role check. Any authenticated user who discovers or guesses the URL can export protected health information, triggering exposure obligations under HIPAA's Security Rule (45 CFR § 164.312).

Mass assignment exploitation — A user registration API accepts a JSON body and binds all incoming fields to a model object. If isAdmin: true is included in the request, and the application does not explicitly block non-whitelisted fields, the user is created with administrator privileges. This failure pattern is documented in OWASP's API Security Top 10 (API6:2023).

Forced browsing in multi-tenant SaaS — A B2B platform uses tenant identifiers embedded in subdomains but stores data keyed only by internal record ID. A user on tenant-a.app.com constructs direct API calls using record IDs harvested from their own tenant. Without tenant-scoping on the data access layer, records from tenant-b are returned.

Each of these scenarios is detectable through structured application penetration testing and automated tooling in dynamic application security testing pipelines.

Decision boundaries

Evaluating and remediating broken access control requires distinguishing between architectural failures, implementation gaps, and configuration errors — each requiring a different remediation path.

Architectural vs. implementation failures

An architectural failure exists when the access control model is undefined or inconsistently designed — for instance, when role hierarchies are not formally specified and enforcement is ad hoc. An implementation failure exists when the model is well-defined but specific code paths omit the enforcement call. Architectural failures require design review (see threat modeling for applications); implementation failures are addressable through secure code review and automated scanning.

Client-side vs. server-side enforcement

Any access control decision that depends exclusively on client-side state — hidden form fields, disabled buttons, localStorage flags, or UI-only role checks — is categorically insufficient. All enforcement must occur server-side at the resource layer, not at the presentation layer. This boundary is absolute.

Deny-by-default vs. allow-by-default models

NIST SP 800-53 AC-3 specifies enforcement of least privilege. Applications implementing a deny-by-default model — where access is blocked unless explicitly granted — are structurally more resistant than allow-by-default designs. Migrating from allow-by-default to deny-by-default typically requires an inventory of all resource access paths and is a foundational component of an appsec program building exercise.

Automated detection limits

Static application security testing tools can identify missing authorization annotations or decorator patterns in frameworks that use them, but cannot reliably infer business-logic intent. Business logic vulnerability testing and manual review remain necessary for scenarios involving state-dependent access rules or complex multi-object relationships. This distinction governs where automated controls are sufficient and where human review is mandatory.

Regulatory thresholds

For applications in scope for PCI DSS application security requirements (Requirement 7) or HIPAA's Security Rule minimum necessary standard, access control failures that result in unauthorized access to cardholder data or protected health information trigger mandatory breach assessment and, depending on scope, notification obligations under 45 CFR § 164.400–414.

References

• OWASP Top Ten 2021 — A01: Broken Access Control
• OWASP Web Security Testing Guide — Authorization Testing (WSTG-ATHZ)
• OWASP API Security Top 10 (2023)
• NIST SP 800-53 Rev. 5 — Security and Privacy Controls (AC Family)
• HHS HIPAA Security Rule — 45 CFR § 164.312
• HHS HIPAA Breach Notification Rule — 45 CFR §§ 164.400–414
• NIST Secure Software Development Framework (SSDF) — NIST SP 800-218