Skip to the content

Security

Security headers: what to send, and why

A handful of HTTP response headers make browsers stricter about how they treat your site. They are configuration, not code, and most of them are safe to add today. Here is what each one does and how to deploy them.

Aback Audit

Guides from the team behind the 55 checks

SecurityUpdated 27 October 20262 minute read
  • Start with the safe baseline. HSTS, nosniff, Referrer-Policy and framing protection rarely break anything.
  • Content-Security-Policy is the strongest and the most delicate. Ship it in report-only mode first.
  • Mixed content and a broken certificate are real risks for visitors. Missing headers are hardening.
  • Set headers once, at the edge or the server, so every response carries them.
On this page
  1. The baseline
  2. Content-Security-Policy
  3. The real risks: HTTPS and mixed content
  4. Deploy

The baseline

These headers are safe for nearly every site. Add them first.

Strict-Transport-Security

Strict-Transport-Security: max-age=31536000; includeSubDomains

Tells the browser to use HTTPS for your domain for a year, even if someone types http://. It removes the first insecure request and protects against downgrade attacks. Add it once the whole site works over HTTPS. Use includeSubDomains only when every subdomain does.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Stops browsers from guessing a file’s type from its content. Without it, an uploaded file served as text could be run as a script.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Controls how much of the current url is sent to other sites when a visitor follows a link. This value sends only the origin to other sites, and nothing when going from HTTPS to HTTP. It is the browser default today, and stating it makes it explicit.

Framing protection

X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'

Prevents other sites from loading your pages in a frame, which is how clickjacking works. frame-ancestors is the modern way and wins when both are present.

Permissions-Policy

Permissions-Policy: camera=(), microphone=(), geolocation=()

Turns off browser features the site does not use, so an injected script cannot use them either.

Content-Security-Policy

A CSP lists where scripts, styles, images and other resources may come from. If an attacker manages to inject a script tag, the browser refuses to run it. It is the most effective defence against cross site scripting, and the easiest header to get wrong.

Roll it out in three steps

  1. Report only. Send Content-Security-Policy-Report-Only with a policy. Nothing is blocked; violations are logged in the browser console and, if you add a reporting endpoint, sent to you.
  2. Fix the violations. Move inline scripts to files, or allow them with hashes or nonces. List the third party hosts you really use.
  3. Enforce. Rename the header to Content-Security-Policy.

Avoid unsafe-inline for scripts

script-src 'unsafe-inline' allows every inline script, including injected ones, which defeats the main purpose of a CSP. Use a nonce generated per response, or hashes of the inline scripts you control.

The real risks: HTTPS and mixed content

Two findings matter more than any missing header:

  • A certificate that does not validate shows visitors a full page warning. Check every hostname with the SSL checker.
  • Mixed content, an https page loading scripts or styles over http, lets a network attacker change the page. Browsers block most of it, which breaks the page instead.

Deploy

The security headers generator writes the configuration for Nginx, Apache, Cloudflare and Netlify _headers files and Vercel. Deploy it, then confirm with the security headers checker, which reads the live response and checks the values, not just whether a header exists.

Check your own site

The Security Headers Checker runs the checks from this guide on any public page, free and without an account.

Open the Security Headers Checker

Frequently asked questions

Do security headers affect SEO?

Not directly. HTTPS is a light ranking signal and browser warnings drive visitors away, so the effect is indirect.

Is X-XSS-Protection still useful?

No. Browsers removed the filter it controlled. Use a Content-Security-Policy instead, and send no X-XSS-Protection or set it to 0.

Should I use HSTS preload?

Only when every subdomain, now and in the future, supports HTTPS. Getting removed from the preload list takes months.

Where should I set the headers?

As close to the edge as possible, at your CDN or web server, so they apply to every response including error pages and static files.

Keep reading

Browse every guide
↑ ↓ to move↵ to openesc to close