Playground.

Broken Access Control

Access rules aren't properly enforced, letting users do things that should be outside their permissions.

Beginner± 20 minAvailable

A01.1

What is Broken Access Control?

Access control decides who is allowed to do what. When those rules are loose or missing entirely, an attacker can open other people's accounts, read sensitive data, modify records, or run admin-only functions without permission. OWASP ranks it number one because it is the flaw found most often in real applications.

A01.2

IDOR: the most common form

IDOR (Insecure Direct Object Reference) happens when an app uses an id from user input to pull data straight from the database without checking that the data actually belongs to that user. Imagine opening /account?id=123 and changing it to /account?id=124. A vulnerable server still returns the data because it never asks, 'does this id belong to the logged-in user?' Try it yourself in the Vulnerable Demo tab.

A01.3

Impact

Leaked user data, account takeover, privilege escalation to admin, and even tampering with the entire application's data. Because the root cause sits in authorization logic, a single careless endpoint is enough to expose every user's data.

A01.4

How to prevent it

Enforce authorization checks on the server for every request, not just by hiding a button in the UI. Deny by default, then allow only when the user is genuinely entitled to the requested object. Never rely on a guessable id as the only gatekeeper. The Fixed Demo tab shows the single ownership check that closes this gap.

A01.5

Real-world example

Many large data breaches start from IDOR: swapping an invoice number, order id, or profile id in the URL to open someone else's. The bug class is simple, but the impact can be enormous when the affected endpoint serves millions of users.