ORIGINAL TECHNICAL PRACTICE
Keep authorization at the resource boundary
A user can view their own reports. What checks are needed when an API accepts a report ID in the URL?
Written for independent practice. The model answer presents one approach; clarify constraints and explain alternatives.
A REASONED APPROACH
Model answer.
Authenticate the caller, then authorize access to the specific report and operation on the server. A valid or hard-to-guess ID is not evidence that the caller is allowed to use it.
Work through it
- Derive the authenticated identity from the trusted session or token, and look up the report within that identity’s permitted scope.
- Apply the same resource check to reads, downloads, updates and background exports. Re-check authorization when a later job executes if permissions may have changed.
- Test cross-account IDs, revoked access, role changes and indirect references inside request bodies. Return errors without revealing unnecessary information about protected resources.
Tradeoffs to discuss
- Fine-grained checks can add implementation and query complexity. Central policy helpers can improve consistency, but every data-access path must actually invoke them.
Common pitfalls
- Hiding a button in the frontend does not enforce access. A signed URL or cached response must be scoped and expired in a way that preserves the intended permission boundary.