Broken Access Control Explained: How IDOR Bugs Are Found and Fixed

Key takeaways

• Broken Access Control is OWASP Top 10 A01:2021, and IDOR is its common form, where changing an ID returns someone else's record.
• Fix it on the server by checking ownership and permissions on every request, since hiding links or using hard-to-guess IDs is not enough.
• Test only inside an authorised programme's scope and report responsibly, because unauthorised testing in India can breach the IT Act, 2000.

This article explains how Broken Access Control works, how authorised testers find it, and, most importantly, how developers prevent it. It describes patterns and defences at a conceptual level. It does not provide a ready-to-run attack against any real system, and all testing must stay inside an authorised programme's scope.

What is Broken Access Control?

Broken Access Control happens when an application fails to enforce what an authenticated user is allowed to do. The user is logged in, but the server does not properly check whether this user may see or change this resource. OWASP ranks it first in the OWASP Top 10 (A01:2021), because it is both common and high impact: it can expose personal data, financial records or admin functions.

Access control comes in two directions:

• Horizontal: reaching another user's data at the same privilege level, such as reading a different customer's support ticket.
• Vertical: gaining a higher privilege level, such as a normal user calling an admin-only function.

What is IDOR, and how is it related?

Insecure Direct Object Reference (IDOR) is the most common form of Broken Access Control. The application exposes a direct reference to an object, usually a number or a predictable ID, and trusts the client to only request objects it owns.

Consider two endpoints in the same fintech-style API:

GET /api/v1/user/{id}/tickets # checks ownership, returns 403 for others
GET /api/v1/tickets/view?ticket_id={id} # forgets to check ownership

The first route verifies that the logged-in user owns the record and refuses others. The second does not. Because the same application protects one path but not the other, a tester who tries alternate routes to the same data can reach records belonging to other users. The flaw is not the numeric ID itself; it is the missing server-side ownership check on the second route.

This is why "security through obscurity", such as hiding IDs or relying on the front end to grey out a button, never works. Anything the browser can send, an attacker can send too.

How do authorised testers find it?

On a bug bounty platform such as HackerOne or Bugcrowd, a researcher works only within a programme's published scope and rules. The method is methodical, not magic:

1. Map the application. Log in with a test account and record the API routes the app uses, including different versions or alternate paths to the same feature.
2. Note every object reference. IDs in URLs, query strings, request bodies, headers and cookies are all candidates.
3. Use two accounts. Most legitimate access-control testing compares what account A and account B can each reach, using only the tester's own accounts, so no real third party's data is touched.
4. Check each route rather than a single one. A feature protected on its main endpoint is often unprotected on an older or secondary one.
5. Observe the response. A 403 means the check works; a 200 with another account's data means it does not.

Tools used for this are the same ones used for all web testing: an intercepting proxy such as Burp Suite, an API client such as Postman (see our guide to API penetration testing with Postman), and the browser's developer tools. The skill is in understanding the application's authorisation logic, not in running a script.

Responsible testers stop as soon as they have a minimal proof that the check is missing. They do not enumerate large ranges of real users' records, because that would expose real people's data and usually breaches the programme's rules and the law.

How is a finding reported responsibly?

A good report helps the vendor reproduce and fix the issue quickly. It typically includes:

The programme's triage team validates the report, assigns a severity, and the vendor patches. Bounty amounts and timelines vary widely by programme and severity, so treat any single figure you read online as one example, not a norm.

How do developers prevent Broken Access Control?

This is the part that matters most, because the fix is entirely in the application's hands. Follow these principles:

• Deny by default. Every endpoint should reject access unless a rule explicitly allows it. New routes inherit "no access" rather than "open".
• Check ownership on the server for every request. For each object a request touches, confirm the authenticated user is allowed to act on that specific object; being logged in is not enough.
• Enforce authorisation in one place. Centralise access decisions in middleware or a policy layer so no single forgotten handler can leak data. Scattered, per-controller checks are where gaps appear.
• Do not trust client-side controls or tokens blindly. A JWT may carry a role claim, but the server must still verify the claim and the ownership of each resource on every call.
• Prefer indirect references where practical. Mapping external IDs to the user's own session-scoped list reduces exposure, though it never replaces a real authorisation check.
• Apply least privilege. Give each role the minimum it needs, and separate admin functions from user functions.
• Log and alert on access-control failures. Repeated 403s or sudden access to many records are signals worth monitoring.
• Test for it continuously. Add automated checks that account A cannot reach account B's resources, and include access control in code review and CI.

Common developer mistakes that cause it

• Protecting the main endpoint but forgetting an older or internal API version.
• Checking only that the user is authenticated, not that they own the resource.
• Relying on the front end to hide buttons or fields instead of enforcing rules on the server.
• Trusting IDs or roles sent by the client without server-side verification.
• Using predictable sequential IDs without any ownership check behind them.

A note on legality in India

Testing an application you do not own, or going beyond a programme's scope, can breach India's Information Technology Act, 2000, even if you intend no harm. Only test systems you own, lab targets you have built, or targets inside an authorised bug bounty programme whose rules you follow. Keep evidence minimal and never access more real user data than needed to prove the point.

Next step

If you are learning application security, set up a deliberately vulnerable lab app (such as OWASP Juice Shop) and practise finding and then fixing an IDOR, so you understand both sides. To go further with structured, authorised practice, see our guide to getting started with penetration testing or structured web application security training.

Related reading

• What is an example of a real bug bounty report where IDOR was used to exploit a banking application?
• What is Bug Bounty in 2026 and How Can You Earn with Real-World Hacking Skills?
• What is IDOR Vulnerability? Insecure Direct Object Reference Attack Explained with Real Examples