HTTP Security Header Generator
Generate essential HTTP security headers for your website. Build Content-Security-Policy, HSTS, X-Frame-Options, Referrer-Policy, and Permissions-Policy. Get copy-paste configs for Apache (.htaccess), Nginx, and raw HTTP headers.
Key Facts
- Content-Security-Policy: The most powerful header, introduced as a W3C Recommendation (Level 3, 2023). Controls which resources browsers can load. A strict CSP reduces XSS attack surface by over 90% per Google Security Research. Only approximately 15% of top 1 million websites implement a strict CSP as of 2024
- Strict-Transport-Security: Defined in RFC 6797 (2012). Forces HTTPS and prevents SSL stripping. max-age of 31,536,000 seconds (1 year) is the standard. Approximately 25% of top websites use HSTS, and the HSTS Preload List contains over 200,000 domains as of 2025
- X-Frame-Options: Defined in RFC 7034 (2013). Prevents iframe-based clickjacking. DENY or SAMEORIGIN are the safe values. Approximately 35% of the top 1 million websites set this header
- X-Content-Type-Options: Set to "nosniff" to prevent MIME-type sniffing. Introduced by Microsoft in 2008, now supported by 100% of modern browsers. Approximately 40% of top websites deploy it
- Referrer-Policy: Standardized by W3C in 2017. "strict-origin-when-cross-origin" is the recommended default (used by approximately 80% of sites that set this header). Prevents leaking sensitive URL parameters to third parties
- Permissions-Policy: Successor to Feature-Policy (renamed in 2020). Restricts 30+ browser APIs (camera, microphone, geolocation, payment). Only approximately 5% of websites use it despite its importance for third-party script containment
Content-Security-Policy Quick Guide
- default-src 'self': Only allow resources from your own domain. Google's 2016 CSP study found that approximately 95% of CSP bypasses are caused by overly permissive source lists
- script-src: Controls JavaScript sources. Per Google CSP research, using 'unsafe-inline' renders approximately 90% of CSP protections ineffective. Use nonces or hashes instead
- style-src: Controls where CSS can load from. 'unsafe-inline' is often needed for inline styles but reduces security
- img-src: Controls where images can load from. Often needs 'data:' for inline images and specific CDN domains
- report-uri / report-to: Sends violation reports to a URL. Use Content-Security-Policy-Report-Only to test before enforcing
- upgrade-insecure-requests: Automatically upgrades HTTP resource requests to HTTPS. Useful during HTTP-to-HTTPS migration
Questions & Answers About Security Headers
Q: What are HTTP security headers?
HTTP security headers are directives sent by servers that instruct browsers to enable security features. Per the OWASP HTTP Headers Cheat Sheet, there are 6 essential headers protecting against clickjacking, XSS, protocol downgrade, MIME sniffing, and data leakage. Despite this, only approximately 20% of websites implement all recommended headers as of 2024.
Q: Which security headers are most important?
The three most critical are Content-Security-Policy (prevents XSS and code injection), Strict-Transport-Security (forces HTTPS), and X-Frame-Options (prevents clickjacking). Implementing these 3 headers alone mitigates approximately 85% of common web vulnerabilities listed in the OWASP Top 10 (2021 edition). X-Content-Type-Options and Referrer-Policy are also strongly recommended.
Q: Will security headers break my website?
Overly strict Content-Security-Policy headers can break functionality by blocking legitimate scripts, styles, or resources. Start with CSP in report-only mode (Content-Security-Policy-Report-Only) to identify issues before enforcing. The other headers rarely cause problems. Always test thoroughly in a staging environment first.
Q: How do I check if my site has security headers?
Use browser developer tools (Network tab → click a request → look at Response Headers). Online tools like securityheaders.com (by Scott Helme) and Mozilla Observatory can audit your headers and provide grades. Approximately 70% of scanned websites score below a C grade. Our generated configs can be added directly to your Apache or Nginx configuration files.
Q: Do security headers replace a WAF or firewall?
No. Security headers complement firewalls and WAFs but do not replace them. Headers instruct the browser to enforce security policies (client-side), while a WAF inspects incoming requests (server-side). Per NIST SP 800-44 guidelines for securing web servers, both are needed for defense in depth. Headers are free to implement and should always be configured regardless of other security measures.