A practical, copy-paste friendly guide to CSP, HSTS, XFO, and other headers — with safe starting values.
Who this is for
- Builders shipping web apps or APIs
- Anyone who wants a “do this, then verify” checklist
- Teams that need repeatable, documented steps
The core idea
Security work is easier when you turn it into a small number of verifiable controls. For Security Headers Checklist for Production, focus on:
- Reduce attack surface (disable what you don’t use)
- Harden defaults (safe configs, least privilege)
- Observe (logs + alerts so you notice failures)
- Verify (a simple test that proves the control works)
Step-by-step
- Define the boundary
- What system/component are you protecting?
- What counts as “success” and “failure”?
- Apply the control
- Prefer configuration changes over custom code where possible.
- Add a quick verification
- A command, a curl request, or a log line you can check.
- Document the “rollback”
- If something breaks in prod, what do you revert first?
Practical checklist
- Identify the most likely abuse cases (auth bypass, data leak, RCE, DoS)
- Set secure defaults in configuration
- Enable logging for the control and confirm events are recorded
- Run a verification test and store the result
- Add a short “maintenance” note (what to re-check monthly)
Common mistakes
- Relying on one layer: assume a control can fail—add a second one.
- No verification: if you can’t test it, you can’t trust it.
- No operational owner: decide who responds when it triggers.
Next steps
If you’re building out a security baseline, turn this into a reusable template for other topics like rate limiting, secrets management, and dependency scanning.
Tags: web, headers, csp