Loading module...

Broken Access Control | Top 10 Dev Training

OWASP-01

Broken Access Control

Access control enforces policy such that users cannot act outside of their intended permissions.

Audio overview (optional)

AI-generated summary. The Read tab has the full written content, which is the primary source and what the quiz is based on.

Transcript

Broken access control is at the top of the OWASP Top 10 for 2025, and it's there for a sobering reason. When the OWASP Foundation ran their analysis across hundreds of thousands of applications, every single one had some form of broken access control. Not some. Not most. All of them.

So let's talk about what this category actually is, why it's so pervasive, and what you can do about it in your own code.

At its core, access control is the rule that says users should only be able to do what they're authorized to do. Authentication is about proving you are who you say you are. Access control, sometimes called authorization, is about deciding whether the person you just authenticated is allowed to perform the action they're trying to perform. These are two different problems, and a lot of developers conflate them. That confusion is where bugs come from.

The most common flavor of broken access control is something called IDOR, short for insecure direct object reference. Imagine a URL that looks like slash api slash orders slash twelve thousand three hundred forty five. User one is looking at their own order. But what happens if they change the number to twelve thousand three hundred forty six? If the server returns user two's order without checking who's asking, you have an IDOR bug. And it's shockingly common. Most developers write the "fetch the order" logic and forget to also write "but only if the current user is allowed to see it."

Another pattern is missing authorization on write operations. Your GET endpoints might be locked down, but are your POST, PUT, and DELETE endpoints equally careful? A lot of teams focus on read access and forget that an unauthorized write is usually worse than an unauthorized read.

Then there's forced browsing, sometimes called horizontal privilege escalation. A regular user navigates to a URL they shouldn't know about, like slash admin slash users, and discovers that while the link wasn't visible in the interface, the endpoint itself wasn't guarded on the server. The URL was hidden, not protected. That's never enough.

Now, one thing that's new in the 2025 edition: server-side request forgery, or SSRF, used to be its own category at position ten. In 2025, the OWASP team moved it into broken access control. The reasoning makes sense once you think about it. SSRF is fundamentally the server making a request on a user's behalf to a resource the user shouldn't be able to reach. That is an access control failure, full stop. So if you're training on the 2021 list, you still need to cover SSRF. It just lives under a different label now.

So how do you defend against this category? A few patterns worth knowing.

First, adopt deny-by-default. Every endpoint should start with "no one can access this" and then explicitly grant permission. If you default to "allow" and try to remember to block things, you will miss something.

Second, centralize your authorization logic. If you're writing role checks scattered across forty endpoints, you will eventually forget one. Build a single middleware or helper that makes the authorization decision, and call it from every protected endpoint.

Third, enforce everything on the server. The client is untrusted. A hidden menu item is not a security control. A disabled button is not a security control. The server must make the authorization decision, every time.

And finally, log your access control decisions, especially denials. A sudden spike in denied requests is often the first sign of an attack in progress.

Broken access control is the number one category for a reason. Every app has some. The question is whether you've built the patterns to catch it, or whether you're going to find it the hard way.

Quiz & Certification

Training content is freely available. Sign in and get a training credit to take quizzes, track progress, and generate compliance reports.

Attestation not yet available

Complete and pass every module quiz in this course to unlock the final attestation. Once all modules are done, this tab will open for signing.

A01:2025 - Broken Access Control

Overview

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.

Impact: 100% of applications tested were found to have some form of broken access control, making this the #1 security risk.

Common Vulnerabilities

Violation of Least Privilege

Access should only be granted for particular capabilities, roles, or users, but is often available to anyone by default.

URL/Parameter Tampering

Bypassing access control by modifying the URL, internal application state, or HTML page using browser tools or API manipulation.

Insecure Direct Object References (IDOR)

Permitting viewing or editing someone else's account by providing its unique identifier without proper authorization checks.

Missing API Access Controls

APIs with missing access controls for POST, PUT, and DELETE operations, allowing unauthorized data modification.

Elevation of Privilege

Acting as a user without being logged in, or gaining admin privileges as a standard user.

Metadata Manipulation

Replaying or tampering with JWT tokens, cookies, or hidden fields to elevate privileges or abuse JWT invalidation.

CORS Misconfiguration

Allowing API access from unauthorized or untrusted origins due to improper Cross-Origin Resource Sharing settings.

Force Browsing

Guessing URLs to access authenticated pages as an unauthenticated user or privileged pages as a standard user.

Path / Directory Traversal

Abusing a file-read or file-include endpoint by injecting ../ sequences to escape the intended directory and reach files outside the application's allowed scope (e.g., /etc/passwd, .env, other tenants' files). It is an access control failure because the application intended to restrict users to a subset of the filesystem but failed to enforce that boundary.

Real-World Attack Scenarios

Scenario 1: SQL Parameter Tampering

An application uses unverified data in an SQL call accessing account information:

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

An attacker modifies the browser's acct parameter to access any user's account:

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

Impact: Complete access to any user's sensitive account data.

Scenario 2: Force Browsing to Admin Pages

An attacker directly accesses admin URLs without proper authentication:

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

If an unauthenticated user can access either page, or a non-admin can access the admin page, it's a critical flaw.

Scenario 3: Client-Side Access Control Bypass

An application implements all access control in the front-end JavaScript. An attacker bypasses the UI entirely:

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

Impact: Complete bypass of all access controls, exposing administrative functions.

Scenario 4: Directory Traversal via File-Read Endpoint

An application exposes a download endpoint that takes a filename as a query parameter and reads it from a documents directory:

String name = request.getParameter("file");
File f = new File("/var/app/documents/" + name);
response.getOutputStream().write(Files.readAllBytes(f.toPath()));

An attacker requests:

https://example.com/app/download?file=../../../../etc/passwd

Because the path is concatenated without normalization or containment, the resolved path escapes /var/app/documents/ and returns the contents of /etc/passwd.

Impact: Arbitrary file read on the server: system files, configuration, secrets, other tenants' data, anywhere the application process has read access. The fix is a combination of (a) resolving the path and verifying it still starts with the allowed base directory, and (b) rejecting input containing .., null bytes, or absolute paths.

How to Prevent

Server-Side Enforcement

Access control is only effective when implemented in trusted server-side code or serverless APIs where the attacker cannot modify the check or metadata.

Deny by Default

Except for public resources, deny access by default. Only grant access for specific capabilities, roles, or users.

Centralized Access Control

Implement access control mechanisms once and reuse them throughout the application, including minimizing CORS usage.

Enforce Record Ownership

Model access controls should enforce record ownership rather than allowing users to create, read, update, or delete any record.

Domain Model Enforcement

Unique application business limit requirements should be enforced by domain models.

Secure File Access

Disable web server directory listing
Ensure file metadata (e.g., .git) and backup files are not present within web roots

Logging and Monitoring

Log access control failures
Alert admins when appropriate (e.g., repeated failures)
Implement rate limits on API and controller access to minimize automated attacks

Session Management

Invalidate stateful session identifiers on the server after logout
Use short-lived stateless JWT tokens to minimize attack windows
For longer-lived JWTs, use refresh tokens and follow OAuth standards to revoke access

Testing

Developers and QA staff should include functional access control in unit and integration tests.

Additional Resources

Content adapted from OWASP Top 10:2025, licensed under CC BY-SA 4.0