A01 — Broken Access Control

By the end of this lesson you can:

• Explain IDOR and missing function-level access control.
• Recognise vulnerable code that trusts the client to enforce access.
• Apply the fix: verify ownership and role server-side on every request.
• Adopt "deny by default" and never rely on hidden UI for security.

You're logged in and view your invoice at /invoice?id=123. Out of curiosity you change it to 124 — and you're looking at someone else's invoice. No hacking tools, just a different number. That's Insecure Direct Object Reference (IDOR), and it's shockingly common.

Authentication vs. authorization

AUTHENTICATION  "who are you?"      → login proves identity
AUTHORIZATION   "are you allowed?"  → checks permission for THIS action
Broken access control = authentication present, authorization missing/wrong.

The two big failure modes

• IDOR — an endpoint takes an object id and returns it without checking you own it: /api/orders/124 returns order 124 regardless of whose it is.
• Missing function-level control — an admin action (/admin/delete-user) isn't protected by a role check, so any logged-in user (or anyone) can call it directly.

Vulnerable code (the trap)

# VULNERABLE — trusts the id, never checks ownership (IDOR)
@app.get("/invoice/<int:invoice_id>")
def view_invoice(invoice_id):
    invoice = db.get_invoice(invoice_id)      # fetches ANY invoice by id
    return render(invoice)                    # no "is this MINE?" check!

# VULNERABLE — admin route with no role check
@app.post("/admin/delete-user/<int:user_id>")
def delete_user(user_id):
    db.delete_user(user_id)                   # any caller can delete anyone!
    return "deleted"

Both "work" in the UI because the UI only links to your own invoices and hides the admin button from non-admins. But the endpoints enforce nothing — and that's all an attacker touches.

The fix: verify ownership and role, server-side

# FIXED — check the object belongs to the current user
@app.get("/invoice/<int:invoice_id>")
@login_required
def view_invoice(invoice_id):
    invoice = db.get_invoice(invoice_id)
    if invoice is None or invoice.owner_id != current_user.id:
        abort(404)                            # 404, not 403 — don't reveal it exists
    return render(invoice)

# FIXED — require the admin role for admin actions
@app.post("/admin/delete-user/<int:user_id>")
@login_required
@require_role("admin")                        # deny by default unless admin
def delete_user(user_id):
    db.delete_user(user_id)
    return "deleted"

• Ownership check — invoice.owner_id != current_user.id → abort. The server decides, not the URL.
• Role check — a @require_role decorator on privileged routes.
• 404 over 403 for objects — returning "not found" avoids confirming the record exists to someone snooping.

The principles

Goal: a tiny local Flask app with an IDOR bug, a demonstration that one user can read another's note by changing the id, and the fix — all on your own machine.

# vulnerable_app.py — a DELIBERATELY broken demo, run locally only
from flask import Flask, session, abort

app = Flask(__name__)
app.secret_key = "demo"      # demo only

NOTES = {1: {"owner": "aisha", "text": "Aisha's private note"},
         2: {"owner": "ben",   "text": "Ben's private note"}}

def current_user():
    return session.get("user", "aisha")     # pretend aisha is logged in

# VULNERABLE route:
@app.get("/note/<int:note_id>")
def get_note_vuln(note_id):
    note = NOTES.get(note_id)
    if not note:
        abort(404)
    return note["text"]            # ← no ownership check! IDOR.

# FIXED route:
@app.get("/secure-note/<int:note_id>")
def get_note_fixed(note_id):
    note = NOTES.get(note_id)
    # deny if it doesn't exist OR isn't yours — and 404 either way
    if not note or note["owner"] != current_user():
        abort(404)
    return note["text"]

# attack demo (against your OWN local app) — show the difference
import requests
# logged in as aisha; her own note (id 1) works on both routes.
# Ben's note (id 2):
print(requests.get("http://127.0.0.1:5000/note/2").text)        # ← LEAKS Ben's note (vuln)
print(requests.get("http://127.0.0.1:5000/secure-note/2").status_code)  # 404 (fixed)

Ben's private note          ← the VULNERABLE route leaks it (IDOR)
404                          ← the FIXED route denies it (ownership check)

Read the code

The only difference between the two routes is one line — note["owner"] != current_user() — yet it's the difference between leaking every user's private data and a secure app. The vulnerable route "worked" in testing because the UI only ever linked aisha to note 1; the attacker simply requested /note/2 directly. This is the most common serious bug in real web apps, and the fix is always the same: authorize this request against this user, server-side. Run this on 127.0.0.1 only — it's your own deliberately-broken app.

Use your own local demo app or OWASP Juice Shop (Lesson 27) — both safe, intentional targets.

from functools import wraps
from flask import abort
def require_role(role):
    def deco(fn):
        @wraps(fn)
        def wrapper(*a, **k):
            if session.get("role") != role:
                abort(403)            # deny by default
            return fn(*a, **k)
        return wrapper
    return deco

Broken Access Control (A01, the #1 risk) is authentication without proper authorization. The two classics: IDOR (an endpoint returns an object by id without checking you own it — change ?id=123 to 124) and missing function-level control (privileged routes with no role check). The fix is always the same: verify ownership and role server-side, on every request, deny by default, return 404 for objects you can't access, and never treat hidden UI as security. Centralise checks in decorators/middleware so a forgotten route fails closed. Most real breaches are exactly this — and exactly this preventable.