How to Check and Fix HTTP Security Headers

HTTP security headers are one of the most effective and least expensive defenses you can add to a website. They’re instructions included in the server’s response that tell the browser how to behave when loading and displaying your content. Without them, browsers apply their default behavior, which often leaves room for attackers to inject scripts, hijack clicks, or downgrade connections.

This guide covers the six most important security headers, explains what each one does, and shows you how to add them on popular platforms. Use our HTTP Header Checker to test your site and get an instant A-F security grade.

What Are HTTP Headers?

Every time a browser requests a web page, the server sends back two things: the page content and a set of headers. Headers are key-value pairs that provide metadata about the response. Some headers describe the content (Content-Type, Content-Length), others control caching (Cache-Control, ETag), and a critical subset enforces security policies.

Security headers don’t change what users see on the page. Instead, they restrict what the browser is allowed to do with the content. A properly configured set of security headers can prevent cross-site scripting, clickjacking, protocol downgrade attacks, and MIME type confusion without changing a single line of your application code.

Key Security Headers Explained

Content-Security-Policy (CSP)

CSP is the single most powerful security header. It defines a whitelist of trusted content sources for scripts, styles, images, fonts, and other resources. If a resource isn’t on the whitelist, the browser blocks it. This prevents most XSS attacks because injected scripts won’t match the allowed sources.

A basic CSP might look like this:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

This policy allows scripts only from your domain and a specific CDN. All other script sources are blocked. The default-src 'self' directive acts as a fallback for any resource type not explicitly listed.

Strict-Transport-Security (HSTS)

HSTS tells browsers to only access your site over HTTPS, even if the user types http:// in the address bar. Once a browser receives this header, it automatically upgrades all HTTP requests to HTTPS for the specified duration.

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

The max-age value is in seconds. Setting it to 31536000 (one year) is the recommended minimum. The includeSubDomains directive extends protection to all subdomains. The preload flag makes your site eligible for inclusion in browser preload lists, which enforce HTTPS even on the first visit.

X-Frame-Options

This header prevents your pages from being loaded inside an iframe on another site. Attackers use iframes to overlay invisible pages on top of legitimate-looking content, tricking users into clicking buttons they can’t see. This technique is called clickjacking.

Set this header to DENY (no framing allowed) or SAMEORIGIN (only your own site can frame your pages). The CSP frame-ancestors directive is the modern replacement, but X-Frame-Options provides backward compatibility with older browsers.

X-Content-Type-Options

Setting this header to nosniff prevents the browser from guessing the MIME type of a file. Without it, an attacker could upload a file disguised as an image that actually contains executable script code. The browser might “sniff” the content, detect the script, and execute it. With nosniff enabled, the browser strictly follows the declared Content-Type.

Referrer-Policy

This header controls how much URL information is shared when a user navigates from your site to another. The default browser behavior leaks the full URL, which may include session tokens, search queries, or private paths. Setting strict-origin-when-cross-origin sends only the origin (domain) for cross-origin requests while preserving the full URL for same-origin navigation.

Permissions-Policy

Formerly called Feature-Policy, this header controls which browser features your page can use. You can disable access to the camera, microphone, geolocation, payment APIs, and other capabilities that your site doesn’t need. This limits the damage an attacker can do if they find a way to inject code into your page.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

The empty parentheses mean the feature is disabled entirely. You can also restrict features to specific origins.

How to Add Security Headers on Common Platforms

Nginx: Add add_header directives inside your server or location block. Include the always parameter so headers are sent even on error responses.

Apache: Use Header set directives in your .htaccess file or virtual host configuration. Load mod_headers if it isn’t already enabled.

Cloudflare: Create a Transform Rule under Rules > Transform Rules > Modify Response Header. You can also use a Cloudflare Worker for more complex header logic.

Vercel: Add a headers array to your vercel.json configuration file. Each entry specifies a path pattern and the headers to apply.

Netlify: Create a _headers file in your publish directory with rules for each path.

Common Mistakes to Avoid

The most frequent mistake is adding security headers in development but not verifying them in production. Reverse proxies, CDNs, and load balancers can strip or override headers set at the application level. Always test headers on the production URL after deployment.

Another common error is using CSP with unsafe-inline and unsafe-eval for convenience. These directives defeat the purpose of CSP because they allow the exact attack vectors CSP is designed to block. If your application requires inline scripts, use nonce-based CSP instead, where each inline script tag receives a unique random token that must match the CSP directive.

Forgetting to add includeSubDomains to HSTS is also risky. Without it, subdomains remain vulnerable to protocol downgrade attacks. Make sure all subdomains support HTTPS before adding this directive.

Finally, exposing your Server and X-Powered-By headers gives attackers free reconnaissance about your technology stack. Remove or obscure these headers in production.

Frequently Asked Questions

How do I test my HTTP security headers?

Use the HTTP Header Checker to scan any public URL. The tool fetches response headers, grades your security from A+ to F, and provides specific recommendations for each missing or misconfigured header. Run a check after every server configuration change to verify headers are applied correctly.

Can security headers replace a Web Application Firewall?

No. Security headers and WAFs serve different purposes. Security headers instruct the browser to enforce policies at the client level, while a WAF inspects and filters incoming traffic at the server level. Headers prevent attacks like XSS and clickjacking in the browser. WAFs block SQL injection, bot traffic, and other server-side threats. A well-secured site uses both.

What happens if I set conflicting header values?

Browser behavior varies when conflicting headers exist. For CSP, the most restrictive policy wins when multiple CSP headers are present. For X-Frame-Options, browsers typically use the first value encountered. For HSTS, the latest received value overwrites the previous one. Avoid sending multiple conflicting values by auditing your headers at every layer (application, proxy, CDN) to ensure only one instance of each header reaches the client.

Is it safe to add all security headers at once?

X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy are safe to add immediately because they rarely affect normal site behavior. HSTS is safe if your site fully supports HTTPS. CSP requires the most caution. Deploy CSP in report-only mode first by using the Content-Security-Policy-Report-Only header, monitor for blocked resources, then switch to enforcement after whitelisting legitimate sources.