Scanning & Methodology
security.txt: Set Up Vulnerability Disclosure the Right Way
security.txt is the standardized file that tells security researchers where to report vulnerabilities in your site — a five-minute setup that turns discovered weaknesses into responsible disclosures instead of public surprises.
<p>A security.txt file is a small, standardized text file at <code>/.well-known/security.txt</code> (RFC 9116) that tells security researchers who finds a vulnerability in your site exactly where and how to report it. Without one, a researcher who discovers a serious flaw has no obvious channel: they either give up, post it publicly, or report it to a random support inbox where it may rot unread. With one, you get a chance to fix issues before they become incidents — for the cost of five minutes of work.</p>
<h2>Why Every Site Should Have One</h2>
<p>Vulnerability disclosure is a numbers game you cannot opt out of. Your site will be scanned — by researchers, by bug bounty automation, by criminals doing recon — whether you invite it or not. The only variable is what happens to findings. A published security.txt signals that you will receive reports professionally, which keeps well-intentioned finders on your side and inside your timeline. Its absence pushes the same people toward public disclosure or, worse, silence while the bug is sold.</p>
<p>The file also removes ambiguity for legitimate testers. Our own <a href="https://2mny.com/free-security-scan">2MNY scanner</a> checks for security.txt presence because it is a market-recognized maturity signal — the same reason PCI DSS 4.0's requirement 12.5.2 expects a vulnerability disclosure process and the same logic behind the security.txt adoption by Google, GitHub, the BBC and countless government sites.</p>
<h2>Step 1: Create the File</h2>
<p>The minimal useful file has three fields:</p>
<pre><code>Contact: mailto:[email protected]
Expires: 2027-12-31T23:59:00.000Z
Policy: https://yourdomain.com/security-disclosure
</code></pre>
<p>Field meanings:</p>
<ul>
<li><strong>Contact</strong> (required) — where reports go. <code>mailto:</code> is most common; a URL to a form or a security contact page also works. Avoid a generic support address that triages slowly — disclosure reports decay fast.</li>
<li><strong>Expires</strong> (required) — when this file should be considered stale, in full ISO 8601. Set it 6-12 months out and calendar a renewal; an expired security.txt is a promise you stopped keeping.</li>
<li><strong>Policy</strong> (recommended) — link to a short page describing safe-harbor rules: what testers may test, what is out of scope, that good-faith research will not be pursued legally.</li>
<li><strong>Preferred-Languages</strong> (optional) — e.g. <code>en, bn</code> so reporters know what to write in.</li>
<li><strong>Canonical</strong> (optional) — the absolute URL of this security.txt, useful when mirrors exist.</li>
<li><strong>Encryption</strong> (optional) — a PGP key URL for sensitive reports.</li>
</ul>
<h2>Step 2: Publish It in Both Standard Locations</h2>
<p>Place the file at:</p>
<ol>
<li><code>https://yourdomain.com/.well-known/security.txt</code> (the RFC 9116 location)</li>
<li><code>https://yourdomain.com/security.txt</code> (the legacy location some tools still probe)</li>
</ol>
<p>Both should serve identical content with <code>Content-Type: text/plain</code> and a 200 status. Redirects are tolerated by the RFC but a direct 200 is friendlier to automated parsers — some tools follow at most one hop.</p>
<h2>Step 3: Make Sure the Contact Actually Works</h2>
<p>The most common failure mode is a published address nobody monitors. Wire it to a mailbox with multiple recipients and an acknowledgment autoresponder ("received — triage within 72 hours, status updates every 7 days"). A researcher who gets silence for two weeks assumes the worst and publishes. Set internal SLAs: acknowledge fast, triage within days, keep the reporter updated until fix and (if they wish) credit.</p>
<h2>Step 4: Write the Short Policy Page</h2>
<p>Keep it honest and short. State the scope (which domains and products), the priority you care about (authentication, stored XSS, RCE, data exposure), what you do not want (DoS testing, social engineering, physical attacks), and the safe-harbor sentence: good-faith research within scope will not face legal action. If you can reward reports, say so — even a small bounty or hall-of-fame listing changes reporter behavior dramatically.</p>
<h2>Frequently Asked Questions</h2>
<h3>Q: Does publishing security.txt invite attacks?</h3>
<p>A: It invites reports. Attackers scan you regardless; the file changes what happens after they find something. In practice a visible, working disclosure channel converts a share of hostile discoveries into private, fixable reports. It is also one of the cheapest trust signals you can publish — see how we handle <a href="https://2mny.com/kb/evidence-verified-findings">disclosure in our own scanning rules of engagement</a>.</p>
<h3>Q: Is security.txt required by any compliance framework?</h3>
<p>A: Not yet universally, but the direction is clear: PCI DSS 4.0 expects a vulnerability disclosure process (12.5.2), and security.txt is the standard machine-readable expression of one. Government CERTs increasingly recommend or reference it. Expect auditors to start asking within the next cycles.</p>
<h3>Q: Where must the file be located?</h3>
<p>A: RFC 9116 specifies <code>/.well-known/security.txt</code> with the <code>https://</code> scheme. A top-level <code>/security.txt</code> is a widely supported legacy location — publish both. The file must be reachable without authentication.</p>
<h3>Q: What if we cannot offer bounties?</h3>
<p>A: Acknowledgment works. A public hall of fame, a fast professional response and clear safe harbor retain most researchers; many report precisely because it is the right thing to do. What drives them away is silence and legal threats — not the absence of money.</p>