Step 5 — Make authentication, authorization, and audit one boundary

Login proves identity; it does not prove access to a particular resource. Every request must separately answer “who is this?” and “what may this identity do here?”

• Never trust a browser-supplied userId, ownerId, or teamId as permission evidence.
• Classify authentication and authorization failures as 401, policy-appropriate 403, or 404 when resource existence must not be disclosed.
• Admin mutations need session, role, CSRF/CORS, input validation, and audit checks together.
• Do not log emails, tokens, passwords, or raw IP addresses.

Content upserts and DB initialization run behind authenticated console screens. Document and room APIs re-check resource scope on the server. Public inquiries and login paths combine length limits, rate limits, and bounded retries.

Audit failure policy should follow risk. Read-only or easily reversible changes may use asynchronous audit writes. Initialization, deletion, and permission changes first durably record an *_INTENT; if that write fails, the mutation does not start. If the result audit fails after work may have applied, never report success. Return an explicit mutationApplied state and warn against blind retries.

Give users a safe next action without exposing stack traces or resource existence. Operators need actor, resource, action, result, and request correlation in the audit record.

Read next

• Public route allowlists and CORS
• Next step