IDOR & Access Control

What Is Access Control? #

Access control enforces which users can perform which actions on which resources. Every request to a protected resource must answer three separate questions:

The critical insight: authentication and authorization are separate checks. An application can perfectly verify that a user is logged in (authentication) while completely failing to check whether that logged-in user is allowed to touch the specific record they requested (authorization). This is the root cause of IDOR.

IDOR — The Core Concept #

IDOR (Insecure Direct Object Reference) occurs when an application uses a user-supplied identifier to look up an internal object and fails to verify that the requesting user is authorized to access that object.

The canonical IDOR pattern// Authenticated as User A (session cookie = Alice's JWT)

GET /api/invoices/1001           → 200 OK — Alice's invoice ✓

GET /api/invoices/1002           → 200 OK — Bob's invoice ✗  ← IDOR

// The server asked: "Is Alice logged in?" → YES → return record 1002
// The server never asked: "Does Alice OWN record 1002?"

// Vulnerable backend pseudocode:
if session.is_authenticated:
    return db.orders.get(id=request.id)  ← ownership never checked

// Secure backend pseudocode:
if session.is_authenticated:
    return db.orders.get(id=request.id, user_id=session.user_id)

Full Taxonomy #

IDOR on Write Operations — Highest Severity

Most hunters test GET requests only. Write-operation IDOR is far more impactful and far less tested:

Where IDs Live — Full Surface Map #

Beginners check the URL path. Professionals check every location below. Object references can appear in at least nine distinct locations — test all of them before concluding a parameter doesn't exist.

/api/users/42/profile
/api/orders/1001/invoice
/files/report-2024.pdf

?user_id=42
?account=7a3b
?file=invoice_1001.pdf

{"order_id": 1001}
{"recipient": 42}
{"from_account": "ACC-001"}

<input type="hidden"
  name="user_id"
  value="42">

user_id=42
account_ref=ACC-001
role=user

X-User-ID: 42
X-Account-ID: ACC-001
X-Tenant-ID: 7

query {
  user(id: 42) {
    email, privateData
  }
}

{"action":"get_data",
 "user_id": 42,
 "type": "messages"}

/exports/user_42_2024.csv
/receipts/receipt_43.pdf
No explicit ID — pattern is the ID

ID Formats — Don't Stop at Sequential Numbers #

Beginners give up when they don't see an obvious integer. These are all testable ID formats:

Access Control Bypasses — Beyond IDOR #

Forced Browsing

Directly navigating to URLs that should be restricted, bypassing the intended navigation flow. The application relies on the assumption that you don't know the URL.

Forced Browsing — Path and case variations/admin                → 403 Forbidden
/Admin                → 200 OK     (case sensitivity bypass)
/admin/               → 200 OK     (trailing slash)
/admin.php            → 200 OK     (extension variation)
/ADMIN                → 200 OK     (uppercase)
/admin%20             → 200 OK     (encoded space)
/./admin              → 200 OK     (path confusion)
/robots.txt           → reveals /admin-panel-v2-secret/   (info leak)
/sitemap.xml          → reveals /internal/reporting/      (info leak)
/.git/                → source code exposed               (critical)

Parameter-Based Access Control

Some applications store the user's role or privilege level in a request parameter or cookie that the server trusts without re-validating against the server-side session.

Parameter-Based — Client-controlled privilege// Role stored in cookie — modify directly in browser DevTools:
Cookie: role=user    →    Cookie: role=admin

// Role in query parameter:
GET /dashboard?admin=false   →   GET /dashboard?admin=true

// Role in POST body (mass assignment):
POST /api/user/profile
{"name":"Alice", "role":"user"}

→ {"name":"Alice", "role":"admin", "is_verified":true, "balance":9999}

Referer-Based Access Control

Some applications check the Referer header to validate that a request originated from a legitimate admin page. This is completely bypassable — the Referer header is client-controlled.

Referer Bypass// App expects admin action to come from admin dashboard:
Referer: https://app.com/admin/dashboard

// Attacker manually adds this header to any request:
GET /admin/delete-user/42 HTTP/1.1
Host: app.com
Referer: https://app.com/admin/dashboard   ← spoofed

// Server grants access based on Referer alone → user deleted

