A security flaw can be difficult to report even when the affected service is easy to identify. A generic support form may route the message to the wrong queue, an old security mailbox may no longer be staffed, and a researcher cannot safely infer disclosure policy from a company name alone. RFC 9116 addresses that routing problem with security.txt, a small machine-parsable file published by the service operator.
The file does not certify that a service is secure, authorize testing, or define a complete vulnerability disclosure program. Its narrower job is to publish current reporting coordinates and related metadata at a predictable location.
The well-known path is the primary location
For a web service, RFC 9116 places the file at:
https://example.com/.well-known/security.txtHTTPS is required for retrieval. The response uses text/plain and UTF-8. A top-level /security.txt location can exist for legacy compatibility, but when both locations are present, the file under /.well-known/ takes precedence.
This predictable path removes a discovery step from vulnerability reporting. A person or automated client can request the same relative path on the affected host rather than searching site navigation for a security page.
The location also sets an important boundary. A file applies to the domain name or IP address from which it was retrieved; it does not automatically extend to parent domains or subdomains. An organization with several independently operated hosts may therefore publish separate files where reporting routes or policies differ.
Contact and Expires form the required core
Two fields carry the minimum operational contract: Contact and Expires.
Contact provides a URI for submitting a vulnerability report. It can appear more than once, and repeated entries are ordered by preference. An email address uses a mailto: URI rather than a bare address. A reporting portal uses an HTTPS URI.
For example:
Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2026-12-31T23:59:59ZExpires is present exactly once. Its RFC 3339 timestamp marks the point after which the published data is stale and should no longer be used. RFC 9116 recommends setting that date less than a year into the future. The field turns maintenance into part of the format: a forgotten contact file is not supposed to remain credible indefinitely.
Expiration does not prove that a mailbox is monitored before the timestamp. Operators still need to test the reporting route and keep referenced resources available. The timestamp only gives consumers a defined freshness boundary.
Optional fields add routing and policy context
Several optional fields can make the reporting route more useful without turning the file into a full policy document.
Policy links to the organization’s vulnerability disclosure policy. That page can carry details that do not belong in a compact machine-readable file, such as scope, reporting expectations, or program-specific conditions.
Encryption points to material that can be used to protect a report in transit beyond the HTTPS retrieval of the file itself. Publishing a key reference is not enough to establish trust in that key; the reporter still needs an appropriate basis for accepting its authenticity.
Preferred-Languages lists languages suitable for reports. Acknowledgments can point to a page recognizing reporters, while Hiring can point to security-related positions.
Canonical identifies canonical HTTPS locations for the file. When a Canonical field is present and the URI used to retrieve the file is absent from all such fields, RFC 9116 says the contents should not be trusted. The field is especially useful alongside a digital signature because it helps bind signed content to an intended publication location.
A valid file is not automatically trustworthy
The syntax is deliberately simple, but syntactic validity and trustworthy routing are separate properties.
If an attacker controls a website, the attacker may also be able to replace its security.txt, alter a redirect, or point a reporter at infrastructure under attacker control. RFC 9116 therefore discusses digital signatures, canonical locations, historical observations, and out-of-band checks as mechanisms that can support stronger confidence.
Redirects deserve similar care. Retrieval of the file or a URI referenced by one of its fields can redirect elsewhere. A client should not treat a cross-origin destination as harmless merely because the first request used the expected host.
These limits are significant during an active compromise. security.txt is designed primarily for vulnerability response, not as an authenticated incident-response command channel. A compromised origin can undermine the very routing data hosted on that origin.
Signing adds evidence, not universal trust
RFC 9116 recommends an OpenPGP cleartext signature for the file. A valid signature can show that the signed bytes match the holder of a particular signing key, but signature verification alone does not establish that the key belongs to the organization.
Key authenticity remains a separate decision. That distinction prevents a circular trust model in which an attacker replaces both the file and an unauthenticated key reference, then relies on the resulting signature as proof of legitimacy.
The Canonical field also has a bounded role. It states intended locations, but listing several canonical URIs does not make every listed location authoritative merely because one copy names them. Additional trust mechanisms remain relevant when a consumer needs stronger assurance.
Publication needs operational maintenance
A useful deployment is short enough to audit and specific enough to route a report without guesswork. A minimal file can contain one monitored contact and one expiration timestamp. Optional fields should be added when they point to resources the organization actually maintains.
Operational checks should cover more than HTTP status. The published contact route should accept reports, the policy URI should remain controlled by the organization, the expiration date should be renewed deliberately, redirects should stay expected, and any signing material should follow the organization’s key-management process.
Parsers also need defensive limits. RFC 9116 notes that malicious or compromised sites can publish unusually large or malformed files. A client that consumes security.txt should treat it as untrusted network input rather than assuming that a standardized format is benign.
The useful security property is modest but concrete: security.txt gives vulnerability reporters a predictable, time-bounded route to the party responsible for receiving a report. It reduces ambiguity at the first handoff while leaving authorization, triage, remediation, and broader disclosure policy to the systems and people responsible for those decisions.