Broken Access Control — The #1 Vulnerability on the Web

Broken Access Control — The #1 Vulnerability on the Web 🔓 | by loopXvedant - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original Broken Access Control — The #1 Vulnerability on the Web 🔓 The bug that lets you walk into rooms you were never supposed to enter. loopXvedant Follow ~6 min read · March 24, 2026 (Updated: March 24, 2026) · Free: Yes There's a moment every bug bounty hunter experiences. You're testing an application. You change a number in a URL — maybe ?id=101 to ?id=100 . And suddenly you're looking at someone else's data. Their name. Their email. Their order history. That feeling — equal parts excitement and disbelief — is what Broken Access Control looks like in the real world. It's not glamorous. There's no complex exploit chain. You just changed a number. And it worked. Broken Access Control has been the #1 vulnerability on the OWASP Top 10 since 2021. It's everywhere. And once you know what to look for, you'll start seeing it in places that genuinely surprise you. Here's everything you need to know. 🔓 What Is Broken Access Control? Access control is the system that decides who can access what. Regular users can see their own profile — not other people's. Admins can access the admin panel — regular users can't. Premium users can access premium features — free users can't. Broken Access Control happens when these restrictions fail. When the application doesn't properly enforce who can do what — users can access data, functions, or pages they were never supposed to reach. It's not about breaking encryption or bypassing firewalls. It's about the application simply not checking whether you're allowed to do what you're doing. 🔢 Subtype #1 — IDOR (Insecure Direct Object Reference) IDOR is the most commonly found type of Broken Access Control — and one of the most beginner-friendly bugs to hunt. What it is: When an application uses a user-controlled value (like an ID in a URL) to directly reference an object — and doesn't check whether the current user is allowed to access that object. Classic example: You log in and your profile URL is: https://target.com/profile?user_id=1042 You change 1042 to 1041 : https://target.com/profile?user_id=1041 And you're now viewing someone else's profile. Full name, email, phone number — all exposed. That's IDOR. Where to find IDOR: Profile and account pages Order and invoice pages ( /invoice?id=5523 ) File downloads ( /download?file_id=882 ) API endpoints ( /api/users/1042 ) Message and notification systems What to change: Numeric IDs ( 101 → 100 , 99 , 102 ) UUIDs (harder but sometimes still vulnerable — try other users' UUIDs) Usernames or emails in parameters Base64 encoded values (decode, modify, re-encode) Pro tip: Create two accounts on the same application. Use Account A to find object IDs. Use Account B to try accessing those IDs. If B can access A's data — that's a confirmed IDOR. 🔗 Subtype #2 — Forced Browsing & URL Manipulation Sometimes restricted pages exist — they're just not linked from anywhere. Forced browsing means navigating to those pages directly by guessing or constructing the URL. What it looks like: You're a regular user. You notice the URL structure: https://target.com/user/dashboard You try: https://target.com/admin/dashboard https://target.com/admin/users https://target.com/admin/settings If any of these load without redirecting you away — that's Broken Access Control. The admin pages exist and are accessible — the application just never linked to them from the regular user interface. Other things to try: /admin /administrator /manage /moderator /internal /staff /superuser /debug /config /backup Parameter manipulation: ?role=user → ?role=admin ?access=free → ?access=premium ?debug=false → ?debug=true ?isAdmin=false → ?isAdmin=true Sometimes applications make access control decisions based on parameters that the user controls — which is an immediate vulnerability. ⚙️ Subtype #3 — Missing Function Level Access Control This is similar to forced browsing but specifically about functions — actions the application can perform — rather than just pages. What it looks like: A regular user can view other users. But can they delete them? Can they edit their roles? Can they export all user data? These administrative functions might exist in the backend even if the button isn't shown in the UI to regular users. How to find it: Intercept requests in Burp Suite while using the application normally Look for API calls that perform actions: DELETE /api/users/101 , PUT /api/users/101/role Try sending those same requests as a regular user — does the server reject them? Look at JavaScript files — they often contain API endpoints and function calls that aren't exposed in the UI Real example: A regular user account intercepts a request to view their profile: GET /api/users/1042 They modify it to: DELETE /api/users/1041 If the server processes the deletion — that's a critical missing function level access control vulnerability. ↕️ Subtype #4 — Privilege Escalation Privilege escalation happens when a user gains access to a higher privilege level than they're supposed to have. There are two types: Horizontal Privilege Escalation: Accessing resources belonging to another user at the same privilege level . Example: User A accessing User B's private messages. Both are regular users — but A can read B's data. This is essentially what IDOR does. Vertical Privilege Escalation: Gaining access to higher privilege functions — going from regular user to admin. Example: A regular user accessing the admin panel, changing other users' roles, or performing administrative actions. How to test for it: Log in as a regular user Capture an admin-only request (from documentation, JS files, or a second admin account you control) Replay that request with your regular user's session token If the server processes it — vertical privilege escalation confirmed Things to look for in requests: "role": "user" → "role": "admin" "isAdmin": false → "isAdmin": true "tier": "free" → "tier": "enterprise" If these values are sent from the client and trusted by the server without verification — attackers can manipulate them. 🔌 Subtype #5 — API Access Control Bypass Modern applications are heavily API-driven — and APIs often have weaker access control than the main web interface. Why APIs are often more vulnerable: APIs are built quickly and security is an afterthought API endpoints are less visible than web pages Developers assume APIs won't be accessed directly Different teams build the frontend and backend — communication gaps lead to missed access checks How to find API access control issues: Step 1 — Discover API endpoints: Monitor network requests in DevTools while using the app Check JavaScript files for hardcoded endpoints Use tools like ffuf to brute-force common API paths Check the Wayback Machine for old API documentation Step 2 — Test access without authentication: GET /api/v1/users → returns list of all users? GET /api/v1/admin/config → returns config without auth? Step 3 — Test with a lower-privilege token: Perform actions as a regular user that should require admin access. Send the requests with your regular session token and see if the server enforces the restriction. Step 4 — Test older API versions: /api/v1/users → properly secured /api/v2/users → current version Older API versions ( v1 , v2 ) sometimes have weaker security than the current version — and they're often still active. 🛠️ My Testing Checklist for Broken Access Control Here's exactly what I do when testing for Broken Access Control: Setup: Create at least two accounts (different privilege levels if possible) Use Burp Suite to intercept and log all requests Note every URL, parameter, and ID you encounter Testing: Change numeric IDs in URLs and parameters Try accessing admin/internal paths directly Manipulate role/permission parameters in requests Test API endpoints with a lower-privilege token Try older API versions Attempt admin functions with a regular user session Check if access control is enforced on both GET and POST requests Test what happens when you remove authentication headers entirely Confirm with two accounts: Always confirm IDOR findings by accessing Account A's resources from Account B's session. This proves the vulnerability without ambiguity. 🏁 Final Thoughts Broken Access Control is the #1 vulnerability on the web for a reason. It's not technically complex. It doesn't require advanced knowledge. It requires curiosity, methodology, and the habit of asking one simple question every time you see a URL or parameter: "What happens if I change this?" That question — asked consistently, on every target — is what finds Broken Access Control bugs. And it's what found my first real vulnerability too. Start asking it. You'll be surprised how often the answer is interesting. 🔓 Found this useful? Follow for more bug bounty and cybersecurity content. Drop a comment on the most surprising place you've found an access control bug. 🙌 ⚠️ Disclaimer: All techniques in this blog are for educational purposes and authorized security testing only. Always test on systems you have permission to test. Practice on platforms like PortSwigger Web Academy, TryHackMe, and HackTheBox. ☕ Support My Work If you enjoy my content, you can buy me a coffee here: Buy me a Coffee #broken-access-control #owasp-top-10 #bug-bounty #cybersecurity #hacking Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).