Six lines of server configuration shut down a whole family of well-known attacks against your visitors. Most websites are missing at least some of them — usually because nobody ever checked.
Security headers are one of the rare corners of web security where the economics are entirely in your favour: the cost is a few configuration lines, the downside is close to nil, and the protection is enforced by every modern browser automatically. This guide explains what each of the six standard headers protects against, with the concrete attack it stops, and how to check what your own site is sending.
What are security headers?
Security headers are instructions your web server sends along with every page, telling the visitor's browser which protections to switch on. They cost nothing, require no changes to the site's content, and defend against a family of well-known attacks — including clickjacking, content injection and connection downgrades. Because the browser enforces them, they protect your visitors even when something else has already gone wrong.
That last property is what makes them valuable. Headers are a safety net: they do not prevent the first mistake — a compromised script, a careless upload feature, a user on hostile Wi-Fi — but they stop the mistake from turning into harm.
The six headers and what each one stops
Content-Security-Policy (CSP)
CSP tells the browser exactly which sources it may load scripts, styles and other resources from. If an attacker manages to inject a script into your page — through a compromised third-party tag, or a form field that echoes input back — the browser refuses to run it, because it does not come from an approved source. This is the header that limits the damage of cross-site scripting and of payment-page skimmers that phone data home to an attacker's server.
Strict-Transport-Security (HSTS)
HSTS tells the browser to only ever connect to your site over HTTPS, even if the visitor types the address without it or clicks an old http:// link. Without it, an attacker on the same network — the classic case is public Wi-Fi in a café or airport — can intercept that first insecure request and keep the victim on an unencrypted connection, reading or altering everything. This downgrade trick is known as SSL stripping, and HSTS makes the browser refuse to play along.
X-Frame-Options
This header stops other websites from embedding your pages inside an invisible frame. That is the basis of clickjacking: an attacker layers your real "confirm payment" or "change email address" button underneath a fake "claim your prize" button on their own page, and the victim clicks your control without ever seeing it. Deny framing, and the whole technique collapses.
X-Content-Type-Options
Set to nosniff, this header stops the browser second-guessing what type of content a file is. Without it, a browser may "sniff" a file's contents and decide that something served as an image or plain text looks like a script — and execute it. On any site that accepts uploads, that turns a harmless-looking file into runnable code in your visitors' browsers. One word in a header closes the door.
Referrer-Policy
When a visitor follows a link from your site, their browser normally tells the destination which page they came from. Full URLs can carry more than you intend — search terms, account identifiers, password-reset tokens in the query string. Referrer-Policy limits what gets passed along, so third parties learn at most your domain, not the exact page or its parameters.
Permissions-Policy
This header switches off browser capabilities your site does not use — camera, microphone, geolocation and others. If your pages never need the microphone, declaring that means no script on the page, including an injected or compromised one, can request it. It is the principle of least privilege, applied to the browser.
Why are security headers considered a free win?
Because they are configuration, not development. Each header is typically a single line in your web server or CDN settings, there is nothing to license or install, and visitors notice no difference — except that a whole class of attacks quietly stops working. Few security improvements offer this much protection for this little effort.
Can adding security headers break my website?
Mostly no — five of the six are safe to add with sensible values. Content-Security-Policy is the exception: a strict policy can block your own scripts and stylesheets if written carelessly, so it is worth starting with the report-only variant, reviewing what it would have blocked, and only then enforcing it.
This is also why CSP is the header most often missing entirely: teams try a strict policy, something on the site breaks, and the header gets removed rather than tuned. A policy that starts permissive and tightens over time is far better than none.
How do I check which security headers my site sends?
Open your browser's developer tools, load the page, and inspect the response headers on the main document in the Network tab — the six headers either appear there or they do not. On the command line, curl -I followed by your address shows the same thing. For ongoing coverage a scanner is more practical, because headers can silently disappear after a server migration or configuration change.
That silent-disappearance problem is real: headers live in server configuration, and server configuration gets rebuilt — new hosting, a new CDN, a reverse-proxy change — with nobody responsible for carrying the headers across. A one-off check tells you about today; only a repeated check tells you about next quarter.
Where SiteControl fits
SiteControl checks all six headers — CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy — on every crawl of your site. A missing or misconfigured header appears as a finding with a plain-language explanation of what it protects against and step-by-step remediation, so the person who owns the web server knows exactly what to add. The same crawl also covers Core Web Vitals, technical SEO, accessibility and broken links, and an on-demand privacy scan can audit your cookie consent behaviour — one platform, one picture of your site's health.
The same is true one layer down, at the network: the ports that should never face the public internet are opened during migrations and left open for years.