← Back to Blog
Security Web May 18, 2026 · 6 min read

Why HTTP Security Headers Matter — and How to Check Them

Most developers focus on application logic and overlook a simple but powerful layer of defense: HTTP response headers. A few lines of server config can protect your users from XSS, clickjacking, and downgrade attacks — for free.

What Are HTTP Security Headers?

Every time a browser requests a page, the server sends back a response with two parts: the headers (metadata) and the body (HTML content). Most developers only think about the body — but headers are where you tell the browser how to behave when rendering your page.

Security headers are a subset of these response headers. They instruct the browser to enforce specific security policies: block HTTP, prevent framing, restrict scripts, and more. They don't require any changes to your application logic — just your server configuration.

Key insight: Security headers are a defense-in-depth measure. They don't replace secure coding, but they limit the damage when something goes wrong.

The Six Headers You Should Know

Strict-Transport-Security High
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Also called HSTS. Once a browser sees this header, it will only connect to your site via HTTPS for the duration specified by max-age (in seconds). This prevents protocol downgrade attacks where an attacker intercepts an HTTP request before the redirect to HTTPS can happen.
Content-Security-Policy High
Content-Security-Policy: default-src 'self'; script-src 'self'
CSP tells the browser which sources are allowed to load scripts, styles, images, and other resources. It's the most powerful defense against Cross-Site Scripting (XSS) attacks — even if an attacker injects a script tag, the browser won't execute it if the source isn't whitelisted.
X-Frame-Options Medium
X-Frame-Options: DENY
Prevents your page from being embedded inside an <iframe> on another site. This blocks clickjacking attacks, where an attacker overlays an invisible frame of your site over their own page to trick users into clicking things they didn't intend to.
X-Content-Type-Options Medium
X-Content-Type-Options: nosniff
Tells the browser not to guess the content type of a response — it must use whatever the server declares. Without this, browsers can MIME-sniff a response and execute a file as JavaScript even if the server said it was a plain text file.
Referrer-Policy Low
Referrer-Policy: strict-origin-when-cross-origin
Controls how much information the browser includes in the Referer header when navigating between pages. Without this, clicking a link on your site could expose full URLs (including query parameters with sensitive data) to third-party sites.
Permissions-Policy Low
Permissions-Policy: camera=(), microphone=(), geolocation=()
Restricts which browser features your page can use. If your site doesn't need access to the camera, microphone, or geolocation — explicitly disable them. This limits the blast radius if an attacker manages to execute JavaScript on your page.

How to Check Your Site

You can use the HTTP Security Header Checker built into this site. Enter any URL and you'll get an instant breakdown of which headers are present, what values they have, and a security score out of 100.

Try checking a site you own, or a well-known site like github.com to see what a well-configured set of headers looks like in practice.

How to Add Them

The implementation depends on your stack. In Django, the SecurityMiddleware handles several of these automatically when you set the right settings in settings.py:

SECURE_HSTS_SECONDS = 31536000 SECURE_HSTS_INCLUDE_SUBDOMAINS = True SECURE_CONTENT_TYPE_NOSNIFF = True X_FRAME_OPTIONS = 'DENY'

For Nginx, you add them directly to your server block. For Apache, use the Header always set directive. Most modern hosting platforms also let you configure headers through their dashboard.

Final Thoughts

Security headers are one of the highest-leverage improvements you can make to a web application. They take minutes to configure and protect every user who visits your site — no authentication, no database, no application code required.

The next time you deploy a site, run it through a header checker before you ship. It's a quick win that most developers skip.

Written by Emrah Ustundag · Try the Header Checker →