Users can change `?account_id=123` to `124` and see other users' data. What category is this, and how do you fix it?
Short answer
This is broken access control (IDOR): the server isn't checking that the authenticated user may access the requested object. The fix is per-object authorization enforced server-side on every request. Sanitizing the number doesn't establish ownership. Encrypting or obfuscating the ID is obscurity that's still guessable, leakable, or replayable. The HTTP method is irrelevant to authorization. Always verify the caller's right to the specific object before returning it.
When changing account_id=123 to 124 returns someone else's data, the application is identifying the object but never asking whether this user is allowed to see it. That is an Insecure Direct Object Reference (IDOR), a form of broken access control — OWASP's number-one risk category.
The correct fix: server-side object-level authorization
On every request that touches a specific object, the server must check that the authenticated principal is authorized for that exact object — for example, that the account belongs to (or is shared with) the current user — and deny otherwise. This check has to live server-side and run on every access path, not just the UI that "normally" shows the right account. The reference itself can stay a plain integer; what matters is the authorization decision behind it.
Why the distractors are wrong
- Sanitizing the number validates format, not ownership.
124is a perfectly valid integer and still belongs to someone else. - Encrypting or obfuscating the
account_idis security by obscurity. Encrypted or random IDs leak in URLs, logs, Referer headers, and browser history, and can be replayed; switching to UUIDs raises the guessing bar but still returns data to anyone who obtains a valid reference. The missing authorization check is the real defect. - Switching GET to POST changes the HTTP verb and where the parameter rides, not whether the server authorizes the request. An attacker just sends a POST.
What the interviewer is probing
They want you to name the vulnerability class correctly (broken access control / IDOR), resist the tempting but superficial fixes, and locate the control in the right place: a server-side, per-object authorization decision applied uniformly. Strong candidates add that this is best enforced centrally — through a shared authorization layer or middleware — so individual endpoints can't forget the check, and that obfuscation is at most defense-in-depth, never the fix.
Likely follow-ups
- How would you enforce object-level authorization consistently across hundreds of endpoints?
- Why don't UUIDs or random IDs actually fix IDOR?
- How would you test for IDOR across an API at scale?