7 HTTP Security Headers Every Website Should Have

HTTP security headers are instructions a server sends back with every response, telling the browser how to behave more safely with the page it just received. They cost nothing to add, don’t require rewriting application code, and meaningfully reduce a site’s exposure to entire classes of attack. Here’s what the most common ones actually do.

The headers, explained

Strict-Transport-Security (HSTS). Tells the browser to only ever connect to the site over HTTPS from now on, even if a link or bookmark points to http://. This closes off a specific downgrade attack where a request is intercepted before it gets redirected to HTTPS.

Content-Security-Policy (CSP). Restricts which sources scripts, styles, images, and other resources are allowed to load from. This is one of the most effective defenses against cross-site scripting (XSS) - even if an attacker manages to inject a script tag, a strict CSP can stop it from executing or from loading an external payload.

X-Content-Type-Options. A single value (nosniff) that stops browsers from guessing a file’s type based on its content rather than trusting what the server declared. Without it, a browser might execute a file as a script even though the server said it was something harmless.

X-Frame-Options. Controls whether the page can be loaded inside an <iframe> on another site, which prevents clickjacking - where a malicious site overlays invisible frames to trick users into clicking something on your site without realizing it. A strict CSP with a frame-ancestors directive can achieve the same thing.

Referrer-Policy. Controls how much information about the page a user is leaving gets sent to the next site they navigate to. Without it, full URLs (which can contain sensitive query parameters) may leak to third-party sites via the referrer header.

Permissions-Policy. Restricts which browser features - camera, microphone, geolocation, and others - the page and any embedded content are allowed to request at all, regardless of what the user might click “allow” on.

Cross-Origin-Opener-Policy. Isolates the page from other windows and tabs opened from it, closing off certain cross-origin side-channel attacks that rely on shared browsing context.

Checking your own site

Rather than inspecting response headers manually, our HTTP Security Headers Checker checks for all seven of these against any URL, shows which are present with their actual values, and dumps the complete raw response headers for anything else you want to inspect. It’s a simple presence count, not an official certification - a missing header doesn’t automatically mean a site is insecure, since some headers overlap in what they protect against (a strict CSP can make X-Frame-Options redundant, for instance).

A reasonable starting point

If you’re adding these to a site for the first time, HSTS and X-Content-Type-Options are close to zero-risk to add immediately. Content-Security-Policy takes more care - an overly strict policy can break legitimate functionality (embedded widgets, analytics scripts, inline styles), so it’s worth testing thoroughly rather than deploying a strict policy blind. The other headers are generally safe to add without much testing.