Essential HTTP Security Headers

HTTP security headers are response headers that tell the browser how to behave on your site, and the right set closes off whole classes of attacks like XSS, clickjacking, and protocol downgrades. You set them once at the server or CDN, and every visitor is protected. Here are the headers that matter and what each one defends against.

The security headers that matter

Each header below addresses a specific threat. Send all of them where you can.

Strict-Transport-Security (HSTS): forces browsers to use HTTPS for your domain, even if a user types http:// or clicks an old link. This blocks protocol downgrade and SSL-stripping attacks. A typical value is max-age=31536000; includeSubDomains.
Content-Security-Policy (CSP): limits where scripts, styles, images, and other resources are allowed to load from. This is the single strongest defense against cross-site scripting (XSS), because an injected script from an unapproved source simply will not run. CSP is also the trickiest header to deploy, so it needs careful testing (more on that below).
X-Content-Type-Options: nosniff: stops the browser from guessing (“sniffing”) a file’s content type. Without it, an attacker can trick the browser into treating an uploaded image or text file as executable script.
X-Frame-Options / frame-ancestors: prevents your pages from being embedded in an iframe on another site, which defeats clickjacking. The modern approach is the CSP frame-ancestors directive; X-Frame-Options: DENY is the older header kept for legacy browsers.
Referrer-Policy: controls how much of the referring URL is sent when users navigate away. strict-origin-when-cross-origin is a safe default that avoids leaking full paths and query strings to third parties.
Permissions-Policy: switches off browser features your site does not use, such as camera, microphone, and geolocation, so a compromised script cannot quietly request them.

Why CSP is the strongest but needs testing

A good Content-Security-Policy stops most injected scripts cold, but a strict policy can also break your own inline scripts, analytics, fonts, and embeds if you do not account for them. Roll it out carefully: start with Content-Security-Policy-Report-Only, watch the violation reports for legitimate resources you missed, refine the policy, and only then switch to enforcing mode. Test every key template before going live.

Generate your headers

The fastest way to get a correct, copy-paste-ready set is the Security Headers Generator. It builds the exact header block for your stack.

Open the Security Headers Generator.
Pick the headers you want and set values like HSTS max-age and your allowed CSP sources.
Choose your server format (Nginx, Apache, or a generic header list).
Copy the output and paste it into your server config or CDN edge rules.
Deploy, then reload your site and confirm the headers appear in the response.

Everything runs in your browser, so nothing you type is sent anywhere.

Where to set them

Headers belong at the server or CDN layer, not in page markup. Add them to your Nginx or Apache config, or set them as edge rules in Cloudflare or your CDN so they apply to every response in one place. After deploying, check the live response with your browser dev tools or an HTTP Header Analyzer.

CSP Builder: build and refine a Content-Security-Policy directive by directive.
CORS Header Validator: check your cross-origin headers are configured correctly.
HTTP Header Analyzer: inspect the headers a live URL actually returns.

Set these once at the edge and you harden every page on your site in a single deploy.