A successful login does not grant access to every record
Authentication establishes who is making a request. Authorization evaluates whether that identity may perform a particular action on a particular resource. An API can require a valid session and still expose another user's data if it never checks the requested record. These two checks belong together, but they answer different questions.
Consider a document service with GET /documents/42. A session proves that the caller has signed in. The document lookup also needs to establish whether the caller owns the document or has permission through a shared workspace. Returning any record whose ID exists would skip that second decision.
Check the object and the requested action
OWASP describes broken object-level authorization as a risk when APIs accept object identifiers without verifying access to the objects. A UUID can make guessing harder, but knowing an identifier must never become permission to read or modify the record.
A useful policy separates actions. A collaborator might read a document and add comments while only an owner can delete it. Write down those rules before implementing handlers. Then follow the resource relationship from document to workspace and membership. Take the caller's identity from a verified session, rather than accepting a user ID in the request body as proof of ownership.
Apply the rule beyond the detail endpoint
A document can appear in search results, exports, download routes, and background jobs. Protecting only its detail page leaves these other paths open. The OWASP Authorization Cheat Sheet recommends checking permissions on every request and denying access when no rule grants it.
For example, a search endpoint should return documents from the caller's permitted scope. A file download should verify access before serving private bytes. A job that generates an export needs an explicit policy for whose authority it uses and what happens when that person's membership changes.
Test with two accounts and one revoked membership
Create account A and account B, with a private document belonging to each. While authenticated as A, try reading, editing, commenting on, and deleting B's document. Use direct API requests so the test does not depend on which buttons the interface shows. Verify both the response and the stored data.
Next, give A access through a workspace, confirm the permitted operation succeeds, and remove that membership. Repeat the operation. This checks that authorization follows current permissions. Keep an allowed case beside each refused case so a handler that rejects everyone cannot accidentally pass the suite.
Keep the policy understandable
Start with the access rules the product actually needs. A short action matrix is easier to review than permissions scattered across unrelated handlers. Reuse the same policy where multiple endpoints operate on the same resource, and make exceptions explicit. Authentication protects the entrance; object-level authorization determines what a caller can do after entering.