What security headers should my small business website have?

Five headers, in the order they earn their keep: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, and X-Frame-Options. That is the complete answer for a small business website - and the rest of this page is what each one actually prevents, how to check yours in 30 seconds, and the exact request to hand your developer or hosting provider.

Security headers are the highest-leverage item on the website security checklist because of their effort-to-effect ratio: they are configuration, not development. There is no software to buy and no code to rewrite - a short block pasted into a server or hosting control panel, once, and every page on your site is harder to attack from that moment on.

First, the 30-second check

Paste your website address into Security Headers - a free checker that grades exactly this - or Mozilla Observatory, which checks the same things with a slightly sterner marking guide. You will get a letter grade and a list of what is present and missing. Most Australian small business sites land at D or F, and the baseline data says why: four in five have no Content-Security-Policy, and 7 in 10 are missing HSTS^*.

Run the check before reading on. The rest of this page makes much more sense with your own grade in front of you.

What each header prevents

Strict-Transport-Security (HSTS)

The browser remembers, for as long as the header specifies, that your site is HTTPS-only - and refuses to attempt an unencrypted connection, even when the visitor types the bare address or follows an old http link. Without it, that first unencrypted request is intercept-able on hostile networks. 7 in 10 Australian small business websites do not send it^*. One genuine caution: HSTS holds you to it. Enable it only once HTTPS works across the whole site - subdomains included if you use the includeSubDomains directive - and start with a modest max-age raised after a quiet fortnight.

Content-Security-Policy (CSP)

The workhorse - and the one missing from four in five Australian small business websites^*. A CSP names the sources your pages may load scripts, styles and frames from, and the browser blocks everything else. It is the main browser-side defence against injected code: a compromised plugin or a hostile comment that smuggles a script into your page achieves nothing if the policy refuses to run it. It is also the only header on this list that takes real care, because a policy that is too strict blocks your own analytics, fonts or payment widgets. The safe path is built into the standard: deploy as Content-Security-Policy-Report-Only first, watch what would have been blocked, fix the legitimate cases, then enforce.

X-Content-Type-Options: nosniff

One fixed value, no decisions to make. It stops browsers "sniffing" a file's content and reinterpreting it as something more dangerous than its label - the classic case being an uploaded file that claims to be an image but executes as a script. 63% of Australian small business websites are missing it^*, which is striking for a header with literally one correct setting.

Referrer-Policy

Controls what the visitor's browser tells the next site about where they came from. Without it, links from a page like yoursite.com.au/quote-request?customer=... can leak the full address - query string included - to whatever third-party site the visitor clicks through to. A value of strict-origin-when-cross-origin keeps it to the bare domain. 81% of Australian small business websites do not set one^*; for any site with customer-identifying URLs, this is quietly a privacy fix as much as a security one.

X-Frame-Options

Stops other sites loading your pages inside an invisible frame and tricking visitors into clicking things they cannot see - clickjacking, in the trade. SAMEORIGIN is the standard value; its modern replacement lives inside CSP as the frame-ancestors directive, so a site with a good CSP gets this for free. Until then, the standalone header costs nothing.

There is a sixth name you will see in older advice - Permissions-Policy, which limits page access to the camera, microphone and location. 93% of Australian small business websites do not send it^*, and for a brochure site it is the lowest stakes of the set: worth adding while your developer is in the config file anyway, not worth a ticket of its own.

The request to send your developer

The five headers above are deployed in one place - the web server config, the hosting control panel, or the CDN dashboard if you are behind one. Copy this to whoever manages yours:

Please add response headers to the site: Strict-Transport-Security (start max-age=86400, raise after testing), X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, and X-Frame-Options SAMEORIGIN. Then deploy a Content-Security-Policy in Report-Only mode, review the reports after a week, and enforce it. Verify against securityheaders.com before and after.

That is an hour or two of competent work, most of it the CSP review. If the answer you get back is a quote for a security retainer, the question was misunderstood - this is configuration, and item 3 of the checklist anyone can verify afterwards in 30 seconds.

What headers cannot do

Headers instruct the visitor's browser; they do not fix the server behind them. An out-of-date plugin, a guessable admin password or an exposed backup file is untouched by all five - those are separate items on the checklist, and the Australian Cyber Security Centre's small business hub covers the device-and-people half that no website setting reaches. Headers are one wall, not the building.

Our scan checks the full header set on every run - the same checks as the free graders, folded into one plain-English report alongside the domain, email and the rest of the checklist items, and re-checked on schedule so the grade you earned this month is still yours next month. One paste, permanent effect - but only if someone is watching that it stays pasted.