security.txt: Tell Researchers How to Report Vulnerabilities

A security researcher finds a bug in your app. What do they do next? Without a clear channel, they end up guessing at security@, poking a support form, or — worst case — posting it publicly. security.txt (standardized as RFC 9116) fixes that with a small, predictable file.

Where it lives

Serve it at:

https://example.com/.well-known/security.txt

The /.well-known/ path is a reserved location for machine-readable site metadata, so tools and researchers know exactly where to look.

The fields

Only two are required:

Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00Z

• Contact — how to reach you: an email, a reporting form URL, or a phone number. You can list several, most-preferred first.
• Expires — a single ISO 8601 timestamp after which the file should be considered stale. Set it 6–12 months out and refresh it.

Useful optional fields:

• Encryption — a URL to your PGP public key for encrypted reports.
• Policy — a link to your disclosure / safe-harbor policy.
• Acknowledgments — a hall-of-fame page crediting reporters.
• Preferred-Languages — e.g. en, tr.
• Canonical — the file's own canonical URL.

Why bother

It signals that you take security seriously, shortens the path from discovery to responsible disclosure, and is increasingly expected by bug-bounty platforms and automated scanners. It costs nothing to add.

Build a compliant file — with the fields in the right order and the required ones validated — using the Security.txt Generator. While you're hardening things, it's worth confirming your TLS is healthy with the SSL Certificate Checker.