Choose API Denial Responses

A denial response has two jobs: stop the action and give the client enough information to recover safely. It must not reveal another tenant's private record. There is no universal rule that every unauthorized object must return the same status. Choose the response from the authentication state and the product's existence-disclosure policy.

Response decision table

The OWASP REST Security Cheat Sheet covers HTTP API controls. The OWASP Authorization Cheat Sheet supports a server-side decision on each action. The status code expresses the decision; it does not create it.

Test privacy and client behavior

Create synthetic A and B records. Compare the response for an A user requesting B's private record with the response for a nonexistent record. Decide which differences are acceptable. Check body, headers, timing category, logs, and cache behavior without turning the test into a side-channel experiment on a live target. Verify that the client does not retry a forbidden action indefinitely or reveal a private record name in an error toast.

A permitted user should still reach the record. Test that too; a handler that returns 404 for everyone is not a secure repair. For role-limited functions, a clear 403 can help a legitimate user ask an administrator for access. For private object IDs, concealment may reduce needless disclosure. Record the product decision and test it across routes.

The artifact is the response table tied to the resource policy. Use it in API design and QA. Do not present a 404 as proof that the object is protected. The backend must deny data and side effects first.