← All Posts
April 12, 2026 Web Security 7 min read

Security Headers Explained: What They Are and Why You Need Them

Six HTTP headers that protect your website from common attacks. Most sites are missing at least three.

The Invisible Shield You Are Probably Missing

Every time someone visits your website, your server sends back more than just HTML. It sends HTTP response headers -- invisible instructions that tell the browser how to handle your content. Some of these headers are mundane (content type, cache settings). Others are critical security controls that prevent entire categories of attacks.

The problem is that most web hosting platforms and CMS installations do not configure security headers by default. A scan of over 1 million websites by SecurityHeaders.com found that fewer than 10% had all six recommended security headers in place. Most had three or fewer.

If your site is built on WordPress, Squarespace, Wix, or a basic shared hosting plan, there is a strong chance you are missing critical protections right now. Here is what each header does, why it matters, and how to check yours.

1. Content-Security-Policy (CSP)

What it does: Tells the browser exactly which sources are allowed to load scripts, styles, images, and other resources on your page.

Why it matters: Cross-site scripting (XSS) is the most common web vulnerability. An attacker injects malicious JavaScript into your page -- through a compromised form field, a third-party widget, or even a rogue ad network. Without CSP, the browser has no way to know the difference between your legitimate scripts and the attacker's code. It runs everything.

With a properly configured CSP, the browser blocks any script that does not come from an explicitly approved source. Even if an attacker manages to inject code into your HTML, the browser refuses to execute it.

Example:

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

This tells the browser: only load scripts from my own domain and from cdn.example.com. Everything else gets blocked.

2. Strict-Transport-Security (HSTS)

What it does: Forces all connections to use HTTPS. Once a browser sees this header, it will never attempt an HTTP connection to your domain again (for the duration you specify).

Why it matters: Even if you have an SSL certificate, users can still be tricked into connecting over plain HTTP. An attacker on the same network (think coffee shop WiFi) can intercept the initial HTTP request and redirect the user to a fake version of your site. This is called an SSL stripping attack.

HSTS eliminates this entirely. After the first visit, the browser knows to always use HTTPS -- even if the user types http:// in the address bar.

Example:

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

The max-age value is in seconds. 31536000 equals one year. The includeSubDomains directive extends the protection to all subdomains. The preload directive qualifies your domain for the browser's built-in HSTS preload list, which means protection starts on the very first visit.

3. X-Frame-Options

What it does: Controls whether your website can be embedded inside an iframe on another site.

Why it matters: Clickjacking attacks work by loading your website in a hidden iframe, then overlaying a fake interface on top of it. The user thinks they are clicking a harmless button, but they are actually clicking a button on your site -- authorizing a payment, changing account settings, or submitting a form.

Setting X-Frame-Options to DENY or SAMEORIGIN prevents your site from being loaded in frames on other domains. Simple, effective, and often the difference between a secure site and a compromised one.

Example:

X-Frame-Options: SAMEORIGIN

4. X-Content-Type-Options

What it does: Prevents the browser from guessing (or "sniffing") the content type of a response.

Why it matters: Browsers try to be helpful. If they receive a file without a clear content type, they will guess based on the file's contents. An attacker can exploit this by uploading a file that looks like an image but contains executable JavaScript. Without this header, the browser might execute the script instead of displaying it as data.

This is a one-line fix that blocks an entire class of MIME-based attacks.

Example:

X-Content-Type-Options: nosniff

5. Referrer-Policy

What it does: Controls how much information about the user's origin is sent when they click a link on your site to navigate to another site.

Why it matters: By default, when a user clicks a link on your site, the destination receives the full URL they came from -- including query parameters. If your URLs contain session tokens, customer IDs, or search queries, this data leaks to every external site you link to.

A well-configured Referrer-Policy limits or removes this information. For most business websites, strict-origin-when-cross-origin is the right choice. It sends just the domain name (not the full URL) when navigating to external sites, and sends the full URL only for same-site navigation.

Example:

Referrer-Policy: strict-origin-when-cross-origin

6. Permissions-Policy

What it does: Controls which browser features (camera, microphone, geolocation, payment APIs) your website is allowed to access.

Why it matters: If your site gets compromised, or if a third-party script you load turns malicious, the attacker could use browser APIs to access the user's camera, microphone, or location data. Permissions-Policy lets you explicitly disable features you do not use, reducing the attack surface.

A contractor website has no reason to access a visitor's microphone. A dental practice website has no need for geolocation. By disabling these features at the header level, you create a hard boundary that no script can override.

Example:

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

The empty parentheses mean "deny to all origins." No script, no iframe, no embedded widget can use these features.

How to Check Your Headers Right Now

You have three options for checking your current security headers:

Free Headers, Expensive Consequences

Here is the part that should frustrate you: every single one of these headers is free to implement. They require no software purchase, no subscription, and no specialized hardware. They are configuration lines added to your web server or hosting platform. The total implementation time for someone who knows what they are doing is about 30 minutes.

Yet the consequences of not having them are severe. A single XSS attack exploiting a missing Content-Security-Policy can result in stolen customer data, defaced pages, and a Google Safe Browsing warning that tanks your organic traffic for weeks.

Forge Shield scans all six security headers automatically as part of its continuous monitoring. If a header is missing, misconfigured, or weakened after a server update, you get an alert with the exact fix. No guesswork, no security certifications required.

Your website is a business asset. Protect it like one. Get started with Forge Shield and close the gaps before someone else finds them.

← Back to all posts