Implement "security.txt" to advocate responsible vuln. disclosures

Following on from my previous article on restricting your Certificate Authorities with a CAA DNS record: it’s only a matter of time before someone finds a flaw in your website or a front-facing application. When they do, what do you want them to do - sit on it, or disclose it to you responsibly? This one’s for you if you believe in responsible disclosure (if you don’t, you’ve some catching up to do - more on that another time). A well-meaning researcher might reach you through a bug-bounty platform, your info@example inbox (please don’t), social media, or by hunting fruitlessly for a secure channel. But what if you could simply advertise your security contact - a documented, managed, dedicated channel for these conversations? That’s exactly the idea: what robots.txt is to search engines, security.txt is to security researchers.

You might be thinking, “…but I already have a page listing my security contacts.” Fair - except where do you host it? Under contact-us, security, information, about-us? That inconsistency is exactly what the security.txt project sets out to fix: standardising the file, its path, and its presence, building on RFC 5785. As their site puts it:

Security.txt defines a standard to help organizations define the process for security researchers to disclose security vulnerabilities securely.

The project is still early¹, but it’s already drawing positive feedback from the community, and big players like Google² have adopted it. To me, publishing one is a clear signal that you take security seriously and welcome an open conversation when someone wants to report a finding or vulnerability. It sends a genuinely positive message.

Format and fields#

Since security.txt follows a standard, a few things to keep in mind:

• Place security.txt in the .well-known directory at your domain root - i.e. example.com/.well-known/security.txt.
• Each field goes on its own line.

The supported fields:

• Comments - optional; comment lines begin with #.
• Contact (mandatory) - an email, phone number, or a page where a researcher can reach you. It must follow RFC 3986³ for email, phone, and URI syntax, and any URL must be served over HTTPS. For example: Contact: mailto:security@example.com Contact: tel:+1-201-555-0123 Contact: https://example.com/security-contact.html
• Encryption - a link to your encryption key if you expect researchers to encrypt their reports. This must be a URI to the key, not the key itself.
• Signature - a link to the file’s signature if you want to prove integrity; each signature file should be named security.txt.sig and served from /.well-known/.
• Policy - a link to your security policy.
• Acknowledgement - credit previous researchers and findings, with company and individual names.
• Hiring - hiring? This is where you advertise it.

Here’s a reference security.txt, taken from Google:

Contact: https://g.co/vulnz
Contact: mailto:security@google.com
Encryption: https://services.google.com/corporate/publickey.txt
Acknowledgement: https://bughunter.withgoogle.com/
Policy: https://g.co/vrp
Hiring: https://g.co/SecurityPrivacyEngJobs

Hopefully that gives you a clear picture of how to implement a security.txt - and why it’s worth doing.

Stay safe!