Advertisement
Guide
About the security.txt Generator
security.txt is a plain-text file, standardised as RFC 9116, that tells people who find a vulnerability on your site how to reach you. Researchers and automated scanners look for it at /.well-known/security.txt before trying to guess an email address.
Enter at least one contact and an expiry date; the rest is optional. The generator formats each field correctly and flags anything the standard does not allow.
Why it expires
Contact details go stale when people leave or inboxes close. The required Expires field tells reporters when to stop trusting the file. The RFC recommends less than a year ahead, so put a renewal reminder in your calendar when you publish it.
Signing the file
To prove the file has not been tampered with, sign it with OpenPGP: gpg --clearsign security.txt wraps the content in a signature block. Publish the signed version, and link your public key under Encryption so reporters can also send you encrypted details.
How to use it
- 1Add one or more contacts.
- 2Pick when the file expires.
- 3Add your policy, PGP key and canonical URL.
- 4Upload it to /.well-known/security.txt.
Frequently asked questions
Where does security.txt go?
At /.well-known/security.txt on each host, served over HTTPS as text/plain. You can also place a copy at /security.txt for older tools.
Which fields are required?
Contact (at least one) and Expires (exactly one). Everything else is optional.
What format does Expires use?
An ISO 8601 date and time, like 2027-06-30T00:00:00Z. The generator fills it in from your choice.
Should I use an email or a web form?
Either works. Many teams list a security@ address first and a reporting form or bug bounty page second.
Do I need a bug bounty to publish security.txt?
No. It only says where to report issues. A Policy link can explain whether you offer rewards and how you handle reports.