HTTP Security Headers Generator: A Sensible Default Set, Built From Toggles
Setting up security headers from a blank page means remembering exact directive syntax for half a dozen unrelated headers — HSTS's max-age and includeSubDomains, CSP's source-list syntax, Permissions-Policy's empty-allowlist notation. This generator builds a sensible starting set from simple toggles, so you end up with correct syntax to adapt to your actual site.
Each header defends against a distinct class of attack — they're complementary, not redundant.
Six Headers, Six Different Jobs
HSTS prevents protocol-downgrade attacks by forcing HTTPS. X-Content-Type-Options stops browsers from guessing (and misinterpreting) a resource's type. X-Frame-Options blocks clickjacking via iframe embedding. CSP restricts where scripts and other resources can load from. Referrer-Policy limits what URL information leaks to other sites on navigation. Permissions-Policy restricts which browser APIs (camera, geolocation) a page can access. None of these substitute for the others.
Starting Restrictive vs. Starting Permissive
The defaults here lean restrictive — default-src 'self' for CSP, SAMEORIGIN for X-Frame-Options, an empty Permissions-Policy allowlist. This is intentional: it's much easier to loosen a header you understand than to debug a wide-open policy that's silently allowing more than you intended. Expect to add specific allowances as you test your actual site against these headers.
Deploying These Headers
This tool generates the header text, but actually sending them requires server-side configuration — an Nginx add_header directive, an Express middleware, a Next.js headers() config, or your CDN/edge platform's header rules, depending on what's serving your responses.
Practical Examples
A Standard Public Website
Balanced security defaults.
- 1.HSTS: 1 year + includeSubDomains
- 2.X-Frame-Options: SAMEORIGIN
- 3.CSP: default-src 'self'
A Site With No Framing Use Case
Maximum clickjacking protection.
- 1.X-Frame-Options: DENY
- 2.Blocks all iframe embedding, including by your own pages
Headers This Generator Builds
- Strict-Transport-Security: HTTPS enforcement
- X-Content-Type-Options: MIME-sniffing protection
- X-Frame-Options: clickjacking protection
- Referrer-Policy: referrer leakage control
- Permissions-Policy: browser feature restriction
- Content-Security-Policy: resource source restriction
Good Use Cases
- Setting up security headers for a new project
- Establishing a baseline before a security review
- Learning correct syntax for each header
- Generating a starting config to adapt into your server framework
Frequently Asked Questions
Is this the same as the HTTP Header Analyzer?
No — the Analyzer reads headers you already have and checks what's missing. This tool builds a recommended header set from scratch via toggles, for when you're setting up headers on a new project or service rather than auditing an existing one.
What's a safe starting Content-Security-Policy?
default-src 'self' is a reasonable, restrictive starting point — it only allows resources (scripts, styles, images, etc.) to load from your own origin unless a more specific directive overrides it. Real sites usually need to add specific allowances (script-src, style-src) for CDNs, analytics, or embedded content, so treat this as a starting point to refine, not a final policy.
Why is X-Frame-Options set to SAMEORIGIN by default?
SAMEORIGIN allows your own pages to frame each other (useful for some internal tooling) while blocking other sites from embedding your page in an iframe — the common clickjacking defense. DENY is stricter (blocks framing entirely, including by your own other pages) if you have no legitimate framing use case.
What does the Permissions-Policy example mean?
camera=(), microphone=(), geolocation=() disables those three browser features entirely for the page and any embedded iframes — an empty allowlist means 'no origin, including this one, may use this feature.' Adjust the list to match which features your site actually needs.
Should I set includeSubDomains on HSTS?
Only if every subdomain of your domain is actually served over HTTPS — includeSubDomains applies the HSTS policy to all subdomains too, and if any subdomain isn't HTTPS-ready, this can break access to it entirely until that's fixed.
Does generating these headers automatically apply them?
No — this builds the header text only. You still need to configure your web server, framework, or CDN to actually send these headers on responses, using whatever configuration method that platform provides.