Security Headers Generator

What the Security Headers Generator does

Security headers are HTTP response headers that tell the browser to enforce protections on your page: connect only over HTTPS, run only approved scripts, refuse to be framed by other sites, and share less of the URL with other sites. They are set in your web server, CDN or hosting configuration, not in the page content.

This generator produces a set of headers from your choices: Strict-Transport-Security (HSTS) with optional includeSubDomains and preload, a Content-Security-Policy from a basic or a strict nonce-based preset, X-Frame-Options, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy. You get the result as raw header lines, as nginx add_header directives, as Apache Header set directives, or as a _headers file for Netlify and Cloudflare Pages.

Why it matters

Each header closes a class of attack cheaply. HSTS stops downgrades to plain HTTP on hostile networks, a Content-Security-Policy turns many cross-site scripting bugs into blocked requests, framing protection prevents clickjacking, and nosniff stops browsers from guessing content types. Most are one line of configuration once you have the exact syntax.

The syntax is where mistakes happen: a missing quote around 'self', a semicolon in the wrong place, or an nginx add_header inside a location block, which silently replaces every header set at server level. Generating the headers avoids typos, but the policy choices are still yours. See our guides to Content-Security-Policy and HSTS.

How to fix common problems

Paste the output where your server builds responses: the nginx server block (with the always flag, so headers are also sent on error responses), an Apache virtual host or .htaccess file with mod_headers enabled, or a _headers file in the publish directory for Netlify and Cloudflare Pages. If a CDN or framework already sets some of these headers, remove the duplicates so only one value is sent.

Roll out carefully. Start HSTS with a short max-age, such as one day, and raise it once every page and subdomain works over HTTPS; add preload only when you are sure, because leaving the preload list is slow. Deploy the CSP first as Content-Security-Policy-Report-Only, watch the browser console and reports, then enforce it. The strict preset needs a fresh random nonce on every response, added to each script tag by your server or framework; a fixed nonce gives no protection.

Then run the Security Headers Checker against the live URL to confirm every header arrives and to see your grade. The full PerfoMetrix audit checks them alongside TLS, cookies and 170+ other checks.

Questions

Basic or strict CSP: which should I choose?

A source-list policy is easier to deploy on an existing site with inline scripts and third-party tags, but allowlists can often be bypassed and 'unsafe-inline' removes most of the protection. A strict nonce-based policy is stronger and needs your server to add a fresh nonce to every script tag.

Do I still need X-Frame-Options if my CSP has frame-ancestors?

Current browsers use frame-ancestors and ignore X-Frame-Options when both are present. Sending both is harmless and covers older clients.

Should I add X-XSS-Protection?

No. It is obsolete and ignored by current browsers. A Content-Security-Policy is its replacement.

Will COOP break my login pop-ups?

Cross-Origin-Opener-Policy: same-origin cuts the link between your page and pop-ups on other origins, which can break OAuth or payment pop-ups. Use same-origin-allow-popups if you rely on them.