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