Broken Object-Level Authorization
- Summary
- The API did not enforce ownership checks on resource identifiers, allowing any authenticated session to read or modify another user's records by changing the object ID in the request.
- Impact
- An authenticated attacker could exfiltrate the full customer dataset, modify account details, or delete records belonging to any other user — no elevated privilege required.
- Proof of concept
-
Reproduction steps (redacted)
- Authenticate as a normal user and capture a request to
GET /api/v1/users/█████/profile. - Replace the user ID in the path with a different numeric ID (
█████ + 1). - Observe that the response returns the target account’s profile data with HTTP 200.
- Repeat for
PATCH /api/v1/users/█████/email— the server accepts the mutation.
All specific identifiers, endpoints, and credentials have been redacted per the engagement NDA.
- Authenticate as a normal user and capture a request to
- Remediation
- Enforce ownership at the data layer on every read and write: verify that the requesting session owns the referenced object before returning or mutating it.