security.txt validator

What it checks

• That the file exists at /.well-known/security.txt (or only at the legacy /security.txt), over HTTPS, as text/plain; charset=utf-8, and isn't a web page returned by a catch-all route.
• The two required fields: at least one Contact (a mailto:, tel: or https:// address) and exactly one Expires in RFC 3339 format, not in the past and, as recommended, less than a year away.
• The optional fields: Canonical listing the address the file was found at, Encryption pointing to a key over HTTPS, Policy, Acknowledgments, Hiring and CSAF as HTTPS links, and Preferred-Languages given once as language tags.
• Mistakes tools trip over: bare email addresses, plain HTTP links, misspelt field names, stray lines that aren't fields or comments, and an OpenPGP signature that is cut off.

Why it matters

security.txt is how someone who finds a vulnerability in your site knows where to report it. Without one, reports go to a general inbox, a social media account or nowhere, and some get published instead.

Expires is required so a forgotten file doesn't keep pointing at an address nobody reads. Set a reminder to update it, or generate it in your build with a date a few months ahead.

Questions

What is the minimum valid security.txt?

Two lines: Contact: mailto:security@example.com and Expires: followed by a date under a year away, such as 2027-06-30T00:00:00.000Z. Serve it at /.well-known/security.txt over HTTPS.

Does it have to be signed?

No. Signing with OpenPGP is optional. It lets researchers confirm the file hasn't been tampered with, but it has to be re-signed every time the file changes.

Can security.txt redirect to another domain?

Yes. Many large sites redirect it to a central file. Researchers are told to check such redirects, so list the final address in a Canonical field.