The IDOR Iceberg: 4 Flaws Scanners Often Miss
Resumo
Pixel shares an in-depth look at IDOR flaws beyond simple ID tampering, including GraphQL alias projections, UUID-to-integer cast boundaries, pre-signed cloud storage URLs, and batch-operation injection. These architectural access-control failures can evade automated scanners, making careful mapping of how objects move across services essential.
DEV Community
The IDOR Iceberg: Why Scanners Miss 95% of Object-Reference Flaws
If your IDOR knowledge stops at changing id=101 to id=102, you're missing 95% of real business-logic bugs. Here's the iceberg below the waterline. Modern APIs mostly dropped sequential integer IDs in favour of UUIDv4, opaque tokens and nested GraphQL. Automated scanners only know how to tamper with trivial integers, so they are blind to modern IDOR topologies. Here's the IDOR iceberg — the patterns worth hunting on enterprise APIs. 1. GraphQL alias field projections A single GraphQL request can ask for the same type under multiple scopes via aliases: query {
mine: user(id: "uuid-my-account") { email role }
target: user(id: "uuid-victim-account") { email role }
}
Authorization middleware often evaluates permission on the first resolved field and never iterates the alias tree. 2. UUID-to-integer cast boundaries Many services expose UUIDs at the gateway but keep integer primary keys internally: GET /api/documents/00000000-0000-0000-0000-000000001337
GET /api/documents/1337
If the backend strips hyphens or silently casts a failed UUID parse to an integer, the auth check breaks while the DB query still succeeds. 3. Pre-signed cloud storage URLs File flows generate pre-signed URLs (S3, GCS, Azure Blob): POST /api/export/generate
{ "export_type": "pdf", "storage_reference_id": "org_victim_financials" }
If the client controls storage_reference_id or bucket_key, the backend may sign a grant to another tenant's bucket. 4. Batch operations and array injection POST /api/v2/contacts/batch-delete
{ "account_id": "org_my_company",
"contact_ids": ["contact_mine_1", "contact_victim_99"] }
The auth layer checks that you own account_id — but never that every ID in the array does, before running the batch transaction. The takeaway IDOR is not a parameter flaw. It's an architectural access-control failure. Don't trust scanners to find logic bugs. Map how objects move across services, watch where type conversions happen, and scrutinize every batch endpoint. Which IDOR variant gave you your highest-impact report? Share it below.
Powered by Readybot.io
