---
title: 'A01: Broken Access Control'
description: OWASP Web Top 10 reference for broken access control vulnerabilities including privilege escalation and unauthorized resource access
---

# 01 Broken Access Control

Identifier: A01:2025
Category: Access Control

## Description

Broken access control occurs when an application fails to enforce policies that prevent users from
acting outside their intended permissions.
This vulnerability allows unauthorized information disclosure, modification or destruction of data,
or performing business functions beyond the user's authorized limits.
Common manifestations include violation of the principle of least privilege, bypassing access
control checks through URL parameter tampering or API request modification, insecure direct object
references, missing access controls on API endpoints, elevation of privilege, metadata
manipulation of tokens and cookies, and CORS misconfiguration.
Access control weaknesses are pervasive across web applications, with 100% of tested applications
exhibiting some form of this vulnerability.

## Risk

* Unauthorized access to sensitive data belonging to other users or the organization.
* Modification or destruction of records the attacker should not be able to reach.
* Elevation of privilege from a standard user to an administrator role.
* Business logic bypass enabling actions outside the intended user workflow.
* Lateral movement across accounts through insecure direct object references.
* Server-side request forgery when access controls do not restrict internal resource access.
* Cross-site request forgery when anti-CSRF protections are absent or misconfigured.

## Vulnerability checklist

* Access is not denied by default; resources are available to anyone unless explicitly restricted.
* Access control checks can be bypassed by modifying the URL, application state, or API requests.
* Users can view or edit other users' records by supplying a different unique identifier.
* API endpoints for POST, PUT, and DELETE operations lack access control enforcement.
* A user can act as another user or gain administrator privileges without proper authentication.
* JWT tokens, cookies, or hidden fields can be tampered with to elevate privileges.
* CORS policy allows API access from unauthorized or untrusted origins.
* Authenticated pages are accessible to unauthenticated users through forced browsing.
* File metadata, backup files, or source control directories are present within web roots.

## Prevention controls

1. Deny access by default for all resources except those explicitly designated as public.
2. Implement access control mechanisms once and reuse them consistently throughout the
   application, including minimizing CORS usage.
3. Enforce record ownership in access control models rather than allowing users to create, read,
   update, or delete any record.
4. Enforce unique business limit requirements through domain models.
5. Disable web server directory listing and remove file metadata and backup files from web roots.
6. Log all access control failures and alert administrators on repeated failures.
7. Implement rate limits on API and controller access to reduce harm from automated attacks.
8. Invalidate stateful session identifiers on the server after logout and use short-lived
   stateless JWT tokens with refresh token rotation following OAuth standards.
9. Use well-established toolkits or patterns that provide simple, declarative access controls.
10. Include functional access control tests in unit and integration test suites.

## Example attack scenarios

### Scenario A — Insecure direct object reference

An application uses unverified data in a SQL call to access account information:

```
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
```

An attacker modifies the browser's `acct` parameter to send any desired account number.
The application returns the other user's data because it does not verify ownership:

```
https://example.com/app/accountInfo?acct=notmyacct
```

### Scenario B — Forced browsing to admin pages

An attacker forces the browser to target URLs that require admin rights:

```
https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo
```

If an unauthenticated user can access either page, it is a flaw.
If a non-admin can access the admin page, it is a flaw.

### Scenario C — Client-side only access control

An application enforces all access control in its frontend JavaScript.
While the attacker cannot reach the admin endpoint through the browser, they bypass it entirely:

```
curl https://example.com/app/admin_getappInfo
```

The server returns the admin page because it does not enforce server-side access controls.

## Detection guidance

* Review application code for consistent enforcement of access control checks on all endpoints.
* Test for insecure direct object references by substituting resource identifiers in requests.
* Verify that forced browsing to authenticated or privileged pages fails for unauthorized users.
* Inspect CORS configuration for overly permissive origin policies.
* Check for the presence of file metadata, backup files, and source control directories in
  web-accessible paths.
* Monitor access control failure logs for patterns indicating automated or targeted attacks.

## Remediation

* Implement server-side access control enforcement on all endpoints and resource operations.
* Remove all file metadata, backup files, and source control directories from web roots.
* Restrict CORS policies to trusted origins only.
* Add access control failure logging with alerting for repeated violations.
* Invalidate sessions on logout and enforce session timeout policies.
* Conduct access control penetration testing and remediate all identified bypasses.

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0
(<https://creativecommons.org/licenses/by-sa/4.0/>).
Modifications: Restructured into agent-consumable reference format with added
detection and remediation guidance.