Website Security Headers Explained

HTTP security headers are instructions your server sends to the browser alongside every page, telling it how to behave defensively. They don’t change what your site looks like, but they close off entire categories of common attacks — often with just a single line of configuration.

Why headers matter

Without explicit instructions, browsers default to permissive behavior for compatibility reasons. Security headers override those defaults, telling the browser things like “don’t allow this page to be embedded in another site” or “only ever load this over a secure connection.” Each header addresses a specific class of risk.

The headers worth knowing

Content-Security-Policy

Controls which sources of scripts, styles, and other resources the browser is allowed to load. A well-configured policy makes it much harder for injected scripts to run, even if an attacker finds a way to insert content into your page.

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

X-Frame-Options / frame-ancestors

Prevents your site from being loaded inside an iframe on another domain, which blocks “clickjacking” attacks where a malicious site overlays your page to trick users into clicking something they didn’t intend to.

X-Frame-Options: SAMEORIGIN

Strict-Transport-Security (HSTS)

Tells the browser to only ever connect to your site over HTTPS, even if a user types http:// or clicks an old link. This prevents a class of attacks where a connection is silently downgraded to an insecure one.

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

X-Content-Type-Options

Stops the browser from trying to guess a file’s type based on its content, which can prevent certain files from being misinterpreted as something executable.

X-Content-Type-Options: nosniff

Referrer-Policy

Controls how much information about the page a user came from gets sent to the next site they visit, reducing accidental leakage of internal URLs or sensitive query parameters.

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

How to check what you currently have

Most browsers’ developer tools let you inspect response headers directly from the Network tab. There are also independent header-checking tools you can run your domain through to get a quick readout of what’s present and what’s missing.

A reasonable starting point

You don’t need every possible header to see meaningful benefit. A practical baseline for most sites is HSTS, X-Content-Type-Options, a frame-ancestors or X-Frame-Options rule, and a Content-Security-Policy that starts permissive and gets tightened over time as you confirm nothing breaks.

The takeaway

Security headers are inexpensive to add and meaningfully reduce your exposure to some of the most common web attacks. They’re not a complete security strategy on their own, but they’re one of the highest-value, lowest-effort steps you can take. For a broader view of where headers fit into overall security hygiene, see How to Check Your Website Security Posture.