Visual RFC.
ALL RFCs / RFC 9116
Read the RFC ↗

RFC 9116 / START HERE

security.txt, before the details

security.txt is a filename, not an acronym. RFC 9116 defines its format and discovery location.

It is a small plain-text file that helps a researcher find an organization’s vulnerability-reporting contacts and disclosure policy. The organization publishes field lines such as Contact and Expires at a predictable HTTPS address.

The idea in one picture

  1. Find HTTPS file

  2. Check fields + trust

  3. Read contact + policy

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

A guessed security email address does not explain which reporting channels an organization prefers or how its disclosure process works. This file makes that information discoverable and machine-readable. It complements other disclosure resources; it is not a scanner, report-delivery protocol or permission to test. RFC 9116 is Informational, published April 2022, with no formal updates or obsoletions in the checked metadata.

A familiar example

A researcher looks up https://example.com/.well-known/security.txt, checks its format, freshness, host scope and trust, then follows the listed contact and policy. If the information is stale or suspicious, they should not send a sensitive report using it. All contacts here are fictional; the guide neither submits reports nor grants testing permission.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Find the well-known file over HTTPSA researcher needs a way to reach the organization about a vulnerability. For a web service, security.txt puts machine-readable contact information at a predictable URL, rather than requiring a guess at an email address.
  2. Parse field lines and required informationThe file is a sequence of named fields. Each field has a name, a colon, a space and a value on its own line. A parser checks the format before it treats the content as reporting information.
  3. Choose contacts and read optional guidanceContact values are URIs: addresses with a scheme such as mailto:, tel: or https:. Several Contact lines can offer alternatives, while other fields provide policy, language and acknowledgment links.
  4. Check expiry before using contactsContact details can go out of date. Expires gives an RFC 3339 date and time after which the file’s information is stale and should not be used. It is not a guarantee that an address was safe or current before that time.
  5. Respect host scope and Canonical locationsA file retrieved for one host does not automatically cover related hosts. The optional Canonical field lists intended retrieval URIs and can help detect a copied or misplaced file, but does not by itself establish trust in every listed location.
  6. Separate signing, encryption and permissionThree different questions remain: who vouches for this file, how to protect a report in transit, and what testing the organization allows. A security.txt file does not answer all three just by existing.
Start with chapter one →

This introduction explains RFC 9116 (2022). Read the original RFC ↗