Security headers check for your website

What a security headers check looks at

With every page, your server sends the browser a few instructions: use HTTPS only, load scripts only from these places, do not let other sites embed this page. These are security headers. When one is missing, nothing breaks and it does not mean the site was hacked, but the browser has one guard fewer if something else goes wrong, such as an injected script or a hostile page that frames yours.

The check requests your homepage like a browser, follows redirects and reads the final response. It does the same for the main hosts it finds, such as www or api. It sends ordinary GET requests, plus one request with a foreign Origin header to test CORS. Nothing is submitted to your forms.

Header by header: what we flag

More checks on the same responses

• /.well-known/security.txt that is missing, expired or invalid, so whoever finds a problem does not know where to report it.
• Third-party scripts without Subresource Integrity (SRI), and HTTP resources on HTTPS pages (mixed content).
• Private IP addresses or names like staging or internal in response headers.
• Responses that set a session cookie without private or no-store in Cache-Control, so a shared cache may keep them.
• A mixed set: some modern security headers present, but HSTS or CSP missing.
• Whether the homepage is sent compressed.

How to fix the usual gaps

Most headers take one line in the web server, the hosting panel or the CDN settings. Examples for nginx:

• add_header Strict-Transport-Security "max-age=31536000" always; on the HTTPS server, for www and the bare domain. Add includeSubDomains and preload only once every subdomain serves HTTPS.
• add_header X-Content-Type-Options "nosniff" always; and add_header X-Frame-Options "SAMEORIGIN" always;
• server_tokens off; hides the nginx version; expose_php = Off in php.ini removes the PHP version from X-Powered-By.
• Mark session cookies Secure, HttpOnly and SameSite in your application or CMS settings.
• Build CSP last: start with Content-Security-Policy-Report-Only to see what would break, then switch to the enforcing header. Our check treats a report-only policy as not protecting yet.

An nginx pitfall: by default, an add_header inside a location block replaces every add_header line inherited from the server block, so headers can vanish on some pages. Run the check again after each change.

What this check does not do

• It does not rate Referrer-Policy, Permissions-Policy or the Cross-Origin headers one by one; we only compare them across hosts. OWASP recommends setting Referrer-Policy and Permissions-Policy explicitly, so check them yourself.
• It gives no letter grade for headers alone.
• It reads the homepage of each main host, not every page. Inner pages, API responses and admin areas may send different headers.
• For CSP it checks where scripts may load from. It does not test whether an injection is possible or whether your policy breaks the site.
• It sees cookies set in the server response of the homepage, not cookies set by JavaScript or after login.
• It does not ask for X-XSS-Protection: OWASP advises not to set it, or to set it to 0.
• Hiding version numbers is tidy, but it does not update the software. See the outdated software check.