How do you test for object level authorisation flaws like IDOR?
In short
- List every endpoint that accepts an identifier — in the path, the query string or the body.
- Sign in as one user, request another user's object by changing the id, and watch the status code.
- Test writes as hard as reads: PATCH and DELETE built from the same scaffold fail the same way.
Start by enumerating rather than probing. Every endpoint that takes an identifier is a candidate, and that list is usually short enough to walk in an afternoon.
For each one, write down in a single sentence who is allowed to call it. Not “an authenticated user” — the actual rule, naming the relationship. If nobody on the team can state that sentence, that endpoint is where to start, because code cannot enforce a rule the team has not articulated.
Then test it directly. Sign in as user A, request an object belonging to user B, and read
the response. A 200 is the finding. A 403 is a weaker finding, because it confirms the
object exists — the correct answer to “may I see something I am not allowed to see” is
404.
Do the same on every method the route accepts. A leaky GET is usually paired with a
PATCH and a DELETE built from the same scaffold, and those are worse: one leaks data,
the others change or destroy it.
Finally, read the fix rather than trusting the test. Ownership belongs inside the database query, so there is no state in which the handler holds a row it may not return. A fetch followed by a permission check passes the same test today and breaks the first time someone moves the check.