What is IDOR?
A broken-access-control flaw where changing an object reference in a request — an ID in a URL or body — returns data belonging to someone else.
IDOR: A broken-access-control flaw where changing an object reference in a request — an ID in a URL or body — returns data belonging to someone else.
In plain language
IDOR is the most relatable access-control bug: the URL says /invoice/1001, you change it to 1002, and you see a stranger’s invoice. The server returned a valid 200 because it never checked that you were allowed to see object 1002.
Because the response looks normal, a scanner cannot tell a legitimate read from a leak. SuperPentest proves IDOR by holding two identities, requesting each other’s objects, and confirming the cross-tenant access — then reproducing it from a clean session so it is undeniable.
A concrete example
A support tool exposes /tickets/8841/attachments/3. Incrementing the attachment id to 4 returns a file from a different customer’s ticket. Nothing in the response looks abnormal — the server simply never asked whether this agent owns ticket 8841. SuperPentest catches it by requesting one identity’s object ids while logged in as another, and flagging every cross-account 200.
Related
IDOR testing → · BOLA → · Access-control replay →
Want this tested on your app? Book a demo or read how findings are verified.