Security Headers Checker

What this security headers checker looks for

Enter a URL and this tool sends one ordinary GET request, follows any redirects, and inspects the response headers the server sends back. Each header is graded on whether it is present, and whether the value it carries actually provides protection — a header that exists but is misconfigured is a common and easily missed failure.

Content-Security-Policy (CSP)

The most important header on this list. CSP tells the browser which sources of script, style, images and frames are legitimate. When an attacker finds a cross-site scripting hole, a good CSP is what stops their injected script from actually running. We flag a missing policy, a policy that is only in report-only mode, and policies weakened by 'unsafe-inline', 'unsafe-eval' or wildcard sources.

Strict-Transport-Security (HSTS)

HSTS tells the browser to only ever contact your domain over HTTPS. It closes the window where a visitor's very first request goes out over plain HTTP and can be intercepted before your redirect fires. We check that it is present and that max-age is long enough to be useful — a policy that expires in a day is barely a policy.

X-Frame-Options and frame-ancestors

These control whether other websites can load your pages inside an iframe. Without them, an attacker can overlay an invisible copy of your site on top of their own and harvest clicks — clickjacking. The modern approach is the CSP frame-ancestors directive, so if you have that, this tool will tell you the older header is not required.

X-Content-Type-Options, Referrer-Policy and Permissions-Policy

Smaller headers that close specific gaps. nosniff stops browsers second-guessing your declared content types, which matters anywhere users can upload files. Referrer-Policy stops full URLs — including tokens and record IDs sitting in the path — leaking to every third party you link to. Permissions-Policy switches off browser features like camera and microphone that your site does not use, so injected content cannot request them.

Version disclosure

Headers like Server and X-Powered-By often advertise the exact build of your web server or framework. That is free reconnaissance: an attacker can look up known vulnerabilities for that precise version instead of probing for them. This is low severity on its own, and trivially fixed.

How the grade is calculated

Every check starts the report at 100 and deducts based on severity — more for a missing CSP than for a missing Permissions-Policy. Scores of 90 and above earn an A, 75 a B, 55 a C, 35 a D, and anything below that an F. The grade is a summary, not a verdict: read the individual findings, because one high-severity gap matters more than several low-severity ones.

Fixing the findings

Almost every header on this page is set in one place — your web server config, your CDN, or your framework's response middleware. A reasonable starting point for most sites:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

Roll the CSP out in report-only mode first. It is the one header on this list that can break a working site, and the reports will tell you what you are actually loading before you enforce anything.

Where to set them

The headers go in one place, and which place depends on what sits in front of your application. Setting them in two places is a common cause of duplicate or conflicting headers, so pick the outermost layer you control and do it there.

nginx

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

The always keyword matters — without it the header is omitted from error responses, which is exactly when you least want a page unprotected.

Apache

Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Next.js

// next.config.js
async headers() {
  return [{
    source: '/:path*',
    headers: [
      { key: 'X-Content-Type-Options', value: 'nosniff' },
      { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
    ],
  }];
}

A CDN or reverse proxy

If you run behind a CDN, its response-header rules are usually the cleanest place to set these, because they then apply to every origin behind it, including static assets and anything your application framework does not route. Check for duplicates afterwards — a header set at both the origin and the edge can appear twice, and browsers handle that inconsistently.

What headers do not do

Worth being blunt about, because grading tools can imply otherwise. None of these headers fix a vulnerability. They constrain what an attacker can do once they have found one. A perfect A grade on a site with an SQL injection flaw is still a compromised site. Treat the grade as a measure of how much defence-in-depth you have, and keep looking for the underlying bugs separately.