Type a domain: you see whether it publishes a security.txt, the file that tells security researchers how to report a vulnerability, and whether the file follows RFC 9116. An expired or malformed file is ignored by the tools that read it.
Our server fetches one file, the security.txt of the domain you type (at its standard address, then at the old one), and keeps the answer ten minutes.
What most often makes a security.txt useless, and how to fix it.
Why. Expires is required and was set once, usually a year ahead. Nothing warns you when the date passes.
Fix. Set a new date less than a year away and add a reminder. If the file is generated by your site, generate the date at deployment.
Why. The field takes an address with its scheme. “security@acme.org” alone is not one, and strict tools reject the file.
Fix. Write “Contact: mailto:security@acme.org”. Use a shared mailbox that someone reads, not a person’s address.
Why. The site sends every unknown address to a page with a 200 status, so the file seems to exist and is in fact a web page.
Fix. Publish a real text file at /.well-known/security.txt, served as text/plain, and let unknown addresses answer 404.
It gives people who find a vulnerability in your site or systems a way to tell you: an address, optionally a policy and an encryption key. Without it, reports get lost or go public.
No law requires it in general. Several governments ask it of their own sites, and customers who assess suppliers increasingly look for it.
No. An OpenPGP signature is optional; the checker notes its presence without verifying it.
The domain you type. Our server fetches the file at its two possible addresses, because a browser may not read it across origins; the answer is kept ten minutes. See the privacy policy.