Broken access control happens when an app lets a user do something they shouldn't, like read another customer's invoice or open an admin page. It is the top risk in the OWASP Top 10:2025, and it shows up in almost every web app pentest. Scanners rarely catch it because the requests look normal. Below are 6 real examples testers find again and again, how each one gets found, and how to fix it.
What is broken access control?
A flaw that lets users act outside their permissions, such as viewing other people's data or using admin functions.
Why is broken access control so common?
Every request needs its own permission check, and developers often lock the page but forget the API behind it.
Can automated scanners find broken access control?
Rarely. A scanner can't tell whether invoice 1043 belongs to you, so testers check by hand with two accounts.
How do you prevent broken access control?
Deny by default, and check ownership on the server for every single request.
Key Takeaways
- Broken access control is #1 in the OWASP Top 10:2025, and OWASP found some form of it in every application tested.
- Most cases come down to one missing check: the server never asks whether this user is allowed to touch this object.
- Hiding a button or a URL is not access control. Attackers send requests directly to the API.
- Some of the largest breaches on record, including First American Financial and Optus, started with this kind of flaw.
- Finding it takes manual testing with at least two accounts at different permission levels.
6 Real Examples of Broken Access Control Found in Pentests
OWASP's A01:2025 entry maps 40 weaknesses to this one category, but in practice the same handful of patterns show up in report after report. Each example below describes how testers usually find it, a public breach that followed the same pattern, and the fix.
Example 1: IDOR, or Changing an ID to See Someone Else's Data
Insecure direct object reference (IDOR) is the most common access control finding in web app pentests. The tester logs in, opens their own invoice at /invoices/1043, then changes the number to 1044. If another customer's invoice loads, the app is checking that you're logged in but not that the record is yours. Sequential IDs make it worse, because an attacker can script through every record in minutes. This is exactly what happened at First American Financial in 2019, where changing a number in a document link exposed roughly 885 million files, including bank statements and Social Security numbers. It sits at the top of most lists of common web application security issues for good reason. The fix: check on the server that the requested record belongs to the current user, every time.
Example 2: API Endpoints That Skip Authentication Entirely
Many apps protect their web pages but leave the API behind them open. Testers find these endpoints by watching the app's own traffic, reading JavaScript files, or pulling an old Swagger file from a forgotten path. Then they call the endpoint with no session token at all. Sometimes it answers with full customer records. In the 2022 Optus breach, the attacker said customer data for about 10 million people came from an API endpoint that required no authentication. Endpoints built for internal tools, mobile apps, or partners are the usual culprits, which is why API security testing looks at every endpoint, not just the documented ones. The fix: require authentication by default on every route, and make public endpoints the exception someone has to approve.
Example 3: Privilege Escalation by Editing a Role Field
Here a normal user turns themselves into an admin. The classic test is mass assignment: when updating a profile, the tester adds a field the form never showed, such as "role": "admin" or "isAdmin": true. If the backend saves whatever the request contains, the account is promoted on the spot. A related finding is the hidden admin panel, where /admin is missing from the menu for normal users but still works if you type it in. Both happen because the app trusts the browser to enforce roles. The fix: allow-list the fields each role may change, and check the user's role on the server for every admin function, not just when drawing the menu.
Example 4: Cross-Tenant Data Access in SaaS Apps
Multi-tenant SaaS apps keep many companies' data in one system, separated by a tenant or organization ID. Testers create accounts in two different test tenants, then swap the tenant ID in requests from one to the other. When it works, a user at Company A can read Company B's reports, users, or files. This is horizontal privilege escalation at the worst possible scale, because one flaw exposes every customer at once. It's also hard to spot in code review, since each query looks correct on its own. The fix: take the tenant ID from the authenticated session, never from the request, and filter every database query by it.
Example 5: Tampered JWTs and Cookies That Grant Admin Rights
Many apps store the user's role inside a JSON Web Token (JWT) or a cookie. Testers decode the token, change "role": "user" to "role": "admin", and send it back. If the server doesn't verify the signature properly, or accepts a token with the algorithm set to none, the edit sticks. Weak signing secrets are another frequent finding, because a tester can crack them offline and sign any token they like. Expired or logged-out tokens that still work fall into the same category. The fix: verify every token's signature with a strong key, reject none, enforce expiry, and look up permissions on the server instead of trusting claims in the token.
Example 6: SSRF That Reaches Cloud Credentials
OWASP folded server-side request forgery (SSRF) into broken access control in 2025, and cloud pentests show why. Any feature that fetches a URL, such as a webhook, a link preview, or a PDF generator, can be pointed at internal addresses instead. Testers aim it at the cloud metadata service at 169.254.169.254, which can hand back temporary access keys. That chain matches the 2019 Capital One breach, where an attacker used SSRF through a misconfigured firewall to pull credentials and read data on about 100 million customers. A cloud security assessment checks both halves: the SSRF and the over-permissive role it unlocks. The fix: allow-list outbound destinations, block internal IP ranges, and require IMDSv2 on AWS.
How Do Pentesters Test for Broken Access Control?
Access control flaws hide inside requests that look completely normal, which is why this is one of the clearest differences between a pentest and a vulnerability scan. A typical test runs like this:
- Map every role. The tester lists each user type, from anonymous visitor to super admin, and what each one should be able to do.
- Create at least two accounts per role. Two normal users catch horizontal flaws like IDOR. A normal user and an admin catch vertical ones.
- Capture every request. Using a proxy such as Burp Suite, the tester records each action as the higher-privileged user.
- Replay with the wrong identity. Each request is sent again with the other account's session, a lower role's session, or no session at all. Extensions like Autorize speed this up.
- Tamper with identifiers. IDs, tenant values, role fields, and token claims are changed one at a time to see what the server accepts.
- Check the edges. Old API versions, mobile endpoints, export features, and file downloads often skip the checks the main app enforces.
How Do You Prevent Broken Access Control?
- Deny by default. Every route and every object should be blocked unless a rule explicitly allows access.
- Check on the server, every time. The frontend can hide buttons, but only the backend can enforce permissions.
- Use one shared authorization layer. Checks scattered across hundreds of controllers are where gaps appear.
- Tie records to their owner. Filter queries by the current user or tenant from the session, not from the request.
- Use random, unguessable IDs. UUIDs don't fix IDOR, but they stop attackers from scripting through every record.
- Log and alert on denied requests. A spike in access errors from one account usually means someone is probing.
- Write access tests. Add unit and integration tests that confirm User A can't read User B's data, so a future change can't quietly break it.
How OraSec Can Help
OraSec's testers hunt for broken access control by hand on every engagement, using multiple accounts per role and replaying each request with the wrong identity. That's how IDOR, cross-tenant leaks, and role tampering get caught before an attacker finds them. The team's own research has produced published CVEs (CVE-2025-50847 through CVE-2025-50850), so the people testing your app also find new flaws for a living.
A web application security test from OraSec covers the full OWASP Top 10, with authorization testing across every role, API, and tenant boundary. Each finding comes with proof, steps to reproduce, and a fix your developers can apply, followed by a retest to confirm the gap is closed.
Conclusion
Broken access control is simple to explain and easy to miss. All six examples above come back to the same gap: the server trusted the request instead of checking who sent it and what they own. That gap exposed 885 million documents at First American and about 10 million customers at Optus. Scanners won't flag it, because the traffic looks normal. Test your app with real accounts at every permission level, fix what turns up with server-side checks, and retest after each major release so new features don't reopen old holes.
Frequently Asked Questions
Is IDOR the same as broken access control?
IDOR is one type of broken access control. The category also covers privilege escalation, missing function-level checks, token tampering, and SSRF.
What is the difference between broken authentication and broken access control?
Authentication checks who you are. Access control checks what you're allowed to do once you're logged in.
What is horizontal vs. vertical privilege escalation?
Horizontal means reaching another user's data at your own level. Vertical means gaining a higher role, such as a normal user acting as an admin.
How severe is a broken access control finding?
It's usually rated high or critical when it exposes personal, financial, or cross-tenant data. A penetration testing report example shows how these findings are rated and written up.
Do random IDs like UUIDs fix IDOR?
No. They make IDs harder to guess, but the server still has to check that the record belongs to the user asking for it.
How often should you test for broken access control?
After any release that changes roles, permissions, or APIs, and at least once a year as part of a full pentest.
