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.

Codingstairs upserts and DB initialization run behind authenticated Admin screens. DMDDKSL document and room APIs re-check resource scope on the server. Public inquiries and login paths combine length limits, rate limits, and bounded 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