Free check
What your site tellsa browser about itself.
A site’s security posture is mostly published facts: which headers it sends, what its policy actually permits, how its cookies are scoped, what its certificate says. All of it readable from outside without touching anything.
We fetch your home page the way a browser would, plus /.well-known/security.txt. No payload is ever sent, no path is guessed, and nothing is stored.
For machines: the same report is JSON at /api/web?d=yourdomain.
Questions
Does this attack my site?
No, and it never will. It fetches your home page the way a browser would, follows the redirect chain, and reads /.well-known/security.txt, which is a file that exists to be fetched by strangers. It sends no SQL injection, no cross-site scripting, no payload of any kind. It does not submit or probe forms, does not guess paths such as /.git or /admin, and does not scan ports. Reports that do those things are running an attack, which is an offence against a domain you have no written authorisation for, whatever the result.
What does the score out of 100 mean?
Nine scored sections: HTTPS and redirect 10, certificate 15, TLS 10, HSTS 10, Content-Security-Policy 20, framing and MIME 10, referrer and permissions 5, cookies 10, content integrity 10. Cross-origin isolation, security.txt, version disclosure and CAA are reported and never move the score, because a site that omits them is not less secure.
Why is CSP worth the most?
Because it is the only header here that limits what an injected script can do, and because its presence says almost nothing. A policy carrying 'unsafe-inline' with a wildcard source passes any checker that only looks for the header, and stops nothing. This one reads the policy: whether it is enforced or merely reporting, whether default-src, object-src, base-uri and frame-ancestors are declared, and whether any directive accepts every origin.
It says TLS 1.0 was not tested. Why not?
Because we cannot ask honestly. The runtime this check uses has TLS 1.0 and 1.1 compiled out, so a refusal would come from our own stack rather than from your server, and we would be reporting our limitation as your result. It is marked not tested rather than assumed absent.
My site sets no cookies and still scored full marks for them. Is that right?
Yes. A site that sets no cookies has no flags to get wrong. Scoring it down for the absence would be marking the safer choice as a fault.
Is anything stored?
No. The domain goes to our resolver and to your server. A finished report is held in memory for fifteen minutes so a repeated check costs your site nothing, and it is gone after that or on the next deploy. Nothing is written to disk and nothing is logged against you.
I scored badly. What do I fix first?
In this order. Get HTTPS working and make plain HTTP redirect to it, because everything else assumes a connection nobody can read. Add HSTS with a max-age of at least six months, which closes the gap on a visitor's first request. Then add a Content-Security-Policy, and write it to say what may load rather than merely existing: declare default-src, object-src, base-uri and frame-ancestors, and keep unsafe-inline out of script-src. Those three are most of the score and all of them are configuration rather than code.
Can I check a site I do not own?
Yes, and that is deliberate. Everything read here is what your browser is already told when it loads the page, so a report on someone else's site contains nothing they have not already published to every visitor. That is also the reason the check refuses to send payloads or guess paths: the moment it does either, it stops being a reader and becomes something you would need their permission for.
Send a brief. A person reads it.
Tell us what you are running today and what you want it to do instead. You will not get a form letter back. The person who writes to you is the same one who would do the work.
Mon–Fri 08:30–21:00 · Sat–Sun 11:00–21:00 CETReply within 48 hours, S/MIME-signed.