What Are HTTP Security Headers?

Every time a browser loads your website, your server sends a set of HTTP headers alongside the page content. Most of these headers are invisible to visitors, but they tell the browser important things about how to handle the page. Security headers are a specific subset that instruct the browser to activate built-in protections against common attacks.

Think of them as a set of rules your server gives to every visitor's browser: "Only load scripts from these sources", "Never connect over HTTP", "Don't let other sites embed this page in a frame". Without these instructions, browsers fall back to their default behaviour, which is often less secure than it should be.

The six key security headers

1. Strict-Transport-Security (HSTS)

This header tells browsers to only ever connect to your site over HTTPS, never HTTP. Without it, the first time someone types yourdomain.com into their browser, the connection starts as plain HTTP before redirecting to HTTPS. An attacker positioned on the same network can intercept that initial HTTP request.

Example:

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

The max-age value is how long (in seconds) the browser should remember this instruction. We recommend at least one year (31,536,000 seconds). The includeSubDomains flag applies the rule to all subdomains. The preload flag signals that you want to be included in browser-level HSTS preload lists.

Common mistake: Setting max-age to a very short value like 300 seconds. This means the browser forgets the rule after five minutes, defeating the purpose.

Read our detailed guide: What is the HSTS header and why does it matter?

2. Content-Security-Policy (CSP)

CSP is the most powerful security header. It controls which resources the browser is allowed to load: scripts, stylesheets, images, fonts, frames, and more. Without CSP, a browser will happily execute any script tag it finds on your page, including malicious ones injected by an attacker.

Example:

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

This tells the browser: "By default, only load resources from the same origin. Scripts can also come from trusted-cdn.com. Stylesheets can include inline styles."

Common mistake: Using default-src *'unsafe-inline' 'unsafe-eval' which effectively disables CSP's protections entirely. It is better to start restrictive and whitelist only what you need.

3. X-Frame-Options

This header prevents your website from being embedded in an iframe on another domain. Without it, an attacker can load your site in a hidden frame, overlay it with invisible elements, and trick a visitor into clicking things on your page without realising. This is called clickjacking.

Example:

X-Frame-Options: DENY

or

X-Frame-Options: SAMEORIGIN

DENY blocks all framing. SAMEORIGIN allows framing only from your own domain. Use DENY unless you specifically need to embed your pages in your own iframes.

Common mistake: Using ALLOW-FROM which is no longer supported by modern browsers. Use CSP's frame-ancestors directive instead if you need fine-grained control.

4. X-Content-Type-Options

Browsers sometimes try to guess the type of a file when the server does not specify one, or when the declared type seems wrong. This is called MIME sniffing. An attacker can exploit this by uploading a file that looks like an image but is actually a script, and the browser might execute it.

Example:

X-Content-Type-Options: nosniff

This single header tells the browser: "Trust the Content-Type I gave you. Do not try to guess." It has only one valid value, and every site should set it.

Common mistake: Simply forgetting to add it. This header has no downside and should be on every website.

5. Referrer-Policy

When a visitor clicks a link on your site to go to another site, the browser normally sends the full URL of your page in the Referer header. This can leak sensitive information, especially if your URLs contain session tokens, user IDs, or search queries.

Example:

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

This sends the full URL as a referrer when navigating within the same site, but only sends the origin (just the domain) when navigating to a different site. Nothing is sent over HTTP connections.

Common mistake: Using no-referrer which breaks analytics on your own site. strict-origin-when-cross-origin is the best balance for most websites.

6. Permissions-Policy

Previously called Feature-Policy, this header controls which browser features and APIs your site is allowed to use: camera, microphone, geolocation, fullscreen, payment requests, and more. Without it, any script on your page (including third-party scripts) can request access to these features.

Example:

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

This disables camera and microphone access entirely, and only allows geolocation from your own origin.

Common mistake: Not setting it at all, which means any third-party script embedded on your page (analytics, chat widgets, ads) could potentially request access to the camera or microphone.

What about X-XSS-Protection?

X-XSS-Protection is a legacy header that asked older browsers (primarily Internet Explorer) to block detected cross-site scripting attacks. Modern browsers have largely deprecated it in favour of CSP. The recommended value now is:

X-XSS-Protection: 0

Setting it to 0 actually prevents the browser's flawed XSS filter from creating vulnerabilities of its own. If you have a strong CSP in place, you do not need this header. If you do not have CSP, set it to 1; mode=block as a fallback.

How to test your security headers

The quickest way is to open your browser's developer tools (press F12), go to the Network tab, reload your page, and click on the first request. Look at the Response Headers section.

For a more thorough check, use an online scanner. PulseShield's free security scan checks all six security headers plus SSL configuration, open ports, cookie settings, and email authentication in a single report.

How to add security headers

nginx

Add these lines to your server block:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(self)" always;

Remember to reload nginx after changes: sudo nginx -t && sudo systemctl reload nginx

Apache

Add these to your .htaccess file or virtual host configuration:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "DENY"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(self)"

Make sure the mod_headers module is enabled.

WordPress

You can add headers via your theme's functions.php file or by using a security plugin such as Really Simple SSL or HTTP Headers. Many managed WordPress hosts also provide header configuration in their dashboard.

What happens without security headers?

Without these headers, your website relies entirely on its own code for security. If an attacker finds a way to inject a script into your page, there is no second line of defence. Browsers have built-in protections, but they need to be told to activate them. Security headers are that instruction.

According to OWASP's Secure Headers Project, implementing proper security headers is one of the most cost-effective ways to improve your website's security posture. It takes minutes to configure but blocks entire categories of attack.

For a complete walkthrough of securing your website, read our how to secure a website guide. You can also use our website security checklist to make sure you have covered everything.