Glossary
security.txt
security.txt is a plain text file published at `/.well-known/security.txt` that tells anyone who finds a security problem in a site how to report it. It is defined by RFC 9116 and solves a small, real problem: someone with a finding and no obvious contact address usually gives up, and the organisation never learns. The file is a few lines, and one of its fields — an expiry date — is mandatory so that stale contact information is visibly stale.
The fields
`Contact` is required and may appear several times: a `mailto:` address, a `tel:` number, or an `https:` URL of a reporting form. Order expresses preference.
`Expires` is required: a timestamp after which the file should no longer be trusted. A date in the past makes the file formally invalid, which is the intended behaviour.
`Encryption` points at a public key for sending an encrypted report.
`Policy` links to a disclosure policy stating what a reporter can expect.
`Preferred-Languages`, `Acknowledgments` and `Hiring` are optional and self-explanatory.
`Canonical` states the URI the file is meant to be served from, which lets a reader detect a copy republished elsewhere as if it were yours.
Where it belongs
`/.well-known/security.txt` is the canonical location. A copy at `/security.txt` is permitted as a legacy fallback and is not the primary.
It must be served over HTTPS, since contact details that can be altered in transit are worse than none.
It applies per host. A reporting address for a whole organisation still needs the file on each host it should cover.
The file should be plain text with an appropriate content type; a server returning HTML for the path defeats automated readers.
Why Expires is mandatory
Contact details rot. A named individual leaves, an address is retired, a form moves, and the file continues to publish an instruction nobody receives.
A required expiry makes the rot visible: a reader can tell whether the information is maintained.
The specification recommends a value less than a year in the future, which forces a periodic review.
An expired file is a finding in its own right, and it is the most common defect in files that exist at all.
What publishing one commits you to
Reading what arrives. A contact address that is never monitored is worse than none, because it consumes the reporter's effort and then nothing happens.
Not the details of a bounty programme, which the file does not require and which a `Policy` link can set out separately.
Expect low-quality reports: automated scanner output forwarded without review is common, and a policy page stating what is in scope reduces it.
Check it with `curl https://example.com/.well-known/security.txt`, and read the `Expires` value before anything else.
The file may be signed with an OpenPGP clear-text signature, which lets a reporter verify it was not altered in transit. This is optional and rare, and it matters most for organisations where the contact address itself is a target.
Frequently asked questions
- Where should security.txt be placed?
- At /.well-known/security.txt, served over HTTPS. A copy at /security.txt is a permitted legacy fallback, not the primary location.
- Why does security.txt need an expiry date?
- So that stale contact information is visibly stale. An expired file is formally invalid, which forces periodic review.
- Does publishing one commit me to a bug bounty?
- No. It publishes a contact address. Any commitments belong in the policy the file may link to.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website