A01 — Broken Access Control Insecure

1000-ft view: these demos show what not to do — fetching resources without owner checks, relying on guessable IDs, missing server-side role checks, accepting over-posted fields, and serving files directly by id/path. Try the suggested inputs to see the risks.

Attack 1 Attack 2 Attack 3 Attack 4 Attack 5

Compare with the Secure version.

Attack 1 — IDOR (Numeric ID)

no owner check

Vulnerable idea: fetch by id alone (e.g., SELECT ... WHERE id = $id). An attacker can enumerate others’ notes.

  1. Enter a note ID you don’t own (from seed data for other users).
  2. Submit — page will display it because there’s no user_id check.

Attack 2 — IDOR (Guessable “UUID”)

public_id only, guessable

Vulnerable idea: expose a “UUID” that is actually short/guessable, and treat possession as authorization (no user check).

  1. Enter another user’s public_id (seed includes an obviously guessable one).
  2. Submit — endpoint returns the note to anyone with the id.

Attack 3 — Function-Level Authorization

no server-side role check

Vulnerable idea: hide the “Promote” button in the UI, but don’t verify role on the server. Attackers can still POST directly.

  1. Enter a target user ID (e.g., 2 for Alice).
  2. Submit — endpoint promotes them without verifying the caller is admin.

Attack 4 — Mass Assignment

trust client fields

Vulnerable idea: take every incoming POST field and apply it to the user record. Attackers can set is_admin=1, credit=9999, etc.

  1. Submit with hidden/extra fields via devtools (e.g., is_admin=1).
  2. Endpoint accepts/updates them because no allowlist is enforced.

Attack 5 — Direct Object/File Access (DOR)

serve by id/path

Vulnerable idea: fetch files by id (or even direct path) without checking ownership. Attackers can read other users’ files.

  1. Enter a file ID/path that belongs to someone else.
  2. Submit — endpoint serves it because there’s no owner check or path constraint.