Skip to content
Hookgap

Website security headers explained for small business sites

· 12 min read

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.
  • includeSubDomains applies 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-age of at least a year, includeSubDomains and preload. 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-uri and object-src is 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: nosniff

Frame 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: SAMEORIGIN

Use '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-origin

That 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, HttpOnly and have a SameSite value.
  • Advertised software versions: a generator meta tag or X-Powered-By header 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

PlatformWhere headers go
Cloudflare in front of any siteRules → Transform Rules → modify response headers. HSTS has its own setting under SSL/TLS → Edge Certificates.
ApacheHeader always set in the site config or .htaccess (needs mod_headers).
Nginxadd_header ... always; in the server block.
WordPress on shared hosting.htaccess, the host's control panel, or a well-maintained security plugin.
Netlify / Cloudflare PagesA _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

  1. Force HTTPS and fix any certificate warning.
  2. Add X-Content-Type-Options, Referrer-Policy and frame protection (low risk).
  3. Add HSTS with a short max-age, then raise it over a few weeks.
  4. Fix mixed content and cookie flags.
  5. Roll out CSP in report-only mode, tighten it, then enforce.
  6. 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.

More on website security