What is Broken Access Control? Learn the Basics

Where Can We Find It?

Broken Access Control happens when an application fails to properly enforce user permissions, allowing unauthorized access to restricted data or actions. You can find this issue in:

Web applications (Dashboard, Admin Panels, APIs)
Mobile applications (Insecure endpoints, misconfigured permissions)
APIs (Exposed endpoints that allow unauthorized actions)

How It Works?

Access control ensures that users can only access what they are authorized to. When it is broken, attackers can:
✅ View sensitive data of other users (Insecure Direct Object References - IDOR)
✅ Modify or delete someone else's data
✅ Access admin functionalities as a normal user
✅ Escalate privileges (e.g., become an admin)

Example:
Imagine a bank website where users access their accounts with a URL like this:
🔹 https://bank.com/account?userID=1234
If changing userID=5678 loads someone else’s account, that's Broken Access Control (IDOR attack)!

Types of Broken Access Control & Examples

1️⃣ IDOR (Insecure Direct Object Reference)

A user can modify a request to access unauthorized data.
Example: Changing the userID in a URL and getting another user’s details.

2️⃣ Privilege Escalation

A normal user gains admin privileges.
Example: If an application only hides the "Admin Panel" button but doesn't check backend permissions, a user can still access it by typing the admin URL directly.

3️⃣ Forced Browsing

Accessing restricted pages directly.
Example: If https://example.com/admin is accessible to normal users without authentication.

4️⃣ CORS Misconfiguration

A weak CORS policy allows unauthorized cross-origin requests.
Example: A banking app allows requests from any domain, leading to data theft.

How to Mitigate It?

🔒 1. Enforce Proper Access Control Checks

Implement role-based access control (RBAC).
Every API request should verify who is making the request and what they are allowed to do.

🔒 2. Secure Direct Object References (IDOR)

Use indirect identifiers (e.g., UUIDs instead of sequential numbers like userID=123).
Check permissions before returning sensitive data.

🔒 3. Disable Directory Listing & Protect Admin Endpoints

Make sure admin pages and sensitive directories are not accessible to normal users.

🔒 4. Implement Proper Session Management

Ensure session tokens are not predictable.
Use secure cookies (HttpOnly, Secure, SameSite).

🔒 5. Audit & Log Access Attempts

Detect suspicious access patterns (e.g., multiple unauthorized access attempts).

🔒 6. Use Security Headers & CORS Properly

Restrict Access-Control-Allow-Origin to trusted domains.
Implement Content Security Policy (CSP).

Real-World Case Study: Facebook IDOR Vulnerability (2015)

What Happened?

A security researcher discovered a Broken Access Control (IDOR) vulnerability in Facebook’s "Support Dashboard."

How It Worked?

The researcher noticed that when a user submitted a report (like reporting an inappropriate post), it generated a unique case ID in the request.
By modifying the case ID, the researcher was able to access other users’ reports, including private details, emails, and sensitive information.
Facebook failed to check whether the logged-in user actually owned the case before displaying the data!

Impact:

Any attacker could view personal information of millions of users just by iterating over case IDs.
Could have led to privacy breaches, targeted attacks, and phishing attempts.

How Facebook Fixed It?

✅ Implemented proper authorization checks to ensure only the report owner could access their case.
✅ Used UUIDs instead of sequential case IDs, making enumeration attacks harder.
✅ Rewarded the researcher with $7,500 under their bug bounty program.

Lesson: If your app references user-specific data in requests, always verify permissions on the backend! 🚀