What this tool checks
- Strict-Transport-Security (HSTS) and max-age
- Content-Security-Policy and weakening directives
- X-Frame-Options or frame-ancestors
- X-Content-Type-Options: nosniff
- Referrer-Policy
- Permissions-Policy
- Cross-Origin-Opener/Resource-Policy
- Version disclosure in Server and X-Powered-By
How to use it
- 01
Enter a domain or a full URL (https://example.com/login).
- 02
Press Analyze; redirects are followed and the final page is graded.
- 03
Apply the recommended value for each header from the notes in the report.
Technical details
Grading
HSTS and CSP weigh the most, followed by clickjacking and MIME protection. A CSP containing 'unsafe-inline' or 'unsafe-eval' without nonces or hashes is treated as weak.
Redirect chain
The tool follows redirects one by one and reads headers from the final response. The whole chain appears in the report, so you can verify the HTTP to HTTPS move as well.
Rolling out CSP
On an existing site, publish CSP first as Content-Security-Policy-Report-Only, watch the violation reports, then switch to enforcing mode.
Frequently asked questions
Which header should I start with?
The quickest wins are X-Content-Type-Options, X-Frame-Options and Referrer-Policy — one line each. Add HSTS once every subdomain supports HTTPS, and roll out CSP with testing.
Why don't you check X-XSS-Protection?
Modern browsers no longer support it, and it could introduce new problems in some cases. Today, Content-Security-Policy is the right tool against XSS.
Where should I add the headers?
At the web server (nginx, Apache, IIS), the CDN (e.g. Cloudflare Transform Rules) or the application framework (Next.js, Express, Laravel). Managing them in one layer keeps them consistent.
Why is showing a version in the Server header a problem?
An exact version makes it easier to target known vulnerabilities in that release. Hiding it is a small but easy improvement.