Security Headers: What They Are and How to Set Them

Security headers tell the browser how to behave when loading your site: enforce HTTPS, block clickjacking, prevent MIME sniffing, and so on. They don’t replace HTTPS or good code, but they add an extra layer. Here's which headers matter and how to add them in Nginx, Apache, and Cloudflare.

Key takeaways

  • Strict-Transport-Security (HSTS): Browsers only load your site over HTTPS; reduces downgrade and strip attacks.
  • X-Frame-Options and Content-Security-Policy frame-ancestors help prevent clickjacking.
  • X-Content-Type-Options: nosniff stops the browser from guessing MIME types (e.g. treating a text file as script).
  • Referrer-Policy and Permissions-Policy control what information and features the browser sends or allows.
  • Set headers at the server (Nginx/Apache) or at the edge (Cloudflare). Test with our checker or browser dev tools.

Why use security headers?

They’re instructions in the HTTP response. The browser reads them and enforces rules: “only load this site over HTTPS,” “don’t put this page in an iframe,” “don’t guess the content type.” That reduces risks like protocol downgrade, clickjacking, and some XSS or data-leak scenarios. They’re quick to add and often recommended by security scanners and compliance guides.

Common security headers (short reference)

  • Strict-Transport-Security (HSTS): max-age=31536000; includeSubDomains; preload. Use HTTPS for the next year, including subdomains; preload lets you submit the site to browser HSTS preload lists.
  • X-Frame-Options: DENY or SAMEORIGIN. Controls who can embed your page in a frame (clickjacking).
  • X-Content-Type-Options: nosniff. Tells the browser not to infer MIME type from content.
  • Referrer-Policy: e.g. strict-origin-when-cross-origin. Controls how much referrer info is sent on links.
  • Permissions-Policy: restrict features (camera, geolocation, etc.) to the origins you allow.
  • Content-Security-Policy (CSP): fine-grained control over scripts, styles, images, frames; start with report-only or a relaxed policy and tighten gradually.

Security headers in Nginx

Add these inside your server block (or in an include file). For HTTPS-only blocks, HSTS is safe; if you still have HTTP, set HSTS only after confirming the HTTP→HTTPS redirect works.

Use always so headers are sent for error responses (4xx, 5xx) too. Reload Nginx after changes: sudo nginx -t && sudo systemctl reload nginx.

Security headers in Apache

Enable mod_headers, then set headers in the server config, a virtual host, or .htaccess.

Restart or reload Apache after editing the main config; .htaccess changes apply on next request (if AllowOverride allows it).

Security headers in Cloudflare

Cloudflare can add or override headers at the edge so your origin doesn’t have to.

  1. In the dashboard, select your domain → RulesTransform RulesModify Response Header (or use ConfigurationsHeaders depending on your plan).
  2. Create a rule that matches the requests you want (e.g. all pages).
  3. Add one or more Set static header actions: header name and value (e.g. X-Frame-Options = SAMEORIGIN).
  4. For HSTS, you can use SSL/TLSEdge CertificatesHTTP Strict Transport Security (HSTS) and enable it there; that sets Strict-Transport-Security at the edge.

How to verify security headers

After deploying, open your site, open DevTools → Network → select a document request → check Response Headers. Or run your domain through our free HTTPS checker; you’ll see redirects, SSL, and often security headers in the report. Our checker only counts X-Content-Type-Options when the value is nosniff, and does not count unsafe Referrer-Policy values (e.g. unsafe-url). We also show Set-Cookie flags (Secure, HttpOnly, SameSite) and headers that may disclose server or framework (e.g. Server, X-Powered-By)—informational only. For CSP, use report-only first and fix any breakage before enforcing.

Check your domain with HTTPS Checker

Stuck or want a second pair of eyes? We can help.

Contact us