Try this on your own product. Sign in, open an invoice, then change the invoice number in the address bar and see whose invoice comes back. The main screens usually pass. The CSV export and the overnight report job are where we’d look first.
Signing in proves who someone is. Authorisation decides what they may do to which record. Sign-in usually comes from a provider. Authorisation is written by your own team, route by route, and every new route is another place to forget it.
OWASP lists this failure first in its API Security Top 10, as broken object level authorisation. Random record IDs make guessing harder. They do nothing when an ID leaks through a shared link or a support ticket.
Map who may do what before testing endpoints
We start from the actions your customers care about, such as downloading an invoice or connecting an integration. For each one, the question is who should be allowed and what stops everyone else.
Don’t stop at the detail page everyone tests by hand. The gaps sit in a bulk action that skips the per-record check. Or in an integration token that can see the whole organisation, when the person who connected it could only see one team.
Questions to ask before you buy
We’d put these to any provider, including us.
Will you test with at least two customer accounts and more than one role in each?
Are exports and background jobs in scope, or only what the screens show?
Will each finding say where the check is missing?
After we fix something, will you check the other routes to the same data?
What a finding should give your developers
A good finding shows the request that should have been refused and what came back. It also points at where the check is missing, for example a database query that filters by document ID and never by customer. Without that pointer, a fix can close the one request in the report and leave the export next to it open.
After the fix, one refused request proves little. The retest should go through every route that reaches the same data.
Which part of your company this is about
An architecture diagram of a typical SaaS product, with the part this note is about lit.
