Broken Access Control and IDOR

Broken Access Control: When the Server Forgets to Check Permissions

Broken access control is the #1 risk in the OWASP Top 10 2021. It occurs when a user can act outside their intended permissions — accessing other users' data, performing privileged actions, or viewing restricted pages. The root cause is almost always the same: the server authenticates the user (verifies identity) but fails to authorize the specific action (verify permission).

Authentication vs. Authorization

These two terms are frequently confused but serve fundamentally different purposes:

Authentication (AuthN) answers: "Who are you?" It verifies the user's identity through credentials (passwords, tokens, biometrics). After authentication, the server knows which user is making the request.

Authorization (AuthZ) answers: "Are you allowed to do this?" It verifies whether the authenticated user has permission to perform the requested action on the requested resource.

A system can have strong authentication and zero authorization. For example, a login page that correctly verifies usernames and passwords but then allows any logged-in user to access any other user's data by changing an ID in the URL.

What Is IDOR?

Insecure Direct Object Reference (IDOR) is the most common manifestation of broken access control. It occurs when an application exposes a reference to an internal object (database record, file, key) and the server fails to verify that the user is authorized to access that specific object.

Vulnerable code:

@app.route('/api/orders/<order_id>')
def get_order(order_id):
    user = get_current_user()  # Authenticated
    order = db.query(f"SELECT * FROM orders WHERE id = {order_id}")
    return jsonify(order)  # No authorization check!

An authenticated user can change order_id from 1001 (their own order) to 1002 (another user's order) and the server returns it.

Why IDOR Is So Prevalent

1. Developers assume obscurity is security: "The IDs are sequential, but users won't guess other IDs." Attackers do guess — it is trivial.
2. Client-side checks are trusted: A UI may hide admin buttons from non-admin users, but the server does not enforce the same restriction.
3. Object-level checks are forgotten: Developers check authentication at the login endpoint but forget to check authorization at every object access endpoint.
4. API endpoints are overlooked: REST APIs often expose object references without the same authorization logic as the web UI.

Real-World Impact

IDOR has been responsible for numerous high-profile breaches:

• Facebook (2018): An IDOR vulnerability allowed attackers to access any user's phone number by manipulating an API parameter.
• Equifax (2017): While not purely IDOR, the breach involved accessing records the attacker was not authorized to view.
• Uber (2016): An IDOR flaw allowed drivers to view other drivers' earnings and personal information.

The Principle of Complete Mediation

The security principle that prevents IDOR is complete mediation: every access to every object must be checked against the access control policy. There are no exceptions, no "trusted" internal calls, and no assumptions about how the user arrived at the request.

Fixing IDOR with Object-Level Authorization Checks

The fix for IDOR is conceptually simple — check authorization on every object access — but requires discipline to implement consistently across an entire application.

The Authorization Check Pattern

Every endpoint that accesses a specific object must verify that the current user is authorized to access that object:

@app.route('/api/orders/<order_id>')
def get_order(order_id):
    user = get_current_user()
    order = db.query(f"SELECT * FROM orders WHERE id = {order_id}")
    
    # Authorization check — verify ownership
    if order.user_id != user.id:
        return jsonify({'error': 'Forbidden'}), 403
    
    return jsonify(order)

This single check transforms a vulnerable endpoint into a secure one. The key is that the check happens on the server, every time, for every object.

Role-Based Access Control (RBAC)

For applications with distinct user roles (user, moderator, admin), implement role-based checks:

@app.route('/api/admin/users/<user_id>/delete', methods=['DELETE'])
def delete_user(user_id):
    user = get_current_user()
    
    # Role check
    if user.role != 'admin':
        return jsonify({'error': 'Admin access required'}), 403
    
    # Proceed with deletion
    db.delete_user(user_id)
    return jsonify({'status': 'deleted'})

Attribute-Based Access Control (ABAC)

For more complex scenarios, attribute-based access control evaluates multiple attributes (user role, resource ownership, time of day, location, etc.):

def can_access_order(user, order):
    # Owner can always access
    if order.user_id == user.id:
        return True
    # Support team can access during business hours
    if user.role == 'support' and is_business_hours():
        return True
    # Admin can always access
    if user.role == 'admin':
        return True
    return False

Why Unpredictable IDs Are Not Enough

A common misconception is that using UUIDs or random IDs instead of sequential integers prevents IDOR. It does not:

1. IDs leak through other channels: API responses, referrer headers, browser history, and logs all expose object IDs.
2. IDs can be brute-forced: A UUIDv1 contains timestamp information. Even UUIDv4 can be guessed if the attacker has access to any other user's ID (they can infer the ID space).
3. Security through obscurity fails: Relying on the secrecy of an identifier is not a security control. The server must enforce authorization regardless of how the ID was obtained.

Unpredictable IDs are a useful defense-in-depth measure (they make enumeration harder), but they must never replace authorization checks.

Testing for IDOR

To test for IDOR, follow this methodology:

1. Create two accounts: Account A (low privilege) and Account B (different user or higher privilege).
2. Identify object references: Note every ID in URLs, request parameters, and API responses.
3. Swap IDs: Make requests to Account A's endpoint but replace Account A's object IDs with Account B's object IDs.
4. Verify the response: If the server returns Account B's data, the vulnerability exists.

# Account A requests their own order
curl -H "Cookie: session=A" https://api.example.com/orders/1001
# Returns order 1001 (expected)

# Account A requests Account B's order
curl -H "Cookie: session=A" https://api.example.com/orders/1002
# If this returns order 1002's data, IDOR exists

Practice: Find the IDOR

Review this code and identify the vulnerability:

@app.route('/api/documents/<doc_id>')
def download_document(doc_id):
    user = get_current_user()
    document = Document.query.get(doc_id)
    
    if not document:
        return jsonify({'error': 'Not found'}), 404
    
    return send_file(document.file_path)

The vulnerability: there is no check that document.owner_id == user.id. Any authenticated user can download any document by guessing or enumerating document IDs. The fix is to add an ownership check before serving the file.