Security.txt: publishing a security policy for your websites

Having discovered security vulnerabilities, researcher often struggle to report these vulnerabilities properly because of missing contact information. This can result in serious delays and may even leave vulnerabilities unreported.

Security.txt as described in RFC #9116 is a small machine-parsable file that helps organisations publish contact information and describe their disclosure practices to make it easier for researchers to report vulnerabilities. The file is both simplistic and elegant at the same time, because it has no other dependencies so side effects cannot occur, and it can be set up easily, so there is basically no reason not to implement it right away. You are right: I mean now!

So let us look into a basic example to get started:

Contact: mailto:secops@threatint.com
Expires: 2022-09-30T12:00:00.000Z
Preferred-Languages: en
Policy: https://www.threatint.com/en/about/coordinated-disclosure


The most important information is of course Contact, which is a required field and in our case contains an email address as a single point of contact. Kindly note that the value is a URL, so we need to explicitly state mailto: for an email address.
Expires is also a required field. This is the date and time (ISO 8601) when the content of the security.txt file should be considered stale. As stated in the RFC, it is RECOMMENDED that the value of this field be less than a year into the future to avoid staleness, so the basic idea is to have an organisation review the file on a regular basis. All other fields described on securitytxt.org or in the RFC, e.g. Preferred-Language or Policy, are optional.

We are now ready to make this file available on our website under /.well-known/security.txt. That’s it! Security Researchers are now able to find a single point of contact for security vulnerabilities at a well known location on your website.

If you run multiple websites, web applications or web services located behind a load balancer that supports custom rules, e.g. Amazon AWS EC2 ALB, it is a good idea to put a rule at the top to allow access to ~/.well-known/security.txt and /security.txt no matter what the site name was. This ensures that the security.txt file is available on each and every site and only needs to be maintained at one central location. It is also a good idea to put your security.txt under version control to track changes over time. If the file is used for more than one site it is reasonable to allow it to have its own repository.

References