HTTP Method Switching

Access control applied to one HTTP method but not others — a very common oversight.

Method-Based Access Control BypassGET    /admin/users   →  403 Forbidden
POST   /admin/users   →  403 Forbidden
HEAD   /admin/users   →  200 OK      ← headers returned, confirms endpoint exists
TRACE  /admin/users   →  200 OK

// More dangerous pattern:
POST   /admin/delete-user/42  →  403 Forbidden
DELETE /admin/delete-user/42  →  200 OK      ← DELETE not in WAF ruleset

// Method override headers (tunnel DELETE inside POST):
POST /admin/delete-user/42
X-HTTP-Method-Override: DELETE

Multi-Step Flow Bypass

Access control checks happen at step 1 of a flow but are forgotten at step 2 or step 3.

Multi-Step Access Control Gap// Checkout flow:
Step 1: GET  /checkout/1001/confirm   → validates ownership ✓
Step 2: POST /checkout/1001/pay       → validates ownership ✓
Step 3: GET  /checkout/1001/receipt   → no validation ✗

// Attacker skips to step 3 with a different order ID:
GET /checkout/1002/receipt   →  200 OK — another user's receipt returned

Mass Assignment

When an API passes the entire request body to an ORM without filtering which fields are updatable, attackers can modify fields they shouldn't be able to touch.

Mass Assignment — Privilege field injection// Legitimate profile update:
PATCH /api/user/profile
{"name": "Alice", "email": "alice@email.com"}

// Attacker adds privileged fields:
PATCH /api/user/profile
{
  "name": "Alice",
  "email": "alice@email.com",
  "role": "admin",
  "is_verified": true,
  "subscription_tier": "enterprise",
  "account_balance": 99999
}

// If ORM applies all fields without whitelist → all fields updated in DB
// Common in: Rails (strong_params), Laravel ($fillable), Django serializers

The Two-Account Testing Methodology #

This is the professional standard. It produces clean, unambiguous proof that no triage team can dispute — and it ensures you never accidentally access real user data.

Real-World Bug Bounty Patterns #

Tooling — Burp Suite + Autorize #

Burp Intruder — ID Fuzzing

Burp Intruder config for sequential ID space fuzzing// Target request in Burp Intruder:
GET /api/orders/§1001§ HTTP/1.1
Host: app.example.com
Cookie: session=ACCOUNT_A_SESSION

// Payload type: Numbers
// From: 1000   To: 2000   Step: 1
// Filter: Status 200 AND Response length > 100
// Review each 200 — check if it's your data or another user's

Autorize — Automated IDOR Detection

Autorize Burp Extension — workflow// 1. Install Autorize from Burp BApp Store
// 2. Configure Account B's session cookie in Autorize settings
// 3. Browse the application as Account A (normally)
// 4. Autorize auto-replays every request with Account B's cookie
// 5. Flags responses where:
//    → Account B gets same response as Account A (no access control)
//    → Status code is 200 (not 403 or 401)
//    → Response length matches (same data returned)
// 6. Review flagged requests — each is a potential IDOR

// Color codes in Autorize output:
GREEN   → Access enforced (different response for Account B)
RED     → Potential IDOR (same response regardless of account)
ORANGE  → Bypassed (Account B got access with modified request)

What a Paid IDOR Report Looks Like #

Prevention — The Correct Fix #

Vulnerable vs Secure — Python Flask example# VULNERABLE — authentication only, no ownership check:
@app.route('/api/orders/<int:order_id>')
@login_required
def get_order(order_id):
    order = Order.query.get(order_id)  ← fetches any order by ID
    return jsonify(order)              ← no ownership validation

# SECURE — ownership enforced at the database query layer:
@app.route('/api/orders/<int:order_id>')
@login_required
def get_order(order_id):
    order = Order.query.filter_by(
        id=order_id,
        user_id=current_user.id   ← both ID and owner must match
    ).first_or_404()               ← 404 if not found OR not owned
    return jsonify(order)

Interactive Lab — Access Control Sandbox #

Five lab modes. Each simulates a different access control failure class. Switch your active session identity and manipulate request parameters to trigger the IDOR conditions.

Chapter 9 — Operational Drills #