Security Headers
Check the HTTP security headers of a web page: HSTS, Content-Security-Policy, framing, referrer and more, each with what it does.
How Security Headers Work
Lines a web server sends with every page that tell the browser how to protect it: use only HTTPS from now on, run scripts only from these sources, do not let other sites put this page in a frame.
They cost nothing to send and close whole classes of attack, such as cross-site scripting, clickjacking and a downgrade to plain HTTP. A missing header does not break the page, which is why they are so often forgotten.
- Enter a host name or a full address:
example.comorhttps://example.com/login. Without a scheme, HTTPS is used. - Redirects are followed, up to 5, and the page that finally answers is checked. Every hop is listed.
- Each header gets a verdict and a sentence on what it does or what is missing. The raw headers are below.
- Headers can differ from page to page, so check the pages that matter, such as a login page.
Six headers count: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, framing protection, Referrer-Policy and Permissions-Policy. A pass counts one, a warning half.
All six make an A; an A+ adds Cross-Origin-Opener-Policy and no software version in the headers. Cookies, Cross-Origin-Resource-Policy and the software version are reported without weight.
A header that is present is not proof the policy is good. A Content-Security-Policy is checked for the common holes, 'unsafe-inline', 'unsafe-eval' and wildcard sources, not read line by line.
The certificate and the TLS setup are the SSL/TLS Server Test's job; a page whose certificate is not trusted is not checked here.
The page that finally answers, after redirects, is checked.