Having a security.txt in the root (/) folder of your website has long been a good practice. The contents of the file has been very free. What started out as a novel and great idea, is now an RFC. Let’s look a bit closer.
So what is RFC9116?
RFC9116 now defines a more strucrured and standardized way of writing the needful. The essence of the security.txt concept is to provide a way for security researchers to contact you in security related matters. Although the idea was born out of bug bounty contact points, every organization should equip their website with a security.txt file. And of course, every organization should have at least security@ email-address defined – and monitored.
The RFC can be downloaded from here: https://www.ietf.org/rfc/rfc9116.pdf
How do I generate a security.txt
This is the simple part really. There is a tool located at https://securitytxt.org/ that can be used for this. So in reality, you do not even have to read the RFC to get started.
Where do I put the file?
As said before, the correct location of the files is either of the following
./well-known/security.txt
/security.txt
What if you have several domains, servers and places where the file would be relevant? My suggestion is to put this as far front as possible. That usually means a load balancer of some sorts.
Let’s have a look at implementing this using pfSense and HAProxy.
Once you have generated your security.txt, paste it into the above very simplistic lua script. The script is used as a resource in your HAproxy configuration.
Next, create an ACL for catching every request to /security.txt. Note that this should preferably be put in such a place in your configuration, that it catches ALL the relevant domains you want to cover.
Finally, create an action that triggers on the ACL. The action points to the lua-script.