Every time your browser loads a website, the server sends back more than just the page itself. Alongside the HTML, images, and scripts, the server includes a set of HTTP headers -- invisible instructions that tell the browser how to handle the content. Some of those headers are purely functional, but others play a critical role in security.
HTTP security headers act as a first line of defense between a website and common web attacks. They instruct browsers to enforce specific protections -- blocking malicious scripts, preventing data leaks, and ensuring connections stay encrypted. When these headers are missing or misconfigured, visitors are exposed to risks that are otherwise straightforward to prevent.
Whether you run a website or simply want to understand what makes one site safer than another, knowing the key security headers is a practical skill. Let's walk through the most important ones.
Content-Security-Policy (CSP)
Content-Security-Policy is one of the most powerful security headers available. It tells the browser exactly which sources of content are allowed to load on a page -- scripts, stylesheets, images, fonts, and more.
Why does this matter? Without CSP, an attacker who finds a way to inject code into a page (a technique called cross-site scripting, or XSS) can run arbitrary JavaScript in your visitors' browsers. That script could steal session cookies, redirect users to phishing pages, or log keystrokes.
A well-configured CSP significantly reduces the impact of XSS by restricting where scripts can come from. For example, a policy might allow scripts only from the site's own domain and a trusted CDN, blocking everything else.
Key takeaway: CSP limits what content a browser is allowed to load, making it much harder for injected malicious code to execute.
Strict-Transport-Security (HSTS)
HSTS tells the browser to always use HTTPS when connecting to a site, even if a user types http:// in the address bar or clicks an old HTTP link.
Without HSTS, there is a brief window during the first connection where an attacker on the same network could intercept traffic before the redirect to HTTPS happens. This is known as a downgrade attack or SSL stripping. HSTS eliminates that window by instructing the browser to never even attempt an insecure connection.
The header typically includes a max-age value (how long the browser should remember the rule) and optionally includeSubDomains to cover every subdomain. Sites can also be added to the HSTS preload list, which is built directly into browsers.
Key takeaway: HSTS ensures that every connection to your site is encrypted, closing the door on downgrade attacks.
X-Frame-Options
X-Frame-Options controls whether a page can be embedded inside an <iframe> on another site. This header is the primary defense against clickjacking -- an attack where a malicious site overlays an invisible frame of a legitimate site, tricking users into clicking buttons or links they cannot see.
Common values include:
- DENY -- the page cannot be framed at all
- SAMEORIGIN -- the page can only be framed by pages on the same domain
Modern browsers also support the frame-ancestors directive in CSP, which offers more granular control, but X-Frame-Options remains widely used for backward compatibility.
Key takeaway: X-Frame-Options prevents your site from being secretly embedded in a malicious page.
X-Content-Type-Options
This header has only one valid value: nosniff. It tells the browser not to guess (or "sniff") the MIME type of a response and instead trust the declared Content-Type.
Without it, a browser might interpret a file differently than the server intended. For instance, a plain text file could be treated as executable JavaScript if an attacker crafts the content carefully. Setting X-Content-Type-Options: nosniff stops that behavior.
Key takeaway: This header prevents browsers from misinterpreting file types, which blocks a class of attacks that rely on MIME-type confusion.
Referrer-Policy
When you click a link from one page to another, the browser typically sends a Referer header (yes, the misspelling is part of the spec) that reveals the URL you came from. Referrer-Policy lets site owners control how much of that information is shared.
Options range from sending no referrer at all (no-referrer) to sending only the origin without the full path (strict-origin-when-cross-origin). This matters because URLs can contain sensitive information -- search queries, account identifiers, or internal paths that should not leak to third parties.
Key takeaway: Referrer-Policy limits what URL information is shared with other sites when users navigate away.
Permissions-Policy
Formerly known as Feature-Policy, this header restricts which browser features a site can use. It can disable access to the camera, microphone, geolocation, payment APIs, and more.
This is particularly useful for preventing embedded third-party content (like ads or widgets) from accessing sensitive device features without the user's knowledge. A site can declare, for example, that only its own origin is allowed to use the microphone, regardless of what embedded frames request.
Key takeaway: Permissions-Policy gives site owners fine-grained control over which browser APIs are available, limiting what third-party code can do.
How to Check a Site's Security Headers
Curious about whether a particular site has these headers in place? You can inspect them directly:
- Use the HTTP header checker to see exactly which headers a site returns and identify any that are missing
- Run a full domain report for a comprehensive look at a domain's security posture, including headers, SSL certificate status, DNS records, and more
Both tools highlight missing or misconfigured headers so you know where a site stands.
What Happens When Headers Are Missing
Missing security headers do not cause a site to break -- everything will still load and function normally. That is precisely why they are so often overlooked. But the absence of these headers leaves real gaps:
- No CSP means any successful XSS injection runs without restriction
- No HSTS means the first visit to a site may happen over an unencrypted connection
- No X-Frame-Options means the site can be embedded in a clickjacking attack
- No X-Content-Type-Options means browsers may misinterpret uploaded files
- No Referrer-Policy means full URLs (potentially containing sensitive data) leak to external sites
- No Permissions-Policy means embedded third-party scripts could access device features
None of these headers are difficult to implement. Most can be added with a single line in a server configuration or a few lines in a framework's middleware. The security benefit relative to the effort is significant.
Wrapping Up
HTTP security headers are one of the simplest and most effective ways to harden a website. They cost nothing, require minimal configuration, and protect against some of the most common attacks on the web. If you maintain a site, auditing your headers should be near the top of your security checklist. If you are evaluating someone else's site, checking their headers is a quick way to gauge how seriously they take security.
Start by running a scan with our HTTP header checker to see where things stand.