Check the HTTP response headers that tell browsers how to protect a site's visitors, with a plain-English explanation and the exact header to add for anything missing.
Security headers are instructions a website sends to the browser with every page: always use HTTPS here, only run scripts from these places, never show this page inside another site's frame. They cost nothing to add and close off whole classes of attack, and most sites are missing several.
Enter a domain or URL to see which headers it sends, a grade weighted by what each one protects against, and the exact line to add for anything missing. We follow redirects first, so the grade is for the page visitors actually land on.
Even a site that redirects every visitor to HTTPS has a weak moment: the very first request, when someone types the address without https://. That request goes out in plain text, and anyone on the same network can intercept it and send the visitor somewhere else. HSTS tells the browser to skip that step and use HTTPS for the domain automatically for a set period.
A typical value is max-age=31536000; includeSubDomains (one year, every subdomain). Only add includeSubDomains once every subdomain really serves HTTPS, because browsers will refuse to load any that do not. The preload flag asks to be built into browsers so even the first visit is protected; it is hard to undo, so add it last.
CSP tells the browser where scripts, styles, images and frames are allowed to come from. Its main job is limiting the damage from cross-site scripting: if an attacker manages to inject a script tag, a good policy stops the browser from running it. It is the most powerful header on this list and the hardest to add, because a policy that is too strict breaks your own site.
The safe way in is Content-Security-Policy-Report-Only, which reports violations without blocking anything. Run it until the reports are quiet, then switch to enforcing. A policy that allows 'unsafe-inline' scripts is better than none but does not stop typical XSS; nonces or hashes for inline scripts are the proper fix.
Without framing rules, any site can load yours inside an invisible frame and line up its own buttons over yours, so a visitor who thinks they are clicking a game is actually clicking "delete account" or "transfer". X-Frame-Options: SAMEORIGIN stops other sites framing your pages. The modern equivalent is frame-ancestors 'self' inside CSP; sending both is fine.
X-Content-Type-Options: nosniff stops browsers guessing file types, which matters most on sites that let users upload files. Referrer-Policy controls how much of the current URL is passed to other sites when visitors follow a link; strict-origin-when-cross-origin sends only your domain. Permissions-Policy switches off browser features such as the camera, microphone and location for your pages and anything embedded in them. Cross-Origin-Opener-Policy isolates your page from windows opened by other sites.
Each of these is one line in your web server or CDN configuration. None of them is likely to break anything, which makes them the easiest points to pick up.
Some headers help attackers rather than visitors. A Server header with a version number (nginx/1.18.0) or an X-Powered-By header naming your framework tells anyone scanning for a known vulnerability exactly what you run. They are not scored here, but they are listed so you can switch them off. X-XSS-Protection is also listed: the browser filter it controlled has been removed, and current advice is to send 0 or nothing.
Headers are set wherever responses are produced: your web server (an add_header line in nginx, Header set in Apache), your application framework, or your CDN (Cloudflare and others let you add response headers in their dashboard). Setting them at the CDN covers every page at once. After a change, run this check again; cached pages may take a little while to pick it up.
Strict-Transport-Security and Content-Security-Policy protect against the most serious attacks, followed by X-Frame-Options (or CSP frame-ancestors) against clickjacking and X-Content-Type-Options. Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy are worth having but matter less, and the grade is weighted that way.
Most will not. HSTS with includeSubDomains can lock out a subdomain that has no HTTPS, and a strict Content-Security-Policy can block your own scripts, so roll CSP out in report-only mode first. X-Content-Type-Options, Referrer-Policy and X-Frame-Options are very unlikely to cause problems.
No. Modern browsers removed the filter it controlled, and in older ones it could be abused. Send X-XSS-Protection: 0 or leave it out, and use Content-Security-Policy instead.
Each tool weighs headers differently and some check the first response rather than the page after redirects. We grade the final page a visitor lands on, and weight each header by what it protects against.
No. Security headers are browser-side defences that limit the damage when something else goes wrong. They do nothing about vulnerabilities in your application, weak passwords or outdated software on the server.
The checker runs on our server and deliberately refuses private, internal and reserved addresses, so it cannot be used to probe networks it should not see. Only public sites on the standard web ports can be checked.