What they're testing
Whether you think of authorisation as an architectural property, or as an if in a controller.
The short answer~30 seconds
Broken access control (A01 in the OWASP Top 10 2021). The most common shape is IDOR: /api/orders/1234 checks that the user is logged in but not that the order is theirs. The right place to defend isn't each controller but the data-access layer: every query carries the caller's scope. Checks scattered across controllers will be correct in the first forty endpoints and missing in the forty-first — the one somebody added in a hurry.
The long answer
The durable approach is making an UNSCOPED query hard to write. For example, every data-access function takes an actor as a required argument and adds WHERE owner_id = actor.id itself; or you enable row-level security in the database so even the paths you forgot are blocked. The common property is that the defence sits where it can't be skipped, rather than where it must be remembered.
Another commonly-missed shape is authorisation over ACTIONS rather than resources: a user may view their own order, but may they CANCEL it after delivery? May they change status through a generic update endpoint? A lot of holes live in update endpoints that accept a whole object and overwrite fields the user shouldn't touch — mass assignment. The defence is an allow-list of fields, not a deny-list.
On testing, this is the class automated scanners handle worst: a tool doesn't know who order 1234 belongs to. So it has to be covered by deliberate tests — for each endpoint, one test using user B's identity against user A's resource, expecting a 404. Writing one helper for that and applying it across every endpoint is the cheapest way to turn a vulnerability class into a checklist.
What they'll ask next
?404 or 403 for a resource that isn't the user's?
404, so you don't confirm the resource exists — otherwise an attacker enumerates ids and learns how many orders you have. But the logs must distinguish the two, or support can't diagnose anything.
These lose points
- Enforcing permissions in the UI. Hiding a button stops nobody from calling the API directly.
- Trusting a client-supplied id to identify the user.
?userId=is the vulnerability; identity comes from the session.