Secure Coding Practices for Authentication and Authorization
Domain 5: Secure Coding Practices for Authentication and Authorization
This domain tests identity proofing and access enforcement. The exam expects you to keep authentication, authorization, and session state separate and to enforce access decisions on the server.
Core rules and concepts
- Authentication establishes who a subject is; authorization decides what that subject may do. Neither implies the other.
- Support multiple factors where risk warrants: something known, possessed, or inherent. Avoid weak recovery paths that bypass the primary factor.
- Store passwords with a modern password-hashing function and a per-user salt; never store reversible passwords or fast unsalted hashes.
- Enforce authorization on every request and every object, using deny-by-default and least privilege. Do not rely on hidden UI controls.
- Prevent IDOR by checking that the authenticated subject is permitted to access the requested object, not merely that the object exists.
- Use established authorization models such as RBAC or ABAC, and centralize policy where practical.
Worked example
An endpoint returns invoices by identifier: GET /invoices/123. A weak implementation checks only that the user is logged in, then fetches invoice 123. An attacker changes the number and reads another customer's invoice. A sound implementation derives the user identity from the server-side session, queries the invoice with both invoice ID and owner ID, and returns not found or forbidden when the record is not owned. The reasoning is that authentication alone is insufficient; object-level authorization must bind the subject to the resource.
Traps that cost marks
Do not treat a role check in the browser as authorization. Do not trust user-supplied role, tenant, or owner identifiers. Do not confuse authentication failures with authorization failures. Do not use predictable password-reset questions. Do not validate a JWT signature but ignore its issuer, audience, or expiry.
Review habit
For each endpoint, ask who can call it, which objects they may affect, and where that decision is enforced server-side.