Skip to content

Module 07 — Web Attacks: Authentication & Access Control

Type 3 · Blast-Radius Trace — exploit IDOR and privilege escalation, run the every-role × every-endpoint sweep to map the reach, and end in the deny-by-default fix. (Secondary: Misconception Reveal — the root cause is the server trusting the client.) Go to the hands-on lab →

Last reviewed: 2026-06

Offensive Security — broken access control is OWASP's #1 risk for a reason.

Difficulty: Intermediate  ·  Estimated time: ~5–7 hrs (study + lab)  ·  Prerequisites: Foundations

In 60 seconds

Authentication is "who are you"; authorization is "what are you allowed to do" — and broken access control tops the OWASP Top 10 because it's everywhere and trivially exploited. The mechanism is almost embarrassing: most apps enforce access at the UI (hide the button) but not at the API (the server still answers if you ask directly). So the attack is just asking — change id=123 to 124 and read someone else's record. It's the same disease as injection: the server trusting the client. Finding it is won by discipline, not cleverness.

Why this matters

Most web apps get the flashy bugs right and the boring ones wrong: weak authentication, broken session handling, and — above all — broken access control, where you simply ask for data that isn't yours and the server hands it over. It tops the OWASP Top 10 because it's everywhere and trivially exploited. Finding it is mostly discipline, not cleverness.

Objective

Identify and exploit authentication and access-control flaws — including IDOR and privilege escalation — and explain the fix.

The core idea

Authentication is "who are you"; authorization is "what are you allowed to do" — and broken access control (the authorization failure) tops the OWASP Top 10 because it's everywhere and trivially exploited. The mechanism is almost embarrassing: most apps enforce access at the UI (hide the button) but not at the API (the server still answers if you ask directly). So the attack is just asking — change id=123 to 124 and read someone else's record (IDOR), call the admin endpoint as a normal user (vertical escalation), or reach a peer's data (horizontal). No payload, no cleverness.

flowchart LR
    U["attacker"] -->|"clicks UI"| UI["UI hides<br/>others' records"]
    U -->|"asks API directly:<br/>id=123 → id=124"| API["server answers<br/>— no authz check"]
    API --> D["someone else's<br/>record returned"]

The mental model

Seen through the lens of injection, this is the same disease in a new organ: the server trusting the client. Injection is the server trusting client input; broken access control is the server trusting the client to only ask for what it should. Both fixes are structural and identical in spirit — never trust the client: enforce authorization server-side, deny-by-default, on every request, not by hiding options the user can still call.

The gotcha

This finding is won by discipline, not brilliance. You check every action as every role — admin, normal user, other user, no auth — and diff what comes back. It's tedious, which is exactly why it's the #1 risk: the boring enumeration gets skipped by developers and testers alike.

AI caveat

A model helps brainstorm which IDs or roles to try, but it won't methodically walk every endpoint × every role for you — that disciplined sweep is the job.

Learn (~4 hrs)

Hands-on labs - PortSwigger — Authentication vulnerabilities — credential, session, and MFA flaws, with labs. - PortSwigger — Access control & IDOR — the highest-value, most common class.

Reference - OWASP Top 10 — A01: Broken Access Control — why it's ranked #1, with real examples.

Key concepts

  • Authentication vs authorization (the distinction that matters here)
  • Insecure Direct Object References (IDOR)
  • Vertical vs horizontal privilege escalation
  • Session handling and token flaws
  • The fix: enforce access control server-side, deny by default

AI acceleration

A model helps you reason about which object IDs or roles to try — but access-control testing is about methodically checking every action as every role, which a model won't do for you. Use it to brainstorm; you do the disciplined enumeration.

Check yourself

  • What's the difference between authentication and authorization, and which one fails in broken access control?
  • Distinguish IDOR, vertical escalation, and horizontal escalation with an example of each.
  • Why does hiding a button in the UI not constitute access control, and what does the real fix look like?

Comments

Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).