↓ Skip to main content
Arkadii Yakovets

Not as well-known as it should be: shipping security.txt

Security··· 6 mins
#disclosure #policy #rfc #standards #well-known
Not as well-known as it should be: shipping security.txt
Table of Contents

security.txt has a branding problem. The file lives at a well-known URI, the format has been an IETF RFC since 2022 (RFC 9116), and big platforms already publish it -- yet plenty of high-traffic sites still do not. The gap is not complexity. It is attention.

There is a lot more we -- particularly me -- can do to promote the specification.

-- Ed Foudil, co-author of RFC 9116 with Y. Shafranovich

I care about this because I have been on both sides of the awkward moment: a researcher finds something worth reporting, and the owning project has no obvious, trustworthy channel. This post is the short version of what the standard is for, what shows up in the wild, a checklist I actually use, and the file this site now ships.

What problem it solves
#

Independent researchers often lack a reliable way to disclose vulnerabilities. Mailbox folklore (security@) helps when it exists and is monitored. It does not tell you the disclosure policy, the preferred language, or whether a web form is the right door. security.txt, created by Ed Foudil and Yakov Shafranovich, is a small machine- and human-readable file that publishes those pointers in one predictable place. Background reading: the Wikipedia overview and the RFC itself.

It does not replace a vulnerability disclosure process. It makes the front door findable.

Where it lives
#

RFC 8615 reserves /.well-known/ so site-wide metadata does not collide with arbitrary application paths. For websites, RFC 9116 says you must publish under /.well-known/security.txt over HTTPS as text/plain. For legacy compatibility, a file at /security.txt (or a redirect to the well-known path) is allowed. If both exist, the well-known one wins.

That dual-location rule shows up in production. GitHub uses the preferred path. HackerOne publishes at the site root -- an RFC-allowed non-preferred location, and a pattern some teams still choose for simplicity. Either can work; prefer well-known when you control the origin, and do not assume researchers will try both forever.

One more scope detail people miss: the file applies to the host used to retrieve it, not automatically to every subdomain or parent. Retail Amazon and AWS are a clean illustration -- amazon.com and aws.amazon.com are separate files with different depth. Put the file where researchers will actually look for that product.

What "good enough" contains
#

You do not need Microsoft's catalog on day one. You do need the required fields and honest URLs.

Must have (RFC 9116):

  • Contact -- at least one URI (https://, mailto:, or tel:)
  • Expires -- when the file should be treated as stale

Should strongly consider:

  • Canonical -- the HTTPS URL of this file
  • Policy -- even a short disclosure page beats a bare inbox
  • Preferred-Languages -- if you omit it, English is assumed

Optional when they earn their keep: Acknowledgments, Encryption, Hiring, OpenPGP cleartext signing.

A concrete starting point -- the file this site ships:

/.well-known/security.txt
Canonical: https://arkid15r.dev/.well-known/security.txt
Contact: mailto:ehlo@arkid15r.com
Expires: 2027-07-01T00:00:00.000Z
Preferred-Languages: en

Generators such as securitytxt.org are fine for a first draft. Treat the output as a commit you will maintain, not a one-off paste.

A light note on Expires
#

The field is mandatory. The RFC also recommends setting it less than a year ahead so the file does not silently rot. Plenty of serious sites choose multi-year dates anyway -- Google points at 2030; the BBC uses a memorable 2038 timestamp. That is their call. On this site I keep Expires inside roughly a year and plan to renew it. Missing the field entirely (still surprisingly common) is the worse failure mode.

What the wild looks like
#

Linking beats pasting. A few patterns worth opening in a tab. Observations below are as of this post's publication date -- re-check before you cite; this landscape moves.

ExamplePatternWhy it is useful
BBCMulti-year ExpiresValid file with a memorable far-future stamp (2038-01-19) -- beyond the RFC's less-than-a-year recommendation
BlueskyMissing ExpiresContact, Canonical, and acknowledgments -- but no mandatory Expires field
CiscoSigned + actionablePSIRT mailto, policy, encryption, canonical, OpenPGP signature -- signing is optional for a personal blog
DEF CONLanguage signalPreferred-Languages: en, zh, zh-gan -- English plus Mandarin and Gan Chinese, not the usual English-only default
GitHubPreferred path, richHackerOne contact, policy, hiring, canonical, and Expires at /.well-known/
GoogleMulti-year ExpiresShips the preferred path; Expires points at 2030 -- another case of stretching the freshness recommendation
HackerOneRoot locationAllowed fallback path
LinkedInMissing ExpiresPreferred path with HackerOne contact and policy -- but no mandatory Expires field (and still cites an old draft)
MicrosoftRich programPolicy, encryption, acknowledgments -- shows the ceiling
OWASPMinimal but validContact + Expires only; still better than silence
VictoriaMetricsSigned + multi-policyOpenPGP-signed file with mailto contact, encryption, hiring, and Policy links across Logs / Metrics / Traces
XStale ExpiresSigned file with HackerOne contact and encryption -- but Expires: 2024-01-01T06:00:00.000Z

Adoption is uneven, not absent. Apple, Cloudflare, Netflix, and many others ship a file. At the same time, quick checks still turn up gaps on destinations researchers actually use -- go.dev, ietf.org (the organization behind the RFC), python.org (while PyPI has one), and stackoverflow.com among them -- and on large consumer brands such as coca-cola.com, ebay.com, mcdonalds.com, and nike.com.

Two pitfalls that look like "we have a file" but are not:

  1. HTML at the path -- some large sites return a soft-404 or login shell with status 200. Researchers (and parsers) need text/plain with real fields.
  2. Informal field names -- a plaintext note that says Email: instead of Contact: may help a human and still fail tooling. Use the RFC names.

The judgment call is not "should this origin have a disclosure channel?" It is "can a stranger discover that channel in under a minute without tribal knowledge?" security.txt is how you answer yes.

A practical checklist
#

Use this when you add the file to a site or product origin:

  1. Create /.well-known/security.txt (HTTPS only).
  2. Add at least one Contact: URI you will actually read.
  3. Set Expires: (I aim for <= 1 year; renew on a calendar or in CI).
  4. Add Canonical: matching the URL you serve.
  5. Link Policy: if you have any disclosure page at all -- or write a short one.
  6. Set Preferred-Languages: to languages you can triage (see the DEF CON example above for a broader-than-English signal).
  7. Verify the response is 200, Content-Type: text/plain, and the body parses. A generator check on securitytxt.org is enough for most teams.
  8. Monitor expiry and accidental 404s the same way you monitor TLS -- because a stale contact is worse than no file.

Optional later: acknowledgments, encryption keys, hiring links, signing.

This site
#

This blog now ships the preferred location: /.well-known/security.txt. Contact is mailto:ehlo@arkid15r.com, Expires is within a year, Canonical matches the served URL, and preferred language is English. No bounty program and no formal safe harbor are implied -- just a clear place to write if you find something on this origin.

Bottom line
#

security.txt is a small affordance with an outsized failure mode when missing: good reports that never arrive. It is easy to overthink (signing, multi-year expiry philosophy) and easier to under-ship. Prefer the well-known path, publish honest contacts, keep Expires honest, link a policy when you can, and renew the file like any other production dependency.

After this post went up on August 8, 2026, CRAdrill published an August 14, 2026 scan of European software-vendor domains from europealternatives.com: of 492 reachable over HTTPS, 374 (76%) had no valid security.txt at /.well-known/security.txt.

References
#