Module 6 · IDOR & Authorization Bypass 🔒

In 2026, authorization is the single most commercially-impactful bug class in SaaS applications. It tops OWASP’s lists. Every pentest we run finds at least one. Authorization bugs produce the cleanest, scariest demos in pentest reports — “Look, this user can read all customers’ data. Yes, all of them. Yes, with a single HTTP request.” Developers can’t argue with the evidence, and regulators take these bugs seriously under DPDP’s “reasonable safeguards” standard.

This module teaches the four authorization bug classes that produce 90% of real-world findings.

The mental model

Authentication: who are you? Authorization: what are you allowed to do? A well-designed application asks both questions on every action. A poorly-designed application checks authentication once (at login) and trusts the client for authorization thereafter.

Authorization decisions live in two dimensions:

• Function-level: is this user allowed to invoke this endpoint at all? (e.g., /admin/users)
• Object-level: given they can invoke it, are they allowed to access this specific object? (e.g., order ID 42 belongs to a different user)

Both need to be enforced on every request, server-side. When either is missing or bypassed, you get one of the four authorization bugs below.

1. Horizontal IDOR (BOLA — Broken Object-Level Authorization)

Authenticated user A can access objects owned by authenticated user B by changing an identifier in the request.

GET /api/orders/12345
Authorization: Bearer <user A's token>
→ Returns order 12345, owned by user A.

GET /api/orders/12346
Authorization: Bearer <user A's token>
→ Returns order 12346, owned by user B. IDOR.

Root cause: endpoint checked authentication (“is this a valid token?”) but not ownership (“does this token’s user own order 12346?”).