When a security researcher finds a vulnerability in your website, the hardest part is often not the finding — it's figuring out who to tell. security.txt, standardized in RFC 9116, solves this with a small text file at a well-known URL that states your security contact, how long the information is valid, and where your disclosure policy lives.
What Is security.txt?
security.txt is a plain-text file served over HTTPS at /.well-known/security.txt. It is both human- and machine-readable: researchers can open it in a browser, and automated scanners can parse it to find your preferred reporting channel. Think of it as robots.txt for vulnerability disclosure — a fixed, predictable place where security information is published.
Contact: mailto:security@example.com
Contact: https://example.com/report
Expires: 2027-01-15T00:00:00Z
Encryption: https://example.com/pgp-key.txt
Preferred-Languages: en, de
Policy: https://example.com/security-policy
Canonical: https://example.com/.well-known/security.txtWhere Must the File Live?
RFC 9116 requires the file at https://yourdomain/.well-known/security.txt, served as text/plain; charset=utf-8 over HTTPS. The root location /security.txt is permitted only as a legacy fallback — many scanners check the well-known path exclusively, so serving it only from the root effectively hides it from automated tooling.
The Fields Explained
| Field | Required? | Description |
|---|---|---|
Contact | Yes (1+) | How to reach you, as a URI: mailto:, https://, or tel:. A bare email address without mailto: violates the RFC. The first Contact listed is the preferred channel. |
Expires | Yes (exactly 1) | ISO 8601 date-time after which the file must be considered stale. The RFC recommends keeping it under a year away. |
Encryption | No | URL of your PGP public key so researchers can send encrypted reports. |
Acknowledgments | No | Link to your hall-of-fame page crediting researchers. |
Policy | No | Link to your vulnerability disclosure policy (scope, safe harbor, rewards). |
Preferred-Languages | No (max 1) | Comma-separated language tags reports can be written in, e.g. en, de. |
Hiring | No | Link to your security job openings. |
Canonical | No | The URI(s) where this file is officially published — should match the URL it is fetched from. |
Expires field is the most commonly botched part of security.txt. Once the date passes, conforming scanners and researchers must treat the whole file as stale — exactly as if it did not exist. Set a calendar reminder and re-issue the file before it expires.Why Publish One?
- Faster reports: researchers reach the right inbox on the first try instead of emailing
info@or guessing. - Fewer public disclosures: when no contact is findable, some researchers post findings publicly out of frustration.
- Compliance signals: security ratings services and some regulatory frameworks check for the file's presence.
- It costs nothing: a seven-line static file, deployable in minutes.
Signing the File
RFC 9116 recommends signing security.txt with a PGP cleartext signature. An attacker who compromises your web server could otherwise swap in their own contact address and quietly intercept vulnerability reports. Sign with the same key you publish under Encryption so researchers can verify the chain end to end. The guide How to Sign security.txt with PGP walks through generating the key with GnuPG, publishing it, and signing the file step by step.
Publishing and Verifying
- Generate the file with at least
ContactandExpires— the Security.txt Generator builds a valid one in seconds. - Serve it at
/.well-known/security.txtastext/plain; charset=utf-8over HTTPS. - Verify it with the Security.txt Tester, which fetches the live file and validates every field against RFC 9116.
- Re-issue it before the
Expiresdate, and immediately whenever a contact changes.
Frequently Asked Questions
Is security.txt mandatory?
No — it is a voluntary standard. But several governments (including the Netherlands and parts of the US federal government) mandate or strongly recommend it for their own agencies, and security ratings platforms increasingly score its presence.
Does publishing it invite more attacks?
No. Attackers do not need an invitation; researchers do need a contact. The file changes nothing about your attack surface — it only changes whether the person who finds a flaw can tell you about it.
Should the Contact be a personal address?
Use a role address (security@yourdomain) or a web form, not a person's mailbox. Personal addresses go stale when people change roles — and a stale contact defeats the whole purpose of the file.