How to Check Your Website's Security Headers (And Why It Matters)

Security headers are a small configuration change with an outsized impact on your website's defenses. Missing headers leave you exposed to clickjacking, cross-site scripting, and information leakage, vulnerabilities that cost nothing to fix. This guide explains the six headers that matter most, shows you exactly what values to use, and walks through how to add them in Nginx, Apache, Next.js, and Express. Check your site's headers right now with our free tool.

What Are Security Headers?

Security headers are HTTP response headers that instruct the browser how to behave when loading your site. Every time a browser requests a page, the server sends back a response containing a status code, the HTML content, and a set of these HTTP response headers, key-value pairs that control browser behaviour.

Most developers are familiar with headers like Content-Type or Cache-Control. Security headers work the same way, except their job is to tell the browser what it should not do: don't load this page inside an iframe, don't execute inline scripts, don't send cookies over plain HTTP.

Here's a concrete example: without X-Frame-Options, an attacker can embed your login page inside an invisible iframe on their own site and trick users into entering credentials without realizing where they actually are. That is called clickjacking, and it is trivially easy to execute against any site that does not set this header.

Security headers are your browser-side safety net. They are not hard to add, most can be configured in a single line, but they require knowing which ones matter and what values to use.

The Six Headers Every Website Needs

1. Strict-Transport-Security (HSTS)

What it does: Tells browsers to only connect to your site over HTTPS, even if the user types http:// into the address bar or clicks an old HTTP link.

Why it matters: Without HSTS, users who navigate to the HTTP version of your site are vulnerable to SSL stripping attacks. An attacker positioned between the user and your server (on a coffee shop Wi-Fi network, for example) can silently downgrade the connection from HTTPS to HTTP and intercept everything.

Recommended value:

• max-age=31536000, remember this policy for one year (in seconds)
• includeSubDomains, apply it to every subdomain too
• preload, opt in to the browser preload list, meaning browsers will refuse HTTP connections before even making the first request

Prerequisite: Your site must be fully served over HTTPS before you enable this. Setting HSTS on a site that still has HTTP pages will break things.

2. Content-Security-Policy (CSP)

What it does: Defines exactly which sources of content, scripts, stylesheets, images, fonts, iframes, are allowed to load on your page.

Why it matters: CSP is your primary defence against cross-site scripting (XSS). When an attacker manages to inject malicious script into your page (through a comment field, user-generated content, or a compromised dependency), a strict CSP prevents that script from running or exfiltrating data.

Example value for a typical web application:

CSP is the most powerful header on this list, but also the most complex to configure correctly. A policy that is too permissive provides little protection; one that is too strict breaks your site. The recommended approach is to start with a Content-Security-Policy-Report-Only header so you can observe violations without enforcing the policy, then tighten it incrementally.

frame-ancestors 'none' within CSP also replaces and supersedes the older X-Frame-Options header in modern browsers.

3. X-Content-Type-Options

What it does: Prevents browsers from guessing (sniffing) the content type of a response when the Content-Type header is absent or ambiguous.

Why it matters: Without this header, a browser might interpret a text file containing HTML as an HTML document and render it, executing any scripts inside. This is known as MIME sniffing. It is a particularly common issue with user-uploaded content.

Recommended value:

There is only one valid value. Set it on every page.

4. X-Frame-Options

What it does: Controls whether your page can be embedded in an <iframe>, <frame>, or <object> element.

Why it matters: Clickjacking attacks rely on loading your legitimate page inside a hidden iframe on a malicious site. The attacker overlays invisible interactive elements on top of your page to trick users into clicking things they did not intend to, like approving a bank transfer or changing account settings.

Recommended value:

Use DENY if you never need your page embedded anywhere. Use SAMEORIGIN if you embed pages within your own domain.

Note that if you are already using CSP with frame-ancestors, you do not strictly need this header in modern browsers. It is still worth including for older browser compatibility.

5. Referrer-Policy

What it does: Controls how much referrer information (the URL of the page the user came from) is included in outgoing requests.

Why it matters: Without a Referrer-Policy, when a user clicks a link on your site, the full URL of the page they were on is sent to the destination site in the Referer header. If your URLs contain session tokens, password-reset tokens, or sensitive query parameters, you are leaking them to third parties every time a user clicks an external link.

Recommended value:

This sends the full URL as the referrer for same-origin requests (useful for your own analytics) and only sends the origin, https://yoursite.com, for cross-origin requests, stripping the path and query string.

6. Permissions-Policy

What it does: Controls which browser features and APIs, camera, microphone, geolocation, payment, and others, can be used by your page and by any third-party content you embed.

Why it matters: If a third-party script you include (an analytics snippet, a chat widget, an ad) becomes compromised, a liberal Permissions-Policy means that script could silently activate the user's camera or microphone. This header limits the blast radius of a supply chain attack.

Recommended value for most sites:

This disables each listed feature entirely. Only grant the permissions your application actually uses.

How to Check Your Website's Security Headers

The fastest way to see which headers your site is sending (or failing to send) is to use our free tool.

Check your headers now →

Enter your URL and you will get an instant breakdown of each header's presence, the value it is set to, and whether that value follows best practice. No account required.

If you prefer to check manually from the command line, curl is your friend:

The -I flag requests only the response headers. Look for the security-relevant headers in the output. Any that are absent are candidates for your next deployment.

You can also check headers in browser developer tools. Open DevTools, navigate to the Network tab, reload the page, click on the initial document request, and look at the Response Headers section.

How to Add Security Headers

Pick your server or framework below. Each snippet adds all six recommended headers in one go.

How to Test Your Security Headers After Deployment

Once you have added your headers, verify everything is working:

What's Next After Fixing Your Headers?

Security headers are a great first step, but they address only one thin layer of your attack surface. They prevent certain browser-level attacks, but they do nothing about the rest.

A complete security picture requires testing at the application layer, not just the header layer. CyberOrbit's automated assessment runs 25+ specialised scanners across OWASP Top 10 categories, captures real HTTP evidence for every finding, and delivers a prioritised remediation report, typically in under an hour.

Frequently Asked Questions