A vulnerability report can lose value before triage begins if the reporter cannot identify a current, organization-controlled contact. RFC 9116 addresses that routing problem with security.txt, a machine-parsable text file published at a predictable HTTPS location.
The file does not grant testing permission, establish a bug bounty, or prove that a listed recipient is trustworthy. Its narrower role is to publish vulnerability disclosure metadata in a format that people and automated tools can retrieve consistently.
The canonical location is under /.well-known/
For a web service, RFC 9116 places the resource at:
https://example.com/.well-known/security.txtThe /.well-known/ location is normative. A top-level /security.txt can exist for legacy compatibility, but when both locations are present, the well-known resource takes precedence.
Retrieval uses HTTPS. The response is plain text encoded as UTF-8, with text/plain as its media type. Those constraints keep the format simple while placing transport integrity on the HTTPS connection.
Scope follows the domain name or IP address used to retrieve the file. A file obtained from example.com does not automatically apply to api.example.com, and a file on a subdomain does not automatically govern its parent. An organization can describe broader product or service scope through its disclosure policy, but the retrieval scope itself remains bounded.
Contact and Expires are the required operational fields
A valid file needs at least one Contact field. Its value is a URI, so an email contact uses mailto: rather than a bare address. Multiple Contact fields can express several reporting channels, listed in preference order.
RFC 9116 also requires Expires. The value is a date and time indicating when the file should no longer be treated as current. The specification recommends setting that timestamp to less than one year into the future.
A compact file can therefore look like this:
Contact: mailto:security@example.com
Expires: 2027-03-01T00:00:00Z
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policyCanonical identifies a URI at which the same file is intended to be authoritative. If a file contains Canonical fields but none matches the URI used to retrieve it, RFC 9116 says its contents should not be trusted.
Policy can point to a vulnerability disclosure policy with details that do not belong in the compact machine-readable file, such as testing boundaries, reporting expectations, or coordinated disclosure terms.
Optional fields carry process metadata
The format defines additional fields for common disclosure workflows. Encryption can point to a key or other material used to protect reports. Acknowledgments can link to a page recognizing reporters. Hiring can identify security-related employment information. Preferred-Languages can declare the natural languages in which an organization prefers to receive reports.
These fields do not replace the resources they reference. A Policy URI still needs a maintained policy behind it, and an Encryption URI still needs usable cryptographic material. Publishing a syntactically correct pointer to stale or inaccessible data leaves the reporting path operationally weak.
Field names are case-insensitive. Each field occupies its own line, and comments begin with #. The grammar is deliberately constrained so parsers do not need to infer structure from prose.
Expiry turns maintenance into part of the protocol
A security contact that silently becomes obsolete can route sensitive vulnerability details to an abandoned mailbox or an unrelated party. Expires makes staleness visible to a consumer rather than leaving freshness implicit.
The field does not refresh itself. Operators still need a maintenance process that checks the contact endpoint, policy page, encryption material, canonical URI, and expiration timestamp. A file that remains reachable after its expiry date is not equivalent to a current disclosure channel.
This also argues against treating publication as a one-time deployment task. The useful state is not merely “file exists”; it is “the current file points to current resources controlled by the intended organization.”
A compromised site can redirect the reporting path
security.txt is served by the same web infrastructure that an attacker may compromise. Control of the site can permit modification of the file or creation of a redirect toward attacker-controlled contact information.
RFC 9116 therefore treats authenticity as a separate concern. The Canonical field can help bind the content to an expected location, and the specification supports cleartext OpenPGP signatures for the file. Consumers still need to assess redirects and other signs of tampering rather than treating successful retrieval as proof of organizational control.
This boundary is especially important during incident response. A disclosure contact published by a compromised host may be one of the resources an intruder can alter. The specification is aimed at vulnerability response and cautions against relying on the mechanism as an incident-response trust anchor.
Publication does not authorize security testing
The presence of security.txt does not grant permission to scan, probe, exploit, or otherwise test a system. Its absence does not prohibit activity by itself either. Authorization comes from applicable policy, contract, program terms, or other legal and organizational controls.
That distinction keeps contact routing separate from testing scope. A Policy field can direct a reporter to explicit rules, but the machine-readable contact file is not a substitute for those rules.
The same separation applies to bug bounties. An organization can publish security.txt without offering compensation, and a bounty program can impose conditions beyond anything represented in the file.
Parsers need hostile-input assumptions
A public security.txt endpoint can return malformed or unexpectedly large input. RFC 9116 calls out defensive parsing and notes that implementations may impose limits such as refusing files larger than 32 KB, fields longer than 2,048 characters, or files containing more than 1,000 lines.
Those figures are implementation choices presented by the RFC, not validity limits in the file grammar. A robust consumer should also handle redirects deliberately, validate URI schemes and syntax, process UTF-8 correctly, and avoid turning referenced resources into unchecked fetch targets.
Machine readability reduces ambiguity only when parsing remains strict. Treating arbitrary text as trusted configuration would move risk from contact routing into the tooling that consumes it.
The useful property is predictable routing
security.txt does not secure an application and does not certify a disclosure program. It standardizes a small but consequential interface between a reporter and an organization: where a vulnerability report should go, when that routing data expires, and where supporting policy or encryption material is published.
Its security value depends on disciplined operation around that interface. HTTPS protects retrieval in transit, canonical locations reduce ambiguity, expiry exposes stale metadata, signatures can add an authenticity signal, and maintained policy links carry the human process that the compact file intentionally leaves elsewhere.