Security headers are short instructions a website sends with every page, telling the browser how to handle it more safely: always use HTTPS, do not let other sites frame this page, do not guess file types. They cost nothing, take minutes to add on most hosts, and are one of the clearest signs, visible to anyone, of whether someone is looking after a site.
This guide covers the headers Hookgap checks, what each one does, a safe value to start from and the traps to avoid.
First: HTTPS and the redirect
Before any header matters, the site must load over HTTPS with a certificate browsers trust, and plain http:// must redirect to it. Without the redirect, anyone typing the address or following an old link lands on the insecure version. Most hosts have a single "force HTTPS" setting. If the certificate is the problem, see SSL certificate lifetimes.
Strict-Transport-Security (HSTS)
Tells the browser: for the next N seconds, only ever connect to this site over HTTPS, even if someone types or links http://. It closes the gap that a redirect alone leaves open on the very first request.
Strict-Transport-Security: max-age=31536000; includeSubDomains- Start small:
max-age=300(five minutes) while testing, then a week, then a year. Once a browser has seen the header, it will refuse plain HTTP for that long, so a broken certificate means an unreachable site. includeSubDomainsapplies the rule to every subdomain. Only add it once every subdomain serves HTTPS.- Preload (submitting to browsers' built-in list via hstspreload.org) needs
max-ageof at least a year,includeSubDomainsandpreload. It is hard to undo; treat it as optional.
Hookgap flags HSTS that is missing, and HSTS shorter than 180 days, because a short max-age gives little protection.
Content-Security-Policy (CSP)
Lists where the page may load scripts, styles, images and frames from. If an attacker manages to inject a script, a good CSP stops the browser running it. It is the most powerful header and the one most likely to break things.
Content-Security-Policy: default-src 'self'; img-src 'self' data: https:; frame-ancestors 'none'; base-uri 'self'; object-src 'none'- Test first with
Content-Security-Policy-Report-Only. The browser reports what it would have blocked, without blocking it. Watch the browser console. - Avoid
'unsafe-inline'for scripts. It allows any inline script, which is exactly what injection relies on, so it removes most of the benefit. Hookgap reports it as a separate finding. Nonces or hashes let specific inline scripts run safely. - Small sites built on WordPress, Wix or Squarespace often load scripts from many places. A full CSP may not be practical; a CSP that only sets
frame-ancestors,base-uriandobject-srcis still worth having.
X-Content-Type-Options
Stops the browser guessing a file's type ("MIME sniffing") and treating, say, an uploaded text file as a script. There is only one value, and it is safe everywhere:
X-Content-Type-Options: nosniffFrame protection
Stops other sites loading this site invisibly inside a frame to trick visitors into clicking things (clickjacking). The modern way is the CSP directive; the older header still works and is widely supported:
Content-Security-Policy: frame-ancestors 'self' X-Frame-Options: SAMEORIGINUse 'none' / DENY if the site never frames itself. Check first that no booking or payment widget relies on framing the site.
Referrer-Policy
Controls how much of the current page's address is sent to other sites when a visitor clicks a link. Without it, full URLs (which can include search terms or IDs) may leak.
Referrer-Policy: strict-origin-when-cross-originThat value sends only the site name to other sites and nothing when going from HTTPS to HTTP. It is also the default in current browsers, but setting it explicitly makes the intent clear and covers older ones.
Two more things the homepage reveals
- Mixed content: images or scripts loaded over
http://on an HTTPS page. See mixed content warnings. - Cookies without the Secure flag: cookies that could be sent over an unencrypted connection. Session and login cookies should be
Secure,HttpOnlyand have aSameSitevalue. - Advertised software versions: a
generatormeta tag orX-Powered-Byheader naming the exact version. It does not make a site unsafe by itself, but it makes outdated software easy to spot, and removing it takes a minute.
How to add headers on common platforms
| Platform | Where headers go |
|---|---|
| Cloudflare in front of any site | Rules → Transform Rules → modify response headers. HSTS has its own setting under SSL/TLS → Edge Certificates. |
| Apache | Header always set in the site config or .htaccess (needs mod_headers). |
| Nginx | add_header ... always; in the server block. |
| WordPress on shared hosting | .htaccess, the host's control panel, or a well-maintained security plugin. |
| Netlify / Cloudflare Pages | A _headers file in the published folder. |
| Hosted builders (Wix, Squarespace) | Limited or no control; HTTPS and HSTS are usually handled by the platform. |
A safe order of work
- Force HTTPS and fix any certificate warning.
- Add
X-Content-Type-Options,Referrer-Policyand frame protection (low risk). - Add HSTS with a short max-age, then raise it over a few weeks.
- Fix mixed content and cookie flags.
- Roll out CSP in report-only mode, tighten it, then enforce.
- Add a security.txt file so people can report problems.
Checking a site
The browser's developer tools show every response header under Network. For a quick outside view, a Hookgap check reads the homepage once and reports each header, HSTS strength, CSP unsafe-inline, mixed content and cookies, alongside the site's certificate and email settings. Hookgap's own site sends all of the headers above; check hookgap.com to see what a passing result looks like.
Frequently asked questions
Which security headers should every website have?
At minimum: an HTTP to HTTPS redirect, Strict-Transport-Security, X-Content-Type-Options: nosniff, frame protection (frame-ancestors in a Content-Security-Policy, or X-Frame-Options) and a Referrer-Policy. A full Content-Security-Policy is the strongest and the most work.
Can security headers break a website?
Most cannot. HSTS can make a site unreachable if HTTPS later breaks, so increase its max-age gradually. A strict Content-Security-Policy can block scripts, so test it in report-only mode first.
Is X-XSS-Protection still needed?
No. Modern browsers have removed the filter it controlled. A Content-Security-Policy is the current way to limit script injection.
Keep reading
SSL certificate validity 47 days · 6 min read
SSL certificates are moving to 47 days: what MSPs should tell clients
The CA/Browser Forum schedule, why it is happening, and why manual renewals stop being viable for client websites.
mixed content fix · 5 min read
Mixed content warnings: what they mean and how to fix them
Why a padlock disappears, which mixed content browsers block, and how to find and fix every http:// reference.
security.txt · 4 min read
security.txt: what it is and how to add one in 10 minutes
A short file that tells people how to report a security problem. The required fields, an example, and what to do with reports.