Security headers are short instructions your web server sends to browsers alongside every page. They tell the browser what to trust, what to block, and how to behave when loading resources. Most small business owners never see them because they sit inside the HTTP response rather than the visible webpage. But they make a real practical difference to how safely your site can be used.
The headers that reduce common browser-side risks
Strict-Transport-Security (HSTS) tells browsers to only connect to your site using HTTPS and to remember that instruction for a set period. Without it, a visitor on public WiFi could be quietly redirected to an insecure version of your site before HTTPS kicks in. With HSTS, the browser refuses to make that insecure connection at all.
Content-Security-Policy (CSP) is a list of sources your page is allowed to load scripts, images, and styles from. A strict policy means that even if a third-party service you embed gets compromised, the malicious code it tries to inject will be blocked rather than executed. CSP is one of the harder headers to configure correctly because it requires you to know every external source your site uses, but even a basic policy is better than none.
X-Frame-Options prevents your site from being embedded inside another page's iframe. This blocks a class of attack called clickjacking, where a user is tricked into clicking something on your site while thinking they are interacting with something else. Setting it to SAMEORIGIN means only your own pages can embed your content.
X-Content-Type-Options: nosniff stops browsers from guessing what kind of file they are loading. Without it, a browser might treat a plain text upload as executable JavaScript if an attacker can influence the filename. This header costs nothing to add and has no downside.
Referrer-Policy controls how much of your URL is shared when a visitor follows a link to another site. A strict policy keeps internal URLs and query strings private, which matters if your URLs contain session tokens or search terms you would rather not share.
Why missing headers do not always mean hacked
A scan finding that flags missing headers is not a sign that your site has been compromised. It means the server configuration has not been set up with those protections. Many websites — including those run by larger organisations — are missing one or more headers. The finding is a gap, not an incident.
The practical risk of a missing header depends on your site's setup. A simple brochure site with no login form, no payment processing, and no user-submitted data has a different risk profile from an e-commerce site or a WordPress installation with multiple plugin-loaded scripts. Prioritise fixes based on what your site actually does.
Which fixes are safe to stage first
The safest headers to add first are those with no known side effects on a standard site: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, and Referrer-Policy: strict-origin-when-cross-origin. These can usually be added via your hosting control panel, a WordPress security plugin, or directly in your .htaccess file on Apache servers.
HSTS and CSP require more care. HSTS should only be enabled once you are confident your entire site runs on HTTPS — including all subdomains if you use the includeSubDomains flag. CSP should be tested in report-only mode first so you can see what would be blocked before enforcing it.
- Start with nosniff, X-Frame-Options, and Referrer-Policy — low risk, easy to add.
- Enable HSTS only after confirming HTTPS is consistent across the whole site.
- Test CSP in report-only mode before switching to enforced mode.
- Re-scan after each change to confirm headers appear correctly.
HSTS, CSP, X-Frame-Options, and cookie flags are not just developer jargon.
Run the free website security scanner