The Problem: Security Researchers Can't Find You
Security researchers discover vulnerabilities in web applications every day. Many of them want to do the right thing — report the issue responsibly so it can be fixed before it's exploited. But there's a persistent problem: how does a researcher actually contact you?
Without a clear, publicized disclosure channel, researchers face a frustrating guessing game: Try to find a security email in the footer? Search LinkedIn for someone who looks like a security engineer? Post on Twitter and hope someone from the company responds? This friction means many vulnerabilities go unreported, or get reported through inappropriate public channels.
security.txt solves this problem with an elegant simplicity: a standardized plain-text file that tells researchers exactly how to report a vulnerability to you.
What Is security.txt?
security.txt is defined in RFC 9116 (published by the IETF in 2022). It specifies that web servers should host a plain-text file at:
https://example.com/.well-known/security.txt(canonical location)https://example.com/security.txt(fallback)
The file uses a simple key-value format, similar to email headers, and contains information like your security contact email, a link to your vulnerability disclosure policy, and an expiry date for the file itself.
A Complete security.txt Example
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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/policy
Preferred-Languages: en, de
Canonical: https://example.com/.well-known/security.txt
-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----Field-by-Field Breakdown
| Field | Required? | Description |
|---|---|---|
| Contact | Yes | How to report a vulnerability. Can be email, URL, or phone. Multiple entries allowed. |
| Expires | Yes | ISO 8601 datetime. Prevents stale contact info from being used. Must be in the future. |
| Encryption | Recommended | Link to a PGP public key for encrypted submissions. |
| Acknowledgments | Optional | URL of a page thanking security researchers who reported issues. |
| Policy | Recommended | Link to your formal vulnerability disclosure or bug bounty policy. |
| Preferred-Languages | Optional | Languages your team can respond in. |
| Canonical | Recommended | The authoritative URL of this security.txt file. |
| Hiring | Optional | Link to security-related job postings — nice bonus for researchers. |
Why the Expiry Field Matters
The Expires field is required for good reason: it forces you to actively maintain your security.txt. An expired security.txt tells researchers (and automated tools) that the information may be outdated. If your security contact email changed six months ago but the file still shows the old one, you'll miss critical reports.
Set a calendar reminder to renew your security.txt before it expires — annually is a common cadence.
Should You Sign It with PGP?
RFC 9116 recommends signing your security.txt with PGP (as shown in the example above). This provides two benefits:
- Authenticity — Researchers can verify the file genuinely came from you, not a malicious actor who compromised your web server to redirect vulnerability reports.
- Integrity — The signature ensures the file hasn't been tampered with in transit.
For most organizations, signing is a worthwhile step, especially if you handle sensitive systems or operate a bug bounty program.
Setting Up Your Disclosure Policy
The Policy field links to a page that should explain:
- What's in scope (which systems, domains, and vulnerability types you accept reports for)
- What's out of scope (e.g., social engineering, physical attacks, denial of service)
- Your response timeline commitments (e.g., "We will acknowledge within 48 hours")
- Whether you offer rewards (bug bounty) or recognition (acknowledgments page)
- Legal safe harbor language protecting good-faith researchers
A clear policy reduces noise from invalid reports and sets expectations that attract serious, responsible researchers. security.txt is a small file with a big impact — implement it today and make your service more trustworthy for everyone.