Visual RFC.
ALL RFCs / RFC 9116
Read the RFC ↗
RFC 9116 / SECURITY.TXT DISCLOSURE CONTACTS

Find the well-known file over HTTPS

01

A 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.

DIAGRAMRead RFC section 3 ↗
RFC 9116 · § 3EXAMPLE
3 / 3
Find the well-known file over HTTPSA researcher requests the specified well-known path at example.com over HTTPS. The second state shows an illustrative HTTP200 response with plain-text UTF-8 Content-Type and the two required field records. The final state compares coexisting legacy root and well-known files, selecting only the well-known one. The request retrieves reporting information; it does not send a vulnerability report. No fictional endpoint is actually contacted.Find where to report a vulnerabilityLegacy root fileWell-known file/security.txt/.well-known/security.txtMUST use if both existSelect the well-known copyDo not merge conflicting contact lists
03
Use the well-known copy when both exist.

The root /security.txt is a legacy location. If both locations have files, select /.well-known/security.txt; do not merge conflicting contacts.

Source for this drawing: RFC 9116 · Read RFC section 3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 8615 Well-known URIs RFC 9110 HTTP RFC 3986 URI syntax

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Well-known URL
A specified path at a host used to discover information about a service.
Media type
The HTTP Content-Type value that identifies the representation as plain text here.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Web services MUST place security.txt under /.well-known/. Access MUST use HTTPS and HTTP 1.0 or higher, with Content-Type text/plain and the default charset set to utf-8.

  • Web services MUST place security.txt under /.well-known/. Access MUST use HTTPS and HTTP 1.0 or higher, with Content-Type text/plain and the default charset set to utf-8.
  • For https://example.com, the specified URL is https://example.com/.well-known/security.txt. This is a file describing disclosure contacts, not a vulnerability scanner or report-submission endpoint.
  • The top-level /security.txt location can exist for legacy compatibility or redirect to the well-known location. If both files exist, the one under /.well-known/ MUST be used.
  • Redirects can occur when retrieving the file or referenced resources. Researchers should record and inspect redirects because a destination can be controlled by an attacker.
  • The file MUST be plain text, encoded as UTF-8 in Net-Unicode form. A web page formatted as HTML is not this file format. Validate the intended TLS endpoint before trusting the content.
DETAILS

All example.com URLs and security mailboxes are fictional documentation fixtures. No requests are sent to those contact or report URLs. HTTP headers in the drawing are an illustrative successful response, not a requirement for a particular HTTP version or transfer encoding. The guide teaches RFC 9116, not a change to this site’s own reporting policy.

Read the RFC section ↗

All chapters in RFC 9116

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