HTTP Security Headers Explained: CSP, HSTS, and the Rest

Every time a browser loads your page, your server sends back a set of invisible instructions alongside the HTML: HTTP response headers. A handful of these, the security headers, tell the browser how to protect your visitors: which scripts it's allowed to run, whether the connection must be encrypted, whether other sites can embed your page. They cost nothing to add, they defend against real attacks, and they signal to users and increasingly to search engines that your site is professionally maintained. Yet a huge share of sites ship with none of them.

Why security headers matter for SEO, not just security

It's fair to ask what security headers have to do with rankings. The connection is real, if indirect:

• HTTPS is a confirmed ranking signal, and headers like HSTS enforce it properly rather than leaving it half-implemented.
• User trust and safety are exactly what search engines optimise for. A site that gets hijacked, defaced, or used to inject malicious scripts loses rankings fast, sometimes with a "this site may be hacked" warning that annihilates click-through. Security headers reduce that risk.
• They signal quality. A correctly configured site is the kind of site search engines want to rank. Security posture is part of the overall technical-health picture.

So this isn't a detour from SEO, it's part of the technical foundation that keeps your rankings from evaporating overnight.

The headers worth knowing

Content-Security-Policy (CSP)

CSP is the most powerful and the most involved. It tells the browser exactly which sources of content (scripts, styles, images, fonts, frames) are allowed to load and execute. Done right, it's the single strongest defence against cross-site scripting (XSS), where an attacker sneaks malicious JavaScript onto your page.

A simple policy might say "only run scripts from my own domain":

Content-Security-Policy: default-src 'self'; script-src 'self'

CSP is powerful precisely because it's strict, which also makes it the easiest to get wrong, too tight and you block your own legitimate scripts and break the page. Because of that, it's best assembled deliberately rather than copied blind. Our CSP generator walks you through choosing allowed sources and builds a valid policy string, so you get the protection without accidentally blocking your own assets.

Strict-Transport-Security (HSTS)

HSTS forces browsers to use HTTPS for your site, always, even if a user types http:// or clicks an old insecure link. Once a browser has seen this header, it refuses to connect over plain HTTP for the duration you specify, closing the window where a connection could be downgraded and intercepted.

Strict-Transport-Security: max-age=31536000; includeSubDomains

The max-age is in seconds (a year, here). Add HSTS only once you're confident HTTPS works everywhere on your site, since it makes the enforcement sticky.

X-Frame-Options

This controls whether other sites can embed your pages in an <iframe>. Blocking that prevents clickjacking, where an attacker overlays your real page invisibly on top of a decoy to trick users into clicking things they didn't mean to.

X-Frame-Options: DENY

Use DENY to forbid all framing, or SAMEORIGIN to allow only your own site to frame your pages. (CSP's frame-ancestors directive is the modern successor, but X-Frame-Options is still widely honoured.)

X-Content-Type-Options

A short, safe, set-and-forget header. It stops browsers from "sniffing" and second-guessing the declared content type of a file, which can be abused to make the browser execute something as script that shouldn't be.

X-Content-Type-Options: nosniff

There's essentially no downside to adding this one.

Referrer-Policy

Controls how much of the referring URL is shared when a user clicks a link off your site. A sensible default protects user privacy without breaking analytics:

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy

Lets you switch off browser features your site doesn't use (camera, microphone, geolocation) so that even if a page were compromised, those capabilities can't be silently invoked.

A quick reference

Header	Defends against	Effort
Content-Security-Policy	Cross-site scripting (XSS)	Higher: needs care
Strict-Transport-Security	Protocol downgrade / interception	Low, once HTTPS is solid
X-Frame-Options	Clickjacking	Low
X-Content-Type-Options	MIME-type confusion	Trivial
Referrer-Policy	Referrer leakage	Low
Permissions-Policy	Abuse of device features	Low

How to check what you've got

You almost certainly can't recite your site's current headers from memory, and the defaults from your host or framework may be incomplete. Before you change anything, see the real state. Run your URL through our security header checker. It fetches your site's actual response headers and reports which security headers are present, which are missing, and where a configuration looks weak. That gives you a punch list instead of guesswork.

The practical workflow:

1. Audit your live site with the security header checker to see what's already there.
2. Add the easy wins first, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and HSTS (once HTTPS is fully working).
3. Tackle CSP carefully. Build a policy with the CSP generator, and if your host supports it, roll it out in report-only mode first so you catch anything it would block before it actually blocks it.
4. Re-run the checker to confirm everything landed as intended.

Where you set the headers depends on your stack (your web server config, a CDN or edge layer, or your application framework) but the header values themselves are the same everywhere.

Start by auditing what you already send

HTTP security headers are a low-effort, high-value layer of protection that guards your visitors against XSS, clickjacking, and interception, and, by keeping your site healthy and trusted, protects the rankings you've worked for. Start by auditing what you have with the security header checker, add the trivial headers immediately, enforce HTTPS with HSTS, and build a careful policy with the CSP generator. A few lines of configuration, and your site is meaningfully harder to attack and easier to trust.

Why our checker asks you to paste

A design note that doubles as a security lesson: the security header checker asks you to paste headers (from curl -I or DevTools) rather than fetching your URL. That is not laziness. Browsers deliberately block one origin from reading another's response headers, so an honest client-side tool cannot fetch them, and doing it server-side would mean sending us your URL and receiving your headers, which can expose server versions and internal hostnames. Pasting keeps the audit fully local, and as a bonus it works on staging, intranet and login-gated pages no public scanner can reach.

Sources

• Content-Security-Policy (MDN Web Docs)
• Strict-Transport-Security (MDN Web Docs)
• OWASP Secure Headers Project