Security headers guide

Security Headers: What They Are and How to Check Your Website

Security headers are instructions your web server sends back with every page, telling the visitor's browser how to treat your site. They are part of the HTTP response, which is why they are also called HTTP security headers or website security headers.

They are useful, they are usually inexpensive to configure, and they are only one layer of defence. Headers do not patch software, protect your hosting account or replace backups. This guide explains what each of the main headers does in plain English, then points to a deeper guide for each one.

Check your website security headers

What are security headers?

When someone visits your website, your server returns the page content plus a set of response headers. Some of those headers are purely technical housekeeping. A handful of them change browser behaviour in ways that reduce the impact of common web attacks — those are the ones people mean by security headers.

Because they are browser-facing, their effect depends on the visitor's browser honouring them. Modern browsers support the headers described here, but an attacker who is not using a browser is unaffected. Treat headers as risk reduction, not as a boundary control.

They are sent by your server (or CDN, proxy or hosting platform), not written into your page content.
They apply to what the browser does with your site — framing, script sources, transport, content types.
They are visible from outside, so anyone can check them, including you.

The headers most Australian small businesses ask about

Four headers come up in almost every website security conversation. Each has its own guide with practical detail:

Content-Security-Policy — controls which sources the browser may load scripts, styles, images and frames from.
Strict-Transport-Security (HSTS) — tells supporting browsers to use HTTPS for your host on later visits.
X-Frame-Options — limits whether other sites may embed your pages in a frame, which is the basis of clickjacking.
X-Content-Type-Options — stops browsers guessing a file's type when your declared Content-Type says otherwise.

How to run a security headers check

You do not need server access to check security headers. Open your site in Chrome, press F12 to open DevTools, choose the Network tab, reload the page, click the top-level document request and read the Response Headers panel. Whatever your server returned is listed there.

Command-line users can request just the headers with a tool like curl. Third-party scanners do the same thing and present it as a report. Whichever method you use, check a real page on your live site rather than a staging copy, because hosting and CDN settings often differ.

What headers will not do

Adding headers does not make a website secure on its own. Out-of-date plugins, weak passwords, exposed admin panels, misconfigured DNS and unprotected email domains are all unaffected by response headers.

It is also possible to break a working site by adding a policy that is too strict — a Content-Security-Policy in particular needs to match the resources your site genuinely loads. Change headers deliberately, test them, and keep someone available who can roll a change back.

Check your website security headers

ScoutLab's free website security check looks at whether these headers are present and how they are configured on your public site, alongside HTTPS, DNS and email protection signals. It reports what it observes so you can discuss the results with whoever maintains your website.

Run the free website security check

Guides for each security header

Content Security Policy header: what CSP does and how to check itWhy a copied CSP string is risky, and how Report-Only helps you test one safely.

Strict-Transport-Security header (HSTS) explainedWhat max-age, includeSubDomains and preload mean before you enable them.

X-Frame-Options: DENY, SAMEORIGIN and clickjackingWhy ALLOW-FROM is obsolete and where CSP frame-ancestors fits.

X-Content-Type-Options and the nosniff directiveWhat MIME sniffing is and why correct Content-Type values still matter.

Run the free website security checkSee which of these headers your site currently returns.

Frequently asked questions

What are security headers?

Security headers are HTTP response headers your web server sends alongside each page. They tell the visitor's browser how to handle your site — for example which script sources to trust, whether the page may be framed by another site, and whether to insist on HTTPS. They are a browser-facing control and one layer of defence among many.

How do I check security headers in Chrome?

Open your site in Chrome, press F12 for DevTools, select the Network tab and reload the page. Click the first document request and open the Response Headers section. Everything your server returned is listed there, including any security headers that are present.

Are security headers enough to secure a website?

No. Headers reduce the impact of specific browser-side attacks, but they do nothing about outdated software, weak credentials, exposed administration interfaces, DNS problems or email spoofing. They are worth configuring, and they belong alongside patching, access control and backups rather than instead of them.

Which security headers should a small business website have?

Most small business sites benefit from Strict-Transport-Security once HTTPS is working reliably, X-Content-Type-Options with nosniff, framing protection through X-Frame-Options or CSP frame-ancestors, a Referrer-Policy, and eventually a Content-Security-Policy tailored to the site. The right combination depends on how the site is built and hosted.

Can adding security headers break my website?

It can. A restrictive Content-Security-Policy can block scripts or styles the site relies on, and framing restrictions can break legitimate embeds. Introduce changes one at a time, test on a representative page, and make sure the change can be reversed quickly by whoever manages your hosting.

Technical references

Security headers are browser-facing HTTP response controls and one layer of defence. They work alongside patching, access control, backups and monitoring rather than replacing them.