C

Web › Module 3 › Lesson 4

BeginnerModule 3Lesson 4/6

IDOR

Insecure Direct Object References—when changing an ID in the URL gives you someone else’s data

15 min+56 XP3 quiz
Module progress4 of 6

Visual · web_developer

IDOR happens when the app exposes internal object IDs but never checks whether you are allowed to access that specific object.

Opening

Same page, different number—different person’s invoice

You open /api/orders/1042 and see your receipt. You change it to /api/orders/1043 and see your neighbor’s order. That is IDOR—Insecure Direct Object Reference. You are authenticated, but authorization failed. It is one of the simplest bugs to explain and one of the most common in APIs.

1. Authentication vs Authorization Here

Authentication answers “Who are you?” Authorization answers “Are you allowed to do this on this object?” IDOR is an authorization failure. The app trusts that if you know an ID, you must own it. Attackers enumerate IDs—incrementing numbers, UUID leaks, or predictable patterns.

2. Where IDOR Shows Up

  • REST paths

    /users/17/profile, /documents/abc/download

  • Hidden form fields

    <input type="hidden" name="account_id" value="9001">

  • GraphQL

    Query by ID without server-side ownership checks on the resolver.

  • File storage keys

    Predictable S3 object names like uploads/user_5/report.pdf

3. Vulnerable vs Fixed Pattern

Check ownership on every object access# BAD — only checks login @app.get("/invoice/{id}") def get_invoice(id, user=Depends(current_user)): return db.invoices.find(id) # BETTER — verify the invoice belongs to this user def get_invoice(id, user=Depends(current_user)): inv = db.invoices.find(id) if inv.owner_id != user.id: raise HTTPException(403) return inv

# BAD — only checks login
@app.get("/invoice/{id}")
def get_invoice(id, user=Depends(current_user)):
    return db.invoices.find(id)

# BETTER — verify the invoice belongs to this user
def get_invoice(id, user=Depends(current_user)):
    inv = db.invoices.find(id)
    if inv.owner_id != user.id:
        raise HTTPException(403)
    return inv

Use non-guessable IDs—but still authorize

UUIDs reduce casual guessing but do not replace access checks. Leaked links, logs, and referrers still expose IDs. Always enforce policy server-side.

Knowledge Check

1

IDOR is best described as:

Multiple choice

Knowledge Check

2

True or False: Using UUIDs alone prevents IDOR without server-side checks.

True or False

Knowledge Check

3

The correct fix for IDOR is to:

Multiple choice

← Previous

Answer all 3 knowledge checks to continue. (0/3 answered)