A security flaw can be reported only if the person who finds it can locate a usable reporting route. When that route is buried in a support portal, points to an abandoned mailbox, or varies across domains, a valid report can be delayed or sent to the wrong place.
security.txt gives a web service a standard place to publish vulnerability-reporting contact details. The file is deliberately small. Its value comes from making the route predictable and keeping the route operational.
This article explains the trust boundary around security.txt, the minimum useful file, how to publish it according to RFC 9116, and the operational checks that keep it from becoming stale metadata.
Treat vulnerability intake as a security control
A vulnerability reporting channel does not fix a flaw. It reduces the time and ambiguity between discovery by an external party and receipt by the people who can assess the report.
The threat model has two parts.
First, a legitimate reporter may fail to reach the security team because the correct contact is hard to find, obsolete, or unclear. That can delay triage while the flaw remains present.
Second, an attacker who can alter the reporting instructions may redirect reports to an address they control. A compromised web service can often alter its own security.txt file too, so the file is not an independent proof that the site itself is trustworthy.
The control therefore has a limited job: publish a predictable, current route for vulnerability reports and make unexpected changes easier to detect. It does not authenticate a reporter, validate a report, contain an incident, or replace the organization’s response process.
Use the standard location and fields
RFC 9116 defines security.txt. For a web service, the standard location is:
https://example.com/.well-known/security.txtThe file is served over HTTPS as UTF-8 plain text. A compliant file requires at least one Contact field and exactly one Expires field.
A small example is enough for many services:
Contact: mailto:security@example.com
Expires: 2027-03-01T00:00:00Z
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/securityContact tells a reporter where to send a vulnerability report. It can appear more than once, and RFC 9116 treats the order as preference order.
Expires marks the time after which the published information is stale. This forces the publisher to make freshness explicit rather than leaving a contact file online indefinitely.
Canonical states the intended location of the file. If a Canonical field is present, the URI used to retrieve the file should match one of the listed canonical URIs. For a web URI, the field uses HTTPS.
Policy can point to a page that describes scope, expected report contents, response expectations, or other disclosure guidance. Keep that page practical. A long policy that hides the contact route defeats part of the purpose of the file.
RFC 9116 also defines optional fields such as Encryption and Preferred-Languages. Add them when the corresponding capability is real and maintained. Publishing an encryption key that nobody monitors or a language that the response team cannot support creates misleading expectations.
Separate discovery from the reporting system
It helps to view security.txt as a directory entry, not as the reporting system itself.
The file tells a reporter where to go. The destination may be a dedicated mailbox, an HTTPS form, or another maintained intake channel. That destination needs its own access controls, retention rules, spam handling, escalation path, and backup ownership.
For example, consider a company that publishes:
Contact: mailto:security@example.comIf that mailbox forwards to one employee’s personal queue, the public file can be perfectly valid while the operational control is fragile. Vacation, role changes, account suspension, or mailbox rules can interrupt intake.
A stronger design routes reports to a role-based channel with more than one trained owner. Access should still follow least privilege: the people who need to triage reports need access, but publishing the address does not justify broad internal access to sensitive report contents.
This separation also improves recovery. If the ticketing platform changes, the public contact can remain stable while internal routing changes behind it.
Keep sensitive reports out of ordinary support queues
Vulnerability reports can contain details that would be risky to expose widely: affected endpoints, reproduction notes, internal identifiers, screenshots, or information about a control that is failing.
A public reporting address is expected to receive untrusted input, but the resulting reports may still deserve restricted handling.
Route the channel into a queue with an explicit access policy. Avoid automatic reposting into broad chat rooms or general support systems unless those systems have suitable access controls. If attachments are accepted, process them as untrusted files and apply the same defensive controls used for other external uploads.
An Encryption field can advertise a URI for a key that reporters can use for encrypted communication. RFC 9116 requires this field to point to the key rather than embedding the key directly in the field. Encryption can reduce exposure while a report travels through systems outside your direct control, but it adds key-management and usability costs. Do not advertise it unless the team can maintain the key and handle encrypted submissions reliably.
For a small service with a well-controlled HTTPS reporting form, that form may be simpler than adding an encryption workflow. For a service that expects highly sensitive reports through email, a maintained encryption option can be useful defense in depth.
Make freshness an operational responsibility
The Expires field is not decoration. It creates a concrete maintenance deadline.
RFC 9116 recommends an expiry value less than a year in the future to reduce staleness. A shorter period can make sense when ownership or infrastructure changes frequently. The right renewal interval should fit the team’s ability to verify the full path, not just edit a timestamp.
Before extending the expiry, test the reporting route from outside the normal administrative environment:
- Fetch
/.well-known/security.txtover HTTPS. - Confirm the response is the intended plain-text file.
- Check that
Contact,Expires, and any other published fields still match reality. - Send a harmless test through the preferred contact route.
- Confirm the report reaches the expected restricted queue and can be acknowledged by the responsible team.
- Check that monitoring would detect an unexpected change to the file or its destination.
The fourth and fifth steps matter. A syntactically correct file does not prove that mail routing, form delivery, ticket creation, or on-call ownership still works.
Tie this check to a recurring operational process with an owner. If the person responsible for the domain changes roles, responsibility for the file and intake route should transfer explicitly.
Monitor the published file for tampering
HTTPS protects the connection between a client and the server under the assumptions of the web public-key infrastructure. It does not protect a security.txt file from an attacker who has gained authority to change the site’s served content.
RFC 9116 discusses this directly: a compromised site can publish a modified file or redirect a reporter elsewhere.
Monitor the file from outside the hosting environment and alert on unexpected content or destination changes. This does not stop modification, but it can shorten the time before the organization notices that reports may be misdirected.
The Canonical field gives consumers a location check. RFC 9116 also recommends an OpenPGP cleartext signature for the file. A signature can provide an additional authenticity signal if the signing key is managed separately enough to remain trustworthy during the failure being considered.
That last condition matters. If the same compromised deployment process can replace both the file and the signing key advertised by the site, the extra control may provide little independent assurance. Defense in depth is strongest when the layers do not fail from the same cause.
Scope each file deliberately
A security.txt file applies to the domain or IP address from which it is retrieved; RFC 9116 does not make a file on a parent domain automatically apply to every subdomain.
That affects organizations with many independently operated services. Publishing a file on example.com does not by itself establish the reporting route for api.example.com or shop.example.com.
You have two practical choices. Services can publish their own files with contacts appropriate to their owners, or deployment standards can publish consistent files across the relevant hosts. The second option is easier to audit centrally, but only if the listed contact really can route reports for every covered service.
Do not publish a broad contact merely to make scanning results look complete. A predictable route that cannot identify the responsible service owner still leaves triage work unresolved.
Avoid common publication failures
The most common failures are operational rather than complicated protocol mistakes.
A stale address is worse than it looks. Reporters see an official route and may reasonably assume someone is monitoring it. If the mailbox silently drops mail, the organization has created confidence without delivery.
An expiry date far in the future weakens the freshness mechanism. It reduces maintenance work by postponing the moment when anyone has to check the file, but that is exactly the check the field is meant to prompt.
A policy page that requires an account before showing contact details adds friction to a path intended for people outside the organization. If authentication is required for report submission, provide a contact alternative for reporters who cannot or should not create an account.
A generic customer-support address can be sufficient for a small organization if support staff have a tested escalation path and access is appropriate. A dedicated security mailbox is not automatically better. The deciding factor is whether a report can reach a responsible person promptly without unnecessary exposure.
Verify the whole path, not just the file
A useful security.txt deployment has two properties: discovery works, and intake works.
Validate discovery with an external fetch and a format check. Validate intake with a harmless end-to-end test. Review access to the receiving queue, confirm backup ownership, and monitor both the public file and the delivery path.
Then test a failure case. Temporarily route a test message through the same mechanisms used during staff absence or primary-owner unavailability. The goal is to expose single-person dependencies before a real report arrives.
Keep the control proportional to the service. A small site may need only a monitored role mailbox, a short policy page, and a regularly renewed file. A larger organization with many domains may justify centralized generation, external monitoring, signed files, encrypted intake, and automated checks for coverage.
The useful invariant is simple: a person who finds a vulnerability should be able to discover a current reporting route, and that route should deliver the report to people prepared to handle it. security.txt makes the first part predictable. Operational ownership makes the second part real.