SupperTools

Useful Online Tools & Utilities to Make Everyday Tasks Easier.

Security.txt Generator for Responsible Disclosure Contact

Create a standards based security.txt file with your contact details, expiry date and disclosure policy links so researchers can report vulnerabilities to you.

How researchers should reach you.
When this policy expires (Max 1 year recommended).
Link to your public PGP key.
Link to your vulnerability disclosure policy.
Link to your security researchers hall of fame.
Link to security-related job openings.
The permanent URL for this file.
Comma-separated list of language codes.
Generated security.txt Content

Place this file at /.well-known/security.txt or the root directory.

When a security researcher finds a vulnerability on your website, the worst outcome is that they cannot find anyone to tell. The standardised solution is a small plain text file called security.txt, published at a predictable address, that lists how to report security problems to you. This Security.txt Generator builds that file properly, so researchers get a working contact route instead of a dead end, and you hear about issues privately before they become public.

What security.txt Is and Why Sites Publish One

The security.txt standard, published as RFC 9116, defines a machine readable file placed at /.well-known/security.txt on a domain. Its fields point researchers to a contact address, your vulnerability disclosure policy, an encryption key for sensitive reports, and an expiry date after which the information should be treated as stale. Organisations from small blogs to major platforms publish one because it shortens the path between "someone found a problem" and "the right person knows". It also signals that reports are welcome through proper channels, which encourages responsible disclosure rather than public posting.

What Goes Into the Generated File

  • Contact: the essential field: an email address or contact page where security reports should go.
  • Expires: the date the information remains valid until, so researchers know the details are current.
  • Policy: a link to your full vulnerability disclosure policy, if you have one.
  • Encryption: a link to a public key so sensitive findings can be sent encrypted.
  • Optional fields: preferred languages, acknowledgments page, hiring page and the canonical location of the file itself.

How to Create Your security.txt File

  1. Decide which inbox or contact page will receive security reports, and make sure someone actually monitors it.
  2. Enter that contact detail in the generator.
  3. Add the optional fields you have: an expiry date, a link to your disclosure policy, an encryption key link and preferred languages.
  4. Click Generate Security.txt.
  5. Copy the generated content and save it as a plain text file named security.txt.
  6. Upload it so it is reachable at https://yourdomain.com/.well-known/security.txt over HTTPS.
  7. Open that address in your browser to confirm the file loads correctly.

Where the File Proves Its Worth

A researcher testing a login form notices it reveals whether an email address has an account. Instead of posting the detail publicly, they look for your security.txt, find the contact address, and email a private report with reproduction steps, so you fix the issue quietly. A company formalising its security posture adds the file to its launch checklist alongside its robots.txt work, giving scanners and researchers an official channel from day one. And an agency handing over a client site includes the file with the client's monitored security mailbox as the contact, so reports still reach someone responsible long after the project ends.

Keeping Your security.txt Useful: Tips and Mistakes

The commonest mistake is pointing the contact field at an inbox nobody reads, which is worse than having no file because it creates false confidence on both sides. Keep the expiry date in the future and diary a renewal, since an expired file tells researchers your details may be abandoned. Serve the file as plain text over HTTPS at the well known location; the legacy root location is still recognised, but the standard address is /.well-known/security.txt. Do not confuse this file with robots.txt: one guides automated crawlers, the other guides humans with security reports. Finally, publish only contact routes you are happy to be public, because the file is deliberately world readable, much like the response details reviewed by the Security Headers Auditor.

Frequently Asked Questions About security.txt

Where exactly should I host the file?

At /.well-known/security.txt on your domain, served over HTTPS as plain text. Placing a copy at the root /security.txt as well is harmless, but the well known path is the standard.

Is security.txt the same as robots.txt?

No. Robots.txt gives instructions to automated crawlers about which paths they may fetch. Security.txt gives human security researchers a contact route for reporting vulnerabilities.

Which fields are required?

The standard requires a Contact field and an Expires field. Everything else, such as policy, encryption and preferred languages, is optional but helpful.

Do I need a PGP key to use the generator?

No. The encryption field is optional. Add it only if you actually maintain a key and can decrypt reports sent with it.

Is having a security.txt mandatory?

It is not legally required for most sites, but it is widely recommended, and some organisations and scanners check for its presence as a sign of security maturity.

A Small File That Opens the Right Door

A security.txt file takes minutes to generate and publish, yet it can be the difference between a vulnerability being reported to you privately and being announced to everyone. Generate the file with a monitored contact, keep it current, and you give every honest researcher a clear, standard way to help protect your site.

Related Tools