/api/User?id=123 vs /api/user?id=123 or user_id ↔ userid
Path Traversal / Mixed Paths
POST /users/delete/my_id/../victim_id
Wildcard Substitution
GET /api/users/* or GET /api/users/user_id
Fuzz Keywords in Path
GET /api/v3/users/12345 -> /api/v3/users/all
SQLi Quick Check
GET /api/v3/users/12345'
Phase 4: Logic & Endpoint Bypasses
Technique
Scenario to Test
Version Downgrading
GET /v3/user/111 -> GET /v1/user/111
Sub-Endpoint Variant
Full profile endpoint vs less-protected detail endpoint
Missing Function Level Access / Case Variants
GET /admin/profile -> GET /Admin/profile
Owner Flag / Role Field Differences
Look for "owner": true/false, "is_admin", role fields returned in body and try to toggle via params or token swap.
Token / Authorization Swap
Replace access_token/API key with victim's or other known tokens (or swap attacker token for victim token in request) to test token-scoped checks.
Cached Role Check / Session Race
Logout/login, change roles, re-test to detect cache-based false-negatives.
Token Binding Flaws
Tokens (e.g., unsubscribe tokens, action tokens) are validated for structure and expiry but not bound to a specific resource (resource_id / page_id / email). Test by reusing a valid token issued for resource A against resource B. Example: POST /unsubscribe?token=<valid_token_for_user_A>&page_id=B — if server accepts token without checking binding, action succeeds.
Frontend–Backend Desync / Logic Mismatch
Frontend hides or restricts certain IDs or operations, but backend endpoints accept those IDs without verifying resource ownership. Test by sending requests with IDs that the frontend never exposes (or disables) and see if backend performs the action. Example: UI shows tasks for user=10 only, but POST /deleteTask with taskId=11 deletes another user's task if backend lacks owner check.
Phase 5: Parameter & Body Abuse
Technique
Scenario to Test (Attacker ID=10, Victim ID=9)
Add Parameter Bypass
GET /api_v1/messages -> ?user_id=victim_uuid
Multi-ID / Comma Separation
GET /api/users?id=10,9
Alternate Separators
{"Account": 2222;1111} or 2222.1111
HTTP Parameter Pollution (HPP)
?user_id=10&user_id=9
JSON Array Wrap
{"userid":[123]}
JSON Object Wrap (Nested)
{"userid":{"userid":123}}
JSON Parameter Pollution
{"userid":1234,"userid":2542}
Null Termination (%00)
GET /api/users/9%00
Control Char Encoding (CR/LF)
%0d%0a inside JSON or param
Replace Parameter Name
album_id -> account_id
Multi-ID Injection (Batch IDs)
{"ids":[111,222,333]} — include victim id among attacker ids to see leakage.
Deserialization / Object Injection
Send an object in place of a primitive ID or crafted serialized payload to influence server-side deserialization logic (e.g., {"user": {"id": 9, "role": "admin"}} or sending a serialized protobuf/object). Test by replacing user_id=9 with user={"id":9} or sending crafted object payloads. Servers that blindly accept deserialized objects may map them to existing objects or honor fields leading to IDOR or privilege escalation. Example: POST /api/profile/update with body {"user":{"id":9,"notify":true}} might operate on victim's profile if backend trusts deserialized object without owner check.
Phase 6: Encoding, Hashing, and Obfuscation Bypasses
X-HTTP-Method-Override: DELETE to bypass method checks.
Protocol-specific APIs (gRPC / protobuf)
Test non-HTTP RPC endpoints and protobuf messages for IDOR patterns. Example: a grpc method GetUser(UserRequest { user_id: 9 }) may accept manipulated IDs over the wire; test by using gRPC clients or proxying protobuf messages to replace IDs. Servers that only validate at REST endpoints may miss gRPC entry points.
Fuzz endpoints for owner, is_admin, role flags; try to induce endpoints to return role-related changes.
Weak UUID Patterns / Partial Brute
If UUIDs share prefix/suffix, brute-force suffix/prefix.
Mobile/API Discovery
Extract endpoints from mobile clients and test with same techniques.
WebSocket / Real-Time Channel Subscription
Test real-time endpoints (WebSocket / SSE) that use channel names like user_<id> or page_<id>. Try subscribing to channels of other users (e.g., send SUBSCRIBE user_9) and verify whether the server enforces authorization for each subscription. Example: attacker opens ws and requests subscribe: "user_9" — if server doesn't validate, attacker will receive victim's real-time events.
TOCTOU / Race Conditions for IDOR
Time-of-check-to-time-of-use issues where ownership/authorization changes between check and action. Example: start batch export referencing ids=[10], race with changing ownership or perform concurrent requests to exploit brief authorization gaps to access another user's resource.
Servers that deserialize untrusted input may map objects incorrectly or honor deserialized object fields (e.g., __proto__ manipulations, polymorphic deserialization). Test by sending crafted serialized objects or protobuf messages that include object wrappers instead of primitive IDs, or type-hint fields that cause different object resolution.
Phase 11: Detection of False Negatives (Checklist)
Never Trust the Status Code: Endpoints often return a 200 OK but silently re-scope the query to your own token. A 200 does not prove an IDOR unless you verify the data.
Use Data Oracles (Canaries): Seed your test accounts with unique data (e.g., Victim A's bio is "AAAA", Victim B's is "BBBB"). Assert that you pulled B's specific value across the boundary, not just your own data echoed back.
Out-of-Band Verification for Destructive Actions: For POST/DELETE requests, the attacker's response often looks identical (e.g., 204 No Content) whether the check passed or failed. You must log in as the victim to confirm the state actually changed.
Compare content-length and body fields, not only HTTP status.
