security headers

Security headers are short pieces of text that travel with every single page a server sends to a browser. A visitor never sees them directly, but their browser reads every one and obeys it. Each header switches off a specific way a page could be misused: whether it can be loaded inside someone else’s site, whether a form on it can send data somewhere other than your own server, whether the page is even allowed to ask for a visitor’s camera or location.

On their own, none of these headers stop a determined attacker with real skill. What they do is close off the cheap, automated tricks that make up the vast majority of real-world attacks against small business websites. A scanner probing thousands of sites for easy targets moves on when it finds a site that has already switched off the obvious openings.

Why it matters to you

Most small business sites never think about this because most small business sites run on WordPress plugins that were not built with it in mind, and adding it after the fact means finding the right plugin, configuring it correctly, and hoping nothing overrides it later. On a site with nothing to break into in the first place, security headers are one more layer that costs nothing and needs no maintenance, because they are written once into the site’s configuration rather than bolted on afterward.

There is also a practical business reason. Cyber insurance questionnaires and procurement checklists from larger clients increasingly ask directly whether these headers are in place. Being able to say yes without qualification, because they were built in from the start, avoids an awkward back and forth.

How I set it up

Security headers ship with the site’s configuration, not as an add-on. Every response carries the same set: HTTPS forced for a full year including subdomains, framing blocked so the site cannot be embedded inside someone else’s page, forms restricted so they can only submit to the site itself rather than some other address a compromised script might redirect them to, and browser permissions for camera, microphone, location and payment access switched off entirely unless a specific page genuinely needs one.

Because this lives in configuration deployed alongside the code, it applies automatically to every page, including ones that do not exist yet. There is no dashboard to check, no setting that silently reverts after an update, and nothing that needs revisiting once it is set.

What it looks like in practice

Open any page on a site built this way in a browser’s developer tools and look at the response headers. You will find the full list sitting there on every single request: the site, a subpage, even a page that returns an error. Run the site through any of the free online security header scanners and it comes back clean, which is the kind of small, unglamorous detail that matters more than it looks.