Authorization follows the object
Suppose /reports/42 returns a report. The server must check more than logged-in status: it must verify that this user may read report 42. Different users with the same role may have access only to their own objects, creating a horizontal access boundary.
A hard-to-guess identifier merely lowers the chance of guessing it. IDs may become known through legitimate sharing, logs or another page. The actual control belongs at a trusted boundary and validates identity, resource and action on each request.
Further reading: OWASP: Authorization Cheat Sheet
Check denial and legitimate sharing
Create two synthetic users and two reports. Verify each can read their own and cannot read the other’s. If sharing is supported, specify the relationship, expiry and revocation separately. Denying every access is not a complete success.
Failures should return appropriate, consistent errors without unnecessary object information. The choice of 403 or 404 depends on the design, but the response must not still contain the protected data.
Example: the same student role, different data
Fictional user A owns report 42 and B owns report 43. Both have the student role, and B knows the URL for 42.
A shared role supplies only part of the policy. Ownership or an explicit sharing relationship is still required. Without sharing, B’s read should be denied.
Conclusion: The rule can require owner==user or valid sharing authorization, rather than merely role==student.
Offline exercise: four access cases
Fill a table without using real accounts or URLs.
- List A→42, A→43, B→42 and B→43.
- Fill allow and deny outcomes with no sharing.
- Then add A explicitly sharing 42 with B and identify the changed cell.
Expected result
Without sharing, only A→42 and B→43 are allowed. Valid sharing can allow B→42 according to policy.
Check your work
Which case must return to denial after sharing is revoked?
Finish and clean up
Save the matrix; no real accounts or sharing permissions need restoration.