What Is security.txt?
When security researchers discover a vulnerability in your web service, how do they contact you? Without a clear, published contact method, they may give up, disclose publicly, or find the wrong person. security.txt solves this problem.
Standardized in RFC 9116, security.txt is a plain text file hosted at /.well-known/security.txt (or /security.txt) that provides a consistent, machine-readable location for security contact information and vulnerability disclosure policies.
Why It Matters
Security researchers are increasingly professionalized, and many won't disclose vulnerabilities to organizations that make it difficult to report them. A clearly published security.txt:
- Removes friction for researchers trying to do the right thing
- Reduces the chance of accidental or malicious public disclosure
- Demonstrates security maturity to partners, auditors, and regulators
- Helps automated security tools identify the right contacts during incident response
Anatomy of a security.txt File
Here is a well-structured example:
Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2026-12-31T23:59:59Z
Encryption: https://example.com/pgp-key.txt
Acknowledgments: https://example.com/security/hall-of-fame
Policy: https://example.com/security/policy
Preferred-Languages: en, es
Canonical: https://example.com/.well-known/security.txtRequired and Recommended Fields
| Field | Required? | Description |
|---|---|---|
Contact | Yes | How to report a vulnerability. Can be email, URL, or phone. Multiple entries allowed. |
Expires | Yes | When this file should be considered stale. Prevents outdated info from being trusted. |
Encryption | Recommended | URL to a PGP key for encrypted communication. |
Acknowledgments | Recommended | Link to a page crediting reporters. |
Policy | Recommended | Link to your full vulnerability disclosure policy. |
Canonical | Recommended | The authoritative URL of this file, preventing confusion from copies. |
Preferred-Languages | Optional | Languages your security team can respond in. |
Signing Your security.txt
RFC 9116 strongly recommends signing your security.txt file with PGP. This prevents attackers from modifying your contact information to redirect vulnerability reports away from you. A signed file has a PGP signature block wrapping the content:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Contact: mailto:security@example.com
Expires: 2026-12-31T23:59:59Z
...
-----BEGIN PGP SIGNATURE-----
[signature data]
-----END PGP SIGNATURE-----Researchers who validate the signature know the file is authentic and hasn't been tampered with.
Writing an Effective Disclosure Policy
The Policy field links to your full disclosure policy page. A good policy should address:
- Scope — Which systems and domains are in scope for testing
- Out of scope — What researchers should NOT test (e.g., production user data, DoS attacks)
- Response timeline — How quickly you acknowledge reports and provide updates
- Safe harbor — Legal protection for good-faith researchers
- Recognition — Whether you offer a bug bounty or public acknowledgment
Deploying security.txt
Deployment is straightforward. Place the file at /.well-known/security.txt and optionally also at /security.txt for compatibility. Serve it as text/plain; charset=utf-8.
Set a reminder to update the Expires field before it lapses — an expired security.txt is almost worse than none, as it signals neglect.
Tools to Help
- securitytxt.org — Official generator tool
gpg --armor --clearsign security.txt— Sign with your PGP key- Various security scanning tools automatically check for and validate security.txt
Setting up security.txt takes less than an hour and signals to the security community that your organization takes responsible disclosure seriously. It's one of the easiest, highest-value security posture improvements any web service can make.