Someone scanned 4,688 small-business websites and checked seven standard security headers. Just under half of them, 49.7 percent, failed all seven. The scan circulated on Hacker News this month, and the number is worth sitting with for a moment.
That is not a small-business problem. It is a small-business target, and the two things are related.
For most local organizations, the website was built once, by someone who has since moved on, and has not been touched since. Nobody was ever asked to think about response headers, because the request never came up.
TL;DR
Security headers are instructions your web server sends to a browser before the page loads. They are free, they do not slow anything down, and they close off a handful of common attacks. Checking yours takes about two minutes. Fixing them is usually an afternoon of work, not a project.
What a security header actually is
When a browser asks for your home page, your server sends the page back along with a set of invisible instructions. Those instructions are the headers. The browser follows them.
A header can tell the browser to only ever use the encrypted version of your site. It can tell the browser to refuse to run any script that didn't come from your own domain. It can tell the browser not to let your page be loaded silently inside another page.
None of that is visible to a visitor. All of it changes what an attacker can do with your site.
The standard seven
Different scanners weight these slightly differently, but the same seven come up again and again. Here is what each one stops.
HSTS forces every visitor onto the encrypted version of your site, so nobody can be quietly downgraded to plain text. A content security policy limits which scripts your pages are allowed to run, which is what stops injected code from executing in a visitor's browser. X-Content-Type-Options stops a browser from guessing that an uploaded file is executable. X-Frame-Options stops your page from being invisible-layered under a fake page to steal clicks. Referrer-Policy controls how much of your URL leaks out when someone clicks a link away from your site. Permissions-Policy shuts off browser features you never intended to expose, like camera and microphone access. Cross-origin policies stop other sites from reaching into yours.
The three that matter most for a local business
If you only get through part of the list, get through these.
A content security policy is the big one. Most site compromises end with code running on a page the attacker did not write, and this is the header that usually stops it. HSTS is the cheapest win on the list, one line, and it protects the connection itself. X-Frame-Options costs nothing and removes a whole class of clickjacking tricks that mostly target small sites precisely because they are unmaintained.
Why this lands harder on small organizations
A large company has a web team and a review process, and the headers probably got set years ago by someone whose job that was. A ten-person shop, a church, a nonprofit with a donated site: nobody's job that was.
Meanwhile the site still sells, still takes donations, still collects names and email addresses. A compromise means your customers get the phishing page instead of your order form, and browsers start showing warnings next to your name. The business cost lands on you, not on the person who built the site in 2019.
How to check your own site
You do not need an account or a tool. Most browsers will show you.
Open your site, then open the browser's developer tools and look at the Network tab and the response headers for the main page. You are looking for the seven names above. If none of them appear, you are in the same bucket as roughly half the small-business sites that were scanned.
There are also free public scanners that do the same thing from a web form and give you a letter grade. Either way, the answer takes a couple of minutes.
The fix is usually an afternoon
Headers are set in a handful of places: on the web server, in the hosting panel, or in a small config file. Adding them is careful, boring work. It is not a rebuild.
The one part that needs judgment is the content security policy, because a policy that is too strict will break a contact form or a booking widget. That is the piece worth testing on a staging copy before it goes live.
If you would rather not dig through it, this is the kind of thing we check as part of a free 30-minute IT review — including whether your site is sending the headers at all, and whether your email is set up to resist the same category of impersonation.