What Is security.txt?
security.txt is a proposed internet standard (defined in RFC 9116) that gives security researchers a standardized, easy-to-find way to report vulnerabilities they discover on your website. Rather than hunting through a site for a contact email or guessing whether security@yourdomain.com exists, researchers look in a single well-known location: https://yourdomain.com/.well-known/security.txt.
Think of it as a published vulnerability disclosure policy. It signals that your organization takes security seriously and has a clear, welcoming process for receiving reports — which in turn encourages more responsible disclosure instead of public exploits.
Why It Matters
- Faster vulnerability reporting — Researchers know exactly where to send reports without guesswork.
- Reduces noise — Clear contact and scope information filters out low-quality or out-of-scope reports.
- Demonstrates security maturity — Major organizations including Google, GitHub, and the UK National Cyber Security Centre publish security.txt files.
- Standardized format — Tools can automatically parse and act on the file.
The security.txt File Format
A security.txt file is a plain text file with specific fields. Here's an example:
Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2026-12-31T23:59: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, fr
Canonical: https://example.com/.well-known/security.txt
Field Reference
| Field | Required? | Description |
|---|---|---|
Contact | Yes | How to reach your security team. Can be email, URL, or phone. Multiple entries allowed. |
Expires | Yes | ISO 8601 datetime after which the file should be considered stale. Must be in the future. |
Encryption | No | Link to a PGP key for encrypted communications. |
Acknowledgments | No | URL to a page recognizing researchers who've responsibly disclosed issues. |
Policy | No | Link to your full vulnerability disclosure or bug bounty policy. |
Preferred-Languages | No | Languages your team can receive reports in. |
Canonical | No | The canonical URL of this file — useful if it's mirrored. |
Hiring | No | Link to your security team's job listings. |
Step-by-Step: Creating and Deploying security.txt
-
Draft your file. Use a text editor or the generator at securitytxt.org to create the file. Set the
Expiresfield to no more than one year in the future — you'll want to review and re-sign it annually. -
Sign it with PGP (recommended). RFC 9116 recommends signing the file with a PGP key to prevent tampering. Generate a signature and wrap the file content in a
-----BEGIN PGP SIGNED MESSAGE-----block. -
Place it at the correct path. The file must be hosted at
/.well-known/security.txt. Create a.well-knowndirectory in your web root and place the file there. -
Set the correct Content-Type. Serve it with
Content-Type: text/plain; charset=utf-8. Most web servers will do this automatically for.txtfiles. -
Verify it's accessible. Visit
https://yourdomain.com/.well-known/security.txtin a browser and confirm it loads. Run it through a validator — the securitytxt.org site offers one. -
Set a calendar reminder. Before the
Expiresdate, update and re-sign the file. An expired security.txt is treated as non-existent.
Nginx and Apache Configuration Notes
If your server blocks dotfiles or restricts the /.well-known/ path, you may need a small config change:
- Nginx: Ensure the
.well-knowndirectory is not blocked by a catch-all deny rule. A specificlocation /.well-known/block withallow all;resolves this. - Apache: If you have a
Deny from allon dotfiles, add a specific exception:<Files "security.txt"> Allow from all </Files>inside the.well-knowndirectory's config or.htaccess.
With just a few minutes of work, you'll have a professional, standards-compliant security disclosure channel — and signal clearly that your organization welcomes responsible security research.