Object-Level Authorization: Test the Second Account

A user signs in correctly and requests an invoice correctly formatted as a UUID. Neither fact establishes that the invoice belongs to that user. Broken object-level authorization occurs when a server accepts a reference and acts on the object without checking the caller's rights to it.

Build a two-account fixture

In an authorized staging environment, create accounts A and B with the same ordinary role. Give each a recognizable synthetic invoice. First verify that A can read its own invoice. That positive control matters: a broken endpoint that denies everything can otherwise look secure.

Now request B's fixture while signed in as A. Depending on the product's disclosure policy, a forbidden or not-found response can be appropriate. The essential property is that B's data does not leave the server. Inspect the body as well as the status; error pages can inadvertently contain sensitive fields.

Follow the object beyond the obvious endpoint

Check download, export, update and bulk actions that reference the same object. A list endpoint scoped by tenant will not protect a separate PDF export that fetches by ID alone. For writes, verify the object's stored state remains unchanged. An error response after the mutation is still a failed control.

A robust implementation scopes the data lookup to the authorized principal or performs an equivalent policy check before use. Random identifiers reduce casual discovery but cannot repair a missing ownership check.

Keep the test through refactors

Retain the fixtures and express the expected allow/deny matrix as an integration test. Include delegated access if the product permits it: a finance administrator may legitimately see another user's invoice within the same organization. The rule is the business relationship, not simply equality of two user IDs.

Further reading

OWASP API1: Broken Object Level Authorization

Related guide: How to Verify an Access Control Fix in Staging.