Change the id in the URL, keep the same session — and the API hands over someone else's account. IDOR is small to exploit and devastating in impact.
IDOR — insecure direct object reference — is the app trusting the identifier but not checking who is asking. You change /statement/12345 to /statement/12346, and if the server only checks that you are logged in, not that 12346 belongs to you, it returns a stranger's statement, card or passport scan.
It is the most common access-control miss because it survives frameworks: the route is wired, the auth middleware runs, and only the object-level check is missing.
A single IDOR on account statements is a data leak. The same pattern on a password-reset or email-change endpoint is full takeover: read the token, or set the contact details, and the account is yours. The fix is the same — the impact is not.
IDOR is one specific, common form of it: the object reference is trusted while the ownership check is missing.
Yes — we test across real or isolated accounts to show exactly what one user can see of another.