Security.txt Generator
Generate a security.txt file (RFC 9116) with contact info, PGP key, disclosure policy, and expiry — ready for /.well-known/security.txt
Fill in your security contact details and get a standards-compliant security.txt file
(RFC 9116). Publish it at /.well-known/security.txt so researchers can report
vulnerabilities responsibly.
Email or URL where researchers can reach you. At least one required.
ISO date when this file should be considered stale. Required field.
Link to your PGP/GPG public key for encrypted reports.
Link to your security hall of fame or acknowledgments page.
Link to your vulnerability disclosure / bug bounty policy.
Comma-separated language tags (RFC 5646). Default: en.
If the file is also available elsewhere, point to the canonical location.
Link to security-related job openings at your organization.
About this tool
security.txt is a proposed IETF standard (RFC 9116) that helps
security researchers find the right contact when they discover a vulnerability in
your website or service. You create a plain-text file with fields like
Contact, Expires, and Encryption, then serve
it at the well-known path /.well-known/security.txt. When a researcher
finds a bug, they check this file to learn where to report it and what PGP key to
use for encrypted communication.
Example: with a contact email of security@example.com,
an expiry of 2027-01-01, and a policy URL, the generator produces:
Contact: mailto:security@example.com Expires: 2027-01-01T00:00:00.000Z Policy: https://example.com/disclosure-policy
The output includes a comment header with the link to the RFC, followed by key-value pairs sorted canonically (Contact first, then alphabetical). You host the file as static text on your site, and researchers — and automated scanners — know exactly where to look.
FAQ
Where do I put the security.txt file? ›
Serve it at the well-known path: <code>/.well-known/security.txt</code> on your domain. For example, if your site is <code>example.com</code>, the full URL should be <code>https://example.com/.well-known/security.txt</code>. Most web servers and CDNs let you place a static text file at that location.
Is security.txt required by law or regulation? ›
No — RFC 9116 is voluntary. However, it is increasingly expected by security researchers, bug-bounty platforms, and compliance frameworks. Organizations that handle user data or run public-facing services should publish one to signal that they welcome responsible disclosure. Some procurement questionnaires now ask for it.
What happens if the Expires field passes? ›
Nothing automatically breaks, but researchers and automated scanners may consider the file stale and look for a newer contact. Best practice is to set an expiry no more than one year out and update the file before it lapses. The generator sets the default to one year from today.
Can I have more than one Contact field? ›
Yes. RFC 9116 allows multiple Contact fields — for example, one email and one web form URL. This tool provides two Contact slots. The first is required; the second is optional. Both appear in the output when filled.