security.txt Generator builds the file described in RFC 9116, which tells security researchers how to report a vulnerability to you. Enter at least one contact and an expiry, add your disclosure policy and encryption key if you have them, and copy the result to /.well-known/security.txt on your site. Every field is checked as it is generated.
How to read the result
The output is the file itself. Contact and Expires are the two required fields: a contact can be an email address (written as mailto:), an https:// URL or a phone number, and Expires is set to midnight UTC on the day you chose. Optional fields follow: Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy and Hiring. Notes under the file suggest what is missing, such as a policy link.
Defender tips
- Put a monitored shared mailbox in
Contact, not a person's address, so reports survive staff changes. - Keep
Expiresunder a year and put a reminder in the calendar to renew it; an expired file tells researchers the contact may be stale. - Link a short disclosure policy that states scope and safe harbour. Researchers are more willing to report when they know how you will respond.
- Serve the file over HTTPS as
text/plain, and consider signing it with an OpenPGP cleartext signature.
FAQ
Where does the file go?
At https://your-domain/.well-known/security.txt. RFC 9116 also allows a copy at /security.txt for older tools.
Do I need one per subdomain?
A security.txt describes the host that serves it, so researchers look on the host they found the issue on. Publish it on your main domain and on any other public web host you run, with the same contacts.
Is a security.txt a bug bounty?
No. It only says where to send reports. Rewards, if any, belong in the policy you link.