A city citizen portal shows another resident's case details when only the case ID in the URL is changed. What vulnerability class is this?
Select an answer to reveal the explanation.
Short Explanation
Guessing the next locker number should not open someone else's locker. When changing an ID exposes another user's record, authorization never checked ownership — that is IDOR. Horizontal or vertical privilege problems both start there.
Full Explanation
IDOR / broken object-level authorization appears when changing an object ID in a request reveals another user’s data without an ownership or entitlement check. A city citizen portal that shows another resident’s case details after altering only the case ID is a classic civic privacy failure: horizontal access control is missing on case objects.
Clickjacking from missing frame-ancestors is a UI redress issue, not object authorization. Weak password policy and subdomain takeover are separate findings that do not explain ID-based case disclosure.
Exam caveat: test object IDs across roles and tenants with minimal data exposure; IDOR is among the highest-frequency API issues in modern municipal apps. CPTS web judgment pairs discovery of {id} parameters with authZ proofs.
Operational check: attempt cross-user case ID access with two test accounts, enforce server-side entitlement checks, log denied access, and retest that foreign civic case IDs return authorized errors only. Case APIs for city residents need mandatory ownership checks in a shared middleware layer, not per-handler afterthoughts that miss one route. Object-level checks must use server-side session identity, never a client-supplied user id alone.