What Is security.txt?
security.txt is a proposed internet standard (RFC 9116) that defines a simple, machine-readable file for websites to communicate their security vulnerability disclosure policies. It tells security researchers — and automated scanners — exactly who to contact if they find a vulnerability in your application.
Think of it as the robots.txt of security contact information. It's a small investment with a significant payoff: researchers who find issues in your software can report them responsibly instead of going public or, worse, staying silent.
Why You Should Have One
Without a clear disclosure channel, security researchers face a frustrating dilemma: they've found a vulnerability in your system, but they have no obvious way to report it. The result is often delayed disclosure, public posting, or simply giving up. A security.txt file removes that friction entirely.
- Establishes a clear, trusted contact point for researchers
- Demonstrates security maturity to partners, auditors, and customers
- Reduces time-to-fix for reported vulnerabilities
- Can specify a bug bounty program, policy URL, and preferred languages
Where to Host It
The file must be hosted at one of two locations, with the .well-known path being preferred:
- Preferred:
https://example.com/.well-known/security.txt - Fallback:
https://example.com/security.txt
It must be served over HTTPS. HTTP-only hosting is not considered compliant.
Anatomy of a security.txt File
Here's an example of a well-structured security.txt:
Contact: mailto:security@example.com
Contact: https://example.com/security-report
Expires: 2026-01-01T00:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Acknowledgments: https://example.com/security/hall-of-fame
Policy: https://example.com/security/disclosure-policy
Preferred-Languages: en, fr
Canonical: https://example.com/.well-known/security.txtField Reference
| Field | Required? | Purpose |
|---|---|---|
Contact | Yes | How to report a vulnerability (email or URL) |
Expires | Yes | When the file should be considered stale |
Encryption | Recommended | PGP key for encrypted reports |
Acknowledgments | Optional | Where reporters are credited |
Policy | Recommended | Link to full disclosure policy |
Canonical | Recommended | Authoritative URL of this file |
Signing Your security.txt with PGP
RFC 9116 recommends signing your security.txt file with a PGP key. This lets researchers verify the file is authentic and hasn't been tampered with (e.g., by a compromised CDN or supply chain attack). Use a detached signature or a clearsign wrapper. Store the public key at the URL referenced in the Encryption field.
Writing a Responsible Disclosure Policy
The Policy field should link to a human-readable document that clearly covers:
- What's in scope (which domains, apps, and systems)
- What's out of scope (social engineering, physical attacks)
- What researchers can expect from you (response time, updates, credit)
- What you expect from researchers (no data exfiltration, no DoS)
- Whether you run a bug bounty program and if so, what rewards are available
The Expires Field: Don't Let It Go Stale
One of the most overlooked details: the Expires field is required per RFC 9116. Set it at most one year in the future, and update it regularly. An expired security.txt signals to researchers and tools that your security posture may be neglected — the opposite of the impression you want to give.
Setting up security.txt takes under an hour. It's one of the highest-value, lowest-effort security improvements you can make to any public-facing web project.