What Is security.txt?
When a security researcher discovers a vulnerability on your website, what do they do? Without a clear contact path, they may give up, post publicly, or reach the wrong person entirely. security.txt is a standardized file — defined in RFC 9116 — that solves this problem by giving researchers an authoritative, machine-readable place to find your disclosure policy and contact details.
Think of it as a robots.txt for security researchers. It lives at /.well-known/security.txt (the preferred location) or /security.txt at the root of your domain.
Why Should You Implement security.txt?
Responsible disclosure programs benefit everyone. Here's why security.txt matters:
- Reduce time to report: Researchers can find your contact instantly instead of hunting through footer links or support pages.
- Set clear expectations: Specify your preferred contact method, encryption keys, and whether you offer bug bounties.
- Signal maturity: Publishing a security.txt file signals that your organization takes security seriously and welcomes responsible reports.
- Prevent public disclosure: Researchers who find a contact path are more likely to report privately rather than going straight to public forums.
The security.txt File Format
The file uses a simple key-value format, one directive per line. Here is an example of a well-formed security.txt file:
Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2026-01-01T00:00:00.000Z
Encryption: https://example.com/.well-known/pgp-key.txt
Acknowledgments: https://example.com/security/hall-of-fame
Policy: https://example.com/security/policy
Preferred-Languages: en, fr
Key Directives Explained
| Directive | Required? | Purpose |
|---|---|---|
Contact | Yes | How to report a vulnerability (email, URL, or phone) |
Expires | Yes | When this file should be considered stale (ISO 8601 datetime) |
Encryption | No | Link to a PGP public key for encrypted reports |
Acknowledgments | No | URL to a page recognizing reporters |
Policy | No | Link to your full vulnerability disclosure policy |
Preferred-Languages | No | Languages your team can handle reports in |
Hiring | No | Link to security-related job openings |
Digital Signatures with security.txt
RFC 9116 strongly recommends signing your security.txt with a PGP signature. This prevents attackers from tampering with the file to redirect reports or plant false contact information. To sign the file:
- Generate or use your existing PGP key pair.
- Create a clearsign signature:
gpg --clearsign security.txt - Rename the output to
security.txt— the signed version replaces the plain text file. - Publish your public key at the URL referenced in the
Encryptionfield.
Common Mistakes to Avoid
- Setting Expires too far in the future: Update the file at least annually. Stale files mislead researchers.
- Using a generic support email: The Contact address should reach your actual security team, not a help desk that may not escalate properly.
- Forgetting HTTPS: Always serve security.txt over TLS. A file served over HTTP can be intercepted and modified in transit.
- Not testing discoverability: Use tools like securitytxt.org to validate your file after publishing.
Getting Started Today
Creating a security.txt file takes less than 30 minutes. Start with the minimum required fields (Contact and Expires), serve it at /.well-known/security.txt over HTTPS, and expand from there as your program matures. It's one of the simplest, highest-impact security hygiene steps a web team can take.