You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
security.txt tells a researcher where to report a vulnerability, but says nothing about whether they are legally safe to find one. The largest source of friction in vulnerability disclosure today is not "who do I contact," it is "will I be sued or prosecuted for good-faith testing."
RFC 9116 has no machine-readable signal for legal safe harbor. A researcher who finds an issue has to locate the org's disclosure policy (if Policy is even present), read the prose, and guess whether good-faith research is authorized. Many walk away rather than risk action under the US CFAA, the UK Computer Misuse Act, the Dutch Wet computercriminaliteit, or equivalents. The result is unreported vulnerabilities and exactly the chilling effect security.txt was meant to reduce.
The existing Policy field does not solve this. It is an opaque link to free-form text, not a distinct, detectable assertion that safe harbor exists. Neither a human skimming the file nor an automated crawler can tell at a glance whether an org offers legal protection.
Describe the solution you'd like
Add an optional Safe-Harbor field whose value is a URI pointing to the organization's safe harbor statement, consistent with how Policy, Encryption, and Acknowledgments already use URIs.
In a single machine-readable line this signals that the organization authorizes good-faith security research and will not pursue legal action against researchers who follow its policy. Tooling (scanners, browser extensions, disclosure platforms) can then surface "this target offers safe harbor" to researchers, the same way they surface a missing or expired Expires today.
Optionally, the field could carry a controlled keyword so the level is machine-classifiable at a glance, aligned with the widely used disclose.io taxonomy:
Safe-Harbor: full https://example.com/safe-harbor
where the keyword is one of full, partial, or none, followed by the URI. The plain URI form without a keyword should remain valid.
Describe alternatives you've considered
Rely on the existing Policy field. Rejected: Policy is a single opaque link to prose, neither guaranteed to address safe harbor nor machine-detectable as doing so. An org can have a policy with no legal protection at all.
A keyword-only field with no URI (e.g. Safe-Harbor: full). Simpler, but loses the link to the binding legal text researchers actually need. The combined keyword + URI form keeps both.
Encode safe harbor inside a Scope field (Scope field #213). Rejected: scope is about which assets may be tested, safe harbor is about legal protection for testing them. They are orthogonal and should not be conflated.
Do nothing and leave it to bug bounty platforms. Rejected: that only covers orgs already on a platform. security.txt's value is precisely the long tail that has no platform.
Additional context
The disclose.io project already maintains standardized Safe Harbor language and a full / partial / none taxonomy this field could reference directly.
In May 2022 the US DOJ revised its CFAA charging policy to state that good-faith security research should not be charged. A Safe-Harbor field gives orgs a place to make their own authorization explicit on top of that.
Coordinated vulnerability disclosure is increasingly expected under EU NIS2 and national CVD frameworks, so demand for an explicit, standardized legal signal is rising.
Is your feature request related to a problem? Please describe.
security.txt tells a researcher where to report a vulnerability, but says nothing about whether they are legally safe to find one. The largest source of friction in vulnerability disclosure today is not "who do I contact," it is "will I be sued or prosecuted for good-faith testing."
RFC 9116 has no machine-readable signal for legal safe harbor. A researcher who finds an issue has to locate the org's disclosure policy (if
Policyis even present), read the prose, and guess whether good-faith research is authorized. Many walk away rather than risk action under the US CFAA, the UK Computer Misuse Act, the Dutch Wet computercriminaliteit, or equivalents. The result is unreported vulnerabilities and exactly the chilling effect security.txt was meant to reduce.The existing
Policyfield does not solve this. It is an opaque link to free-form text, not a distinct, detectable assertion that safe harbor exists. Neither a human skimming the file nor an automated crawler can tell at a glance whether an org offers legal protection.Describe the solution you'd like
Add an optional
Safe-Harborfield whose value is a URI pointing to the organization's safe harbor statement, consistent with howPolicy,Encryption, andAcknowledgmentsalready use URIs.Example:
In a single machine-readable line this signals that the organization authorizes good-faith security research and will not pursue legal action against researchers who follow its policy. Tooling (scanners, browser extensions, disclosure platforms) can then surface "this target offers safe harbor" to researchers, the same way they surface a missing or expired
Expirestoday.Optionally, the field could carry a controlled keyword so the level is machine-classifiable at a glance, aligned with the widely used disclose.io taxonomy:
where the keyword is one of
full,partial, ornone, followed by the URI. The plain URI form without a keyword should remain valid.Describe alternatives you've considered
Policyfield. Rejected:Policyis a single opaque link to prose, neither guaranteed to address safe harbor nor machine-detectable as doing so. An org can have a policy with no legal protection at all.Safe-Harbor: full). Simpler, but loses the link to the binding legal text researchers actually need. The combined keyword + URI form keeps both.Additional context
full/partial/nonetaxonomy this field could reference directly.Safe-Harborfield gives orgs a place to make their own authorization explicit on top of that.