The principle of least privilege means giving each component, process, and person only the permissions needed for its intended task. The practical question is simple: if an attacker takes over this account or process, what damage can it actually do? Limiting permissions will not necessarily stop the initial compromise, but it limits what happens next. section 4.15 section 4.16
Limit access at every layer
An airport illustrates the idea: travelers, pilots, and maintenance staff can each enter only the areas required for their roles; nobody has unlimited access. Apply the same boundary to an application: prevent browser JavaScript from reading cookies and set a CSP; use a database account that can read and update data but cannot alter table structures; and run the web server as a nonroot user able to reach only its assets, configuration, and code. section 4.15
Use least privilege as a damage-control checklist:
- Separate organizational responsibilities across roles when practical, so one stolen or misused account cannot make every destructive change. section 5.2
- Time-box sensitive permissions, such as changing servers or upgrading database structures, rather than leaving them available indefinitely. section 5.2
- Keep private-key directories accessible only to the web server process or elevated users; do not expose keys in public static-asset directories. section 7.12
- Restrict the database account used by application code to the data-reading and data-updating permissions it needs, reducing SQL-injection impact. section 12.6
Least privilege complements defense in depth. Escaping input, parameterized database statements, and other controls aim to prevent attacks; permission boundaries reduce the harm when one of those controls is bypassed. For example, injected browser code may still be unable to steal cookies if JavaScript cannot access them, and injected SQL has less reach when the database account cannot change schema. section 4.15 section 12.6
Treat unexpected server access as a probable compromise. Restricting access is not the final step: review access logs, use intrusion detection review, and if TLS keys may be compromised, revoke certificates, regenerate keys, and make required disclosures. section 7.12
