HTTP Security Headers: A Practical Guide

Updated 16 September 2026 · 3 min read

Check your own site as you read: HTTP Header Checker · SSL Checker

Every response your server sends comes with HTTP security headers — or, more often, without them. Each one closes a common attack: forcing HTTPS, blocking cross-site scripts, stopping other sites from framing your pages. None of them are on by default on most stacks, so adding them is some of the cheapest hardening you can do. This guide explains the headers that matter, what each one does, and how to add them.

What HTTP headers are

When a browser requests a page, the server replies with the content plus a set of headers — invisible lines that describe the response and tell the browser how to treat it. Some are about caching and content type; a handful are about security. You can see all of them for any URL with the HTTP Header Checker.

The headers that matter

Strict-Transport-Security (HSTS)

Tells browsers to only ever load your site over HTTPS, even if someone types http://. This closes the window where a first, unencrypted request could be intercepted.

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

Start with a shorter max-age while you confirm every subdomain works over HTTPS, then raise it. HSTS only applies to sites already served over HTTPS — check your certificate with the SSL Checker first.

Content-Security-Policy (CSP)

The most powerful header, and the most involved. It lists exactly where scripts, styles, images and frames are allowed to load from, which is the strongest defence against cross-site scripting (XSS). A strict policy is hard to retrofit, so start in report-only mode:

Content-Security-Policy-Report-Only: default-src 'self'

Watch what it would block, loosen it where legitimate resources are refused, then switch to the enforcing Content-Security-Policy header.

X-Content-Type-Options

Stops browsers from guessing (MIME-sniffing) a response's type, which can turn an uploaded file into an executable script. There is only one value:

X-Content-Type-Options: nosniff

Clickjacking protection

Stops other sites loading your pages inside an invisible frame to trick users into clicking. Either header works; a CSP frame-ancestors rule is the modern form:

X-Frame-Options: SAMEORIGIN

Referrer-Policy

Controls how much of your URL is sent to other sites when a visitor clicks a link out. A sensible default:

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

Permissions-Policy

Switches off browser features the page does not need — camera, microphone, geolocation — so a compromised script cannot reach them.

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

Where to add them

You set these headers in one of three places, depending on your setup:

  • Web server: an add_header block in Nginx, or Header set in Apache's config or .htaccess.
  • CDN: most CDNs (Cloudflare and others) let you add response headers to all traffic — often the easiest place if you run one.
  • Application: a middleware in your framework that adds the headers to every response.

Add them in one place only, so you do not send conflicting values.

How to check your headers

  1. Run your URL through the HTTP Header Checker. It flags each security header as present or missing, and shows caching, compression and the redirect chain too.
  2. Add the missing headers in your server, CDN or app.
  3. Re-check. Remember a CDN may cache the old response for a while — look at the Age or cache-status header.

Headers are also a speed lever, not just a security one — see How to Improve Website Speed for the caching and compression side.

Frequently asked questions

Are HTTP security headers required?

No — a site works without them. But each one closes a well-known attack, so they are recommended hardening. Missing headers are not a bug; they are protection you can add.

Which security headers should I add first?

Start with the easy, low-risk ones: Strict-Transport-Security, X-Content-Type-Options: nosniff, and clickjacking protection (X-Frame-Options or a CSP frame-ancestors rule). Content-Security-Policy is the most powerful but takes the most care, so build it in report-only mode.

Will adding these headers break my site?

HSTS, nosniff and clickjacking protection are low-risk on a normal site. A strict Content-Security-Policy can block legitimate scripts, which is why you roll it out in report-only mode first and watch what it would block.

Do security headers help SEO?

Not directly. They protect users and your site. HTTPS itself is a light ranking signal, and HSTS supports keeping everything on HTTPS, but the headers are about security, not rankings.

What is the difference between the HTTP Header Checker and the SSL Checker?

The HTTP Header Checker reads the response headers, including the security ones. The SSL Checker inspects the TLS certificate itself — who issued it, when it expires, and which hostnames it covers.