FREE Security LESSON · Security
Threat-model the boundary
Assets, actors, capabilities, and invariants
Start from what must remain true.
List the assets and the security properties they require. Draw data flows, identities, and trust boundaries. Describe attackers by capability and access—not movie-villain labels. Then write abuse cases that violate a specific invariant. Controls can be evaluated only against these paths; a checklist without a model creates activity without coverage.
The same component can be trusted for availability and untrusted for content.
Authentication does not imply authorization.
Knowing who made a request does not prove they may perform the action on this object in this state. Authorization must bind principal, action, resource, context, and policy at the authoritative server boundary. UI hiding, route naming, and possession of an identifier are not permissions.
Ask “who may do what to which object under which conditions?”