Security keeps a system’s promised behavior intact when people, software, and infrastructure fail or act maliciously. It is an engineering property of the whole service: identities, authorization, data handling, dependencies, deployment, detection, and recovery all contribute to the result.
The Shape of the Problem
The CIA triad names three recurring goals: confidentiality limits disclosure, integrity limits unauthorized change, and availability keeps required operations usable. A real threat model adds the assets, actors, trust boundaries, abuse paths, and impact that make those goals concrete. Defense in depth then places independent controls along an abuse path so one failed control does not decide the outcome.
Two distinctions run through everything below:
- Authentication and authorization: authentication establishes a principal with some assurance. Authorization decides whether that principal may perform this operation on this resource now. A valid session never replaces the resource decision.
- Encoding, password hashing, integrity, and encryption: encoding changes representation. Password hashing creates an expensive verifier. A MAC or signature authenticates data within a defined trust model. Encryption protects confidentiality for key holders. None substitutes for the others.
Small omissions often open the path: one missing ownership check, one reusable credential in telemetry, one unbounded recovery endpoint, or one dependency deployed past its supported lifetime. The surrounding notes isolate those mechanisms. This page keeps their shared design process visible.
Secure System Design Checklist
Start with one abuse case, not a catalog of controls. For a payroll export, identify the employee records as assets, payroll staff and the export worker as actors, and the browser, API, job queue, object store, and third-party delivery service as separate trust boundaries. Then make each control answer a concrete path through those boundaries.
- Assets and actors: classify the data and operations, name legitimate actors, and describe what an attacker gains. See Sensitive Data.
- Trust boundaries: draw where identities, data, and administrative control cross processes, networks, tenants, and vendors.
- Identity and access: authenticate each actor, authorize the exact resource and action, deny by default, and keep privileges narrow. See Authentication and Authorization Models.
- Secure defaults: expose only required endpoints and methods, close unused ports, reject unknown input, and make a missing policy fail closed. See Firewall, OWASP, and Web Vulnerabilities.
- Secrets and keys: keep credentials out of code and telemetry, use managed key storage, separate key and data administration, and test rotation. See Secrets Management and Encryption.
- Dependencies and delivery: pin and verify build inputs, scan deployed artifacts, protect CI identities, and keep a current inventory of components and public APIs.
- Detection: record authentication, authorization, administrative, and sensitive-data events with safe metadata. Alert on an attack pattern rather than one expected denial.
- Response and recovery: assign incident owners, preserve evidence, revoke compromised access, communicate under the applicable obligations, and restore from a tested recovery path.
A checklist becomes evidence only when its failure paths are exercised. The payroll export should reject another tenant, a missing policy, a revoked job identity, and a stale signing key. Operations should also know what happens when audit delivery fails or the only clean backup predates the incident.
Questions
How do authentication and authorization work together when handling a request?
Authentication establishes who or what is making the request and produces a principal. Authorization then checks whether that principal may perform the requested action on the specific resource in the current context. A valid identity does not grant access to every resource, so both checks are required.