A tester for a cloud-hosted billing portal signs in as one customer, changes the numeric invoice identifier in the browser's URL, and is shown another customer's invoice. Under the OWASP Top 10, which risk category does this flaw belong to?
Select an answer to reveal the explanation.
Short Explanation
The tester didn't break in; they just asked for somebody else's invoice and the app handed it over. The app knew who they were and never checked whether they were allowed to see that record. That's access control, not injection, no matter how 'hacky' you think editing a URL feels.
Full Explanation
Broken Access Control covers failures to enforce what an authenticated user is permitted to do or see. Changing an identifier in a request to reach another user's record, often called an insecure direct object reference, is a classic example: the application authenticated the user correctly but never verified that the requested invoice belongs to that user before returning it. The fix is a server-side authorization check on every object access, tied to the caller's identity and tenant, with deny by default. Injection involves untrusted input being interpreted as code or commands by an interpreter, such as SQL or an operating system shell; here the identifier is used exactly as intended, as data, and the flaw is the missing ownership check. Cryptographic Failures concern weak, missing or misused cryptography that exposes sensitive data, such as unencrypted transmission or poor key handling; encryption would not stop an authorized session from being served the wrong record. Security Misconfiguration covers insecure defaults, unnecessary features and incorrect settings; while poor configuration can contribute to many issues, this flaw lives in the application's authorization logic. Exam caveat: in multi-tenant cloud applications, object-level checks must include the tenant boundary as well as the user. Operational check: add automated tests that request other users' and other tenants' objects and expect a denial.