The Ultimate IDOR Testing Checklist (2026 Edition)
A practical security checklist for testing insecure direct object reference flaws across APIs, apps, GraphQL, mobile clients, and real-world edge cases.
Insecure Direct Object Reference (IDOR) bugs remain one of the most common and high-impact issues in modern web apps. The pattern is simple: an application exposes a resource using a user-controlled identifier, but fails to confirm that the current user actually owns or is allowed to access it.
The goal of this checklist is practical. It helps security engineers and bug bounty hunters move beyond a single lucky payload and instead test for the real-world conditions that create IDORs across APIs, web apps, GraphQL, mobile clients, and newer protocol surfaces.
Phase 1: Setup and target identification
Start by creating a victim and attacker account, identify JSON and private endpoints, inspect sensitive flows, and review whether IDs are exposed in public pages or response bodies. The best IDOR tests usually start with the most sensitive actions: password changes, profile updates, financial records, messages, downloads, and administrative panels.
| Surface | What to inspect | Why it matters |
|---|---|---|
| Profile API | GET /api/users/:id | User ID leakage and ownership mismatches |
| Invoices | GET /billing/invoice/:id | Check invoice scoping and role boundaries |
| Files | /download/:fileId | Verify file-level ACL and token scope |
| GraphQL | node(id: ...) | Object-level authorization bypasses |
Phase 2: Direct ID substitution and enumeration
The most obvious checks are still the most valuable: flip a numeric ID, replace a UUID, fuzz nearby values, test mixed ID patterns, and look for predictable or leaked identifiers. The key lesson is that many apps are not broken by complex logic; they are broken by a single missing ownership check.
- Swap 1 with 2, 3, 10, 999999 and see whether the response changes
- Try adjacent records belonging to another user
- Enumerate IDs in APIs used by dashboards, exports, and shared items
- Check for UUIDs, hashes, and encoded identifiers that reveal predictable patterns
Phase 3: Path and URL manipulation
This is where URL normalization tricks come in: trailing slash variants, double slashes, path traversal patterns, case variation, wildcard handling, and quick parameter pollution. These are common bypasses when the app does not consistently validate the route or the resource ID.
curl -i 'https://target.example.com/api/users/42'
curl -i 'https://target.example.com/api/users/42/'
curl -i 'https://target.example.com/api/users/%2e%2e/42'
curl -i 'https://target.example.com/api/v2/users/42?userId=999'Phase 4: Logic and endpoint bypasses
Some of the nastiest IDORs exist in versioned endpoints, sub-endpoints, role checks, cached access rules, and token-scoped actions. It is also common for the frontend to hide some actions while the backend still accepts the underlying resource ID. If the server never checks ownership, a request that looks forbidden in the UI can still succeed in the API.
Phase 5: Parameter and body abuse
Request tampering is a classic IDOR vector. Try alternate parameter names, multiple IDs in a payload, nested JSON objects, array forms, and HTTP parameter pollution. This is where injection payloads and business logic mismatches show up most often.
Phase 6: False negatives and oracles
One of the biggest mistakes in IDOR testing is treating a 200 OK as evidence. Many apps silently scope the query to your own identity and return your own record even when the provided ID is different. That is why seeded canaries and out-of-band verification matter: a real IDOR is only proven when the victim’s unique value appears or the victim’s state changes.
“A 200 OK is not proof. A canary and a victim-side check are the real oracle.”
Phase 7: Advanced and modern surfaces
IDORs do not live only in classic REST endpoints anymore. Test GraphQL, gRPC, WebSocket channels, mobile APIs, and exported file routes. A real access boundary needs to be enforced at every protocol boundary, not just in the front-end UI or one HTTP route.
The checklist is most useful when it becomes a habit: map the resource, find the identifier, test boundary conditions, verify ownership, and confirm the victim actually sees the impact. That is the difference between weak testing and reliable security engineering.
