security.txt

RFC 9116 defines a plain-text file at /.well-known/security.txt saying where to report a vulnerability in a domain. This check fetches it over HTTPS and grades what it finds: whether a file is there at all, whether it names a Contact, whether its mandatory Expires is present, singular, parseable and in the future, whether it is served as text/plain, and whether it sits at the path the RFC specifies.

Absence is graded as information rather than as a fault — the file is optional and most domains have none. What it buys is the difference between a researcher with a finding having one obvious place to look and having to guess, and guessing wrong ends either in a public disclosure or in nothing being reported at all.

Two details of how it is measured are worth knowing, because the obvious implementation gets both wrong. A 200 response is not a file: a catch-all route answers every unknown path with the site's own HTML, and trusting the status code reports a published security.txt for a large share of single-page applications, so the body has to parse as the format before it counts. And the evidence names the URL that answered rather than the one we asked for — if a redirect took the request to another host, the file found there belongs to whoever runs that host, so it is reported rather than graded as this domain's.

The legacy top-level /security.txt is asked for only when the well-known path found nothing. RFC 9116 §3 keeps it for compatibility but requires the well-known location, so a file found only at the top level is a warning: conformant tooling asks for the specified path, gets a 404, and concludes there is no reporting channel.

Publish a minimal file and grow it later. Contact and Expires are the whole requirement — a contact can be a mailto:, a tel: or the URL of a reporting form, and a form is the better choice if you would rather the address were not scraped.

Generate Expires rather than checking a date into the repository. RFC 9116 asks for less than a year out, and a fixed value is something a person has to remember. An expired file is worse than no file: it is still served, still found, and every tool that reads it treats the channel as abandoned.

Serve it as text/plain; charset=utf-8. The common bug is a static host guessing the content type from an extensionless path and sending text/html, which parsers honouring the header reject even though the file itself is perfect.

Put it at /.well-known/security.txt and redirect /security.txt there if you want the old URL to keep working. Policy, Preferred-Languages and Canonical are worth adding; an OpenPGP signature is optional and only useful if somebody would actually verify it.