Inventory scripts and third-party resources
Why it matters:A CSP is easier to maintain when you know what the site actually loads.
Safe action:List trusted script, style, image, frame, and connection sources before enforcing a policy.
Security Headers Checklist
Table of Contents
Quick Answer
A security headers checklist helps website owners review browser-side hardening controls such as Content Security Policy, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, and secure cookie flags.
What Are Security Headers?
Security headers are HTTP response headers that tell browsers how to handle content, framing, transport security, referrer data, browser features, and cookies. They do not fix vulnerable code by themselves, but they can reduce the impact of common web security mistakes.
How to Use This Checklist
Use this page during website review, launch preparation, and periodic security hardening. It is a manual checklist, not an online scanner. Review headers in your own website, staging system, or authorized environment.
Core Security Headers
| Header | What it helps with | Beginner check | Related risk |
|---|---|---|---|
| Content-Security-Policy | Limits where scripts, styles, frames, and other resources can load from. | Start with a report-only policy before enforcing strict rules. | XSS, script injection |
| Strict-Transport-Security | Tells browsers to use HTTPS for future visits. | Use only after HTTPS works correctly across the site and subdomains. | Downgrade and network interception risk |
| X-Content-Type-Options | Reduces MIME-type sniffing surprises. | Use nosniff where supported. | Unexpected script or file handling |
| X-Frame-Options or CSP frame-ancestors | Controls whether other pages can frame your site. | Prefer CSP frame-ancestors for modern policies. | Clickjacking |
| Referrer-Policy | Controls how much URL/referrer data is sent to other sites. | Choose a policy that balances analytics and privacy. | Information leakage |
| Permissions-Policy | Restricts browser features such as camera, microphone, and geolocation. | Disable features your site does not need. | Excess browser capability exposure |
| Set-Cookie flags | Protects cookies with Secure, HttpOnly, and SameSite attributes. | Apply flags to session and sensitive cookies. | Session theft and cross-site abuse |
Content Security Policy Checklist
Avoid unsafe inline patterns where possible
Why it matters:Inline script allowances weaken CSP protections.
Safe action:Prefer nonces, hashes, or external scripts controlled by the site.
Use report-only mode first
Why it matters:Strict CSP can break functionality if deployed blindly.
Safe action:Test reports, fix expected violations, then enforce gradually.
HSTS Checklist
- Confirm HTTPS is valid and stable across the site.
- Start with a conservative max-age before long-term enforcement.
- Use includeSubDomains only after all subdomains support HTTPS.
- Consider preload only when the domain is fully ready.
Clickjacking, Referrer, and Permissions Checks
- Use
frame-ancestorsor X-Frame-Options to reduce unwanted framing. - Use a Referrer-Policy that does not leak sensitive paths unnecessarily.
- Disable browser capabilities your site does not use with Permissions-Policy.
Cookie Security Header Checks
- Set Secure on cookies that should only travel over HTTPS.
- Set HttpOnly on cookies that do not need JavaScript access.
- Use SameSite thoughtfully for session and cross-site flows.
Common Mistakes
- Copying a strict CSP without testing.
- Using HSTS before HTTPS is stable.
- Forgetting cookies set by subdomains or third-party integrations.
- Assuming headers replace input validation or secure coding.
FAQs
A security headers checklist is a manual review aid for browser-side security headers such as CSP, HSTS, frame controls, Referrer-Policy, Permissions-Policy, and cookie flags.
No. This checklist does not scan websites or collect URLs. It is a reference page for manual review and defensive learning.
Start with HTTPS and HSTS basics, then learn Content Security Policy, clickjacking controls, Referrer-Policy, Permissions-Policy, and secure cookie flags.
No. Security headers reduce risk, but they do not replace input validation, output encoding, authentication, authorization, dependency patching, and secure design.
Sources and further reading
- MDN Web Docs - HTTP response headers — Browser HTTP header reference
- OWASP Secure Headers Project — Security header guidance and examples
- OWASP Content Security Policy Cheat Sheet — CSP design and deployment guidance