CometWeb tools
Security headers checker
A security headers check for one URL · HSTS, CSP, X-Frame-Options and the rest, each with a status and an explanation
This security headers checker fetches a public URL from our server and reads the HTTP response headers that tell a browser how to protect the page: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options or frame-ancestors, X-Content-Type-Options, Referrer-Policy and Permissions-Policy, plus Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy. Each header gets a status and a short explanation. It also flags Server and X-Powered-By headers that reveal your server software. The result is a signal about browser configuration; finding vulnerabilities in the application itself takes a security test.
Which headers to fix first
Start with HSTS and nosniff. Each is one line in the server or CDN config and rarely breaks anything. HSTS needs the whole site on HTTPS, so start with a shorter max-age, check that every subdomain answers over HTTPS, and only then raise it to a year.
CSP takes the most work and gives the most back. A policy that still allows 'unsafe-inline' scripts stops few XSS attacks. Start with Content-Security-Policy-Report-Only, watch the reports for a week or two, then switch to the enforcing header. You can build the policy in our CSP generator.
Framing and referrer are quick wins. frame-ancestors 'self' (or X-Frame-Options: SAMEORIGIN for older browsers) blocks clickjacking. Referrer-Policy: strict-origin-when-cross-origin keeps paths and query strings, which sometimes hold tokens or email addresses, away from other sites.
Check who sets the headers. A CDN or proxy can add, change or strip a header after your application sends it. We saw this on cometweb.io, where the edge replaced our full CSP with a single directive. This tool shows what reaches a visitor, so if the result differs from your config, look at the layer in between.
Check several kinds of response
Headers usually come from three layers: the application, the web server and the CDN, and rules often cover only some responses. Check the home page, one inner page and an error page, such as a URL that returns 404. The differences show which layer adds a header and which one skips it.
OWASP · Secure Headers Project ↗Abbreviations in the result
- HSTSStrict-Transport-Security
- Enforces HTTPS for the time set in max-age.
- CSPContent-Security-Policy
- The allowed sources of scripts, styles and other resources.
- XFOX-Frame-Options
- The older way to stop a page being framed.
- COOPCross-Origin-Opener-Policy
- Isolates the page window from other sites' windows.
- CORPCross-Origin-Resource-Policy
- Sets who may load a given resource.
Enter the URL and choose Check headers. Our server fetches the page the way a browser does, follows redirects and reads the response headers of the final page. You get each header with a status and an explanation. In a browser you can see the same data in the developer tools: the Network tab, the first document request, the Response Headers section.
Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, protection against framing (frame-ancestors or X-Frame-Options), Referrer-Policy and Permissions-Policy. Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy help sites that need cross-origin isolation or serve files to other domains.
Usually a year, which is 31536000 seconds. That is also what the browsers' preload list requires, together with includeSubDomains and preload. We mark a value under 180 days as weak. While rolling it out, start shorter and raise it once you know every subdomain works over HTTPS.
Most often because of 'unsafe-inline' or 'unsafe-eval' in script-src, a wildcard as a script source, or no script-src and no default-src at all. A policy sent only as Report-Only is weak too, because it blocks nothing. Instead of 'unsafe-inline', use nonces or hashes for the scripts you need.
frame-ancestors in CSP is the current standard and can name several sites. X-Frame-Options only knows DENY and SAMEORIGIN. When both are set, browsers that support frame-ancestors use frame-ancestors. Sending both makes sense if you still care about very old browsers.
Remove X-Powered-By, since browsers do not use it. From Server, remove at least the version number. Hiding them does not patch any vulnerability, but it stops hinting where to start an attack.
A good result means the browser gets sensible instructions. Headers will not find SQL injection, weak passwords or outdated plugins. Treat the result as one signal and check the application separately, for example with a security test.
Our server fetches the URL, so it reaches our logs. We do not keep the results. Private and local addresses are rejected, including after a redirect.
What else might come in handy
TLS, headers, cookies and exposure — with a score breakdown and a remediation plan.