After discussing CAA record in DNS to whitelist your certificate authorities in my previous article, do you know it’s a matter of time that someone finds an issue with your web-presence, website or any front-facing application? If they do, what do you expect them to do? Keep it under the wrap, or disclose it to you “responsibly”? This article is for you if you advocate the responsible disclosure; else, you have to do catch up with reality (I shall come back to you later!). Now, while we are on responsible disclosure, the “well-behaved” hackers or security researchers can either reach you via bug-bounty channels, your info@example email (not recommended), social media, or would be struggling to find a secure channel. But, what if you have a way to broadcast your “security channel” details to ease out their communication, and provide them with a well documented, managed and sought out conversation channel? Isn’t that cool? Voila, so what
robots.txt is to search engines,
security.txt is to security researchers!
I know you might be thinking, “…what if I have a page on my website which lists the security contacts?.” But, where would you host this page - under contact-us, security, information, about-us etc.? This is the very issue that security.txt evangelists are trying to solve - standardize the file, path and it’s presence as part of RFC 5785. As per their website,
Security.txt defines a standard to help organizations define the process for security researchers to disclose security vulnerabilities securely.
The project is still in early stages1, but is already receiving positive feedback from the security community, and big tech players like Google2 have incorporated it as well. In my opinion, it very well advocates that you take security seriously, and are ready to have an open conversation with the security community if they want to report a finding, vulnerability or a security issue with your website/ application. By all means, it sends a positive message!
Semantics/format of “security.txt”
As the security.txt follows a standard here are some points to consider,
security.txthas to be placed in
.well-knowndirectory under your domain parent directory, i.e. example.com/.well-known/security.txt
It documents the following fields,
Comments: The file can have information in the comment section that is optional. The comments shall begin with
Each separate field needs a new line to define and represent.
Contact: This field can be an email address, phone or a link to a page where a security researcher can contact you. This field is mandatory and MUST be available in the file. It should adhere to RFC39863 for the syntax of email, phone and URI (MUST be served over HTTPS). Possible examples are,
Contact: mailto:[email protected].
Encryption: This directive should link to your encryption key if you expect the researcher to encrypt the communication. It MUST NOT be the key, but a URI to the key-file.
Signature: If you want to show the file integrity, you can use this directive to link to the signature of the file. Each of the signature files must be named as
security.txt.sigand accessible at
Policy: You can use this directive to link to your “security policy”.
Acknowledgement: This derivative can be used to acknowledge the previous researchers, and findings. It should contain company and individual names.
Hiring: Wanna hire people? Then, this is the place you post.
security.txt extracted from Google,
Contact: https://g.co/vulnz Contact: mailto:[email protected] Encryption: https://services.google.com/corporate/publickey.txt Acknowledgement: https://bughunter.withgoogle.com/ Policy: https://g.co/vrp Hiring: https://g.co/SecurityPrivacyEngJobs
Hope this articles gives you an idea of implementing
security.txt file, and the very importance of it.