Security.txt Adoption and Frequent Implementation Mistakes

In April 2022, an effort was made to enhance cybersecurity by introducing RFC9116. This standard introduces a well-organized file format, simplifying security vulnerability reporting by placing a text file in the /.well-known/ folder of a domain. The goal? To tackle a pervasive issue: the difficulty security researchers face in finding the right channels to report vulnerabilities, which too often results in unreported risks.

Dedicated to enhancing internet security, we've launched an extensive project with a three-pronged approach: evaluating the adoption rate, developing a free tool for RFC compliance testing, and pinpointing common implementation mistakes. Among the top one million internet domains, we discovered that 0.7% (6816 domains) have embraced the security.txt file. Strikingly, just 19% of these domains pass RFC compliance!

Key findings in our analysis include:

  1. Contact Information: The "Contact" field allows different URIs. Our data shows 67% use email, 31% a URL, and a rare 2% list a telephone number.
  2. Expiration Date: The required "Expires" field signals when the security.txt data becomes obsolete. Alarmingly, 46% didn't specify this field, with 4% showing invalid values, 18% already expired, 0.3% expiring within a week, and 23% setting an overly distant expiration date, contrary to RFC recommendations.
  3. Encryption: 32% of security.txt files include an encryption key, which is vital for secure communication. This key must be represented as a URI leading to its location. 92% use https, 4% use openpgp4fpr, and 0.4% relies on dns. The rest either contains invalid values or, contrary to explicit guidelines, the key itself.
  4. Digital Signature: A mere 10% have added an OpenPGP signature, as advised in Section 2.3 of RFC9116, to enhance the file's authenticity. We were able to successfully validate 40% of all signed files using a key published in an Encryption field.
  5. Acknowledgments vs Acknowledgements: A minor yet notable discrepancy - while both are grammatically correct, the RFC uses "Acknowledgments", 12% of the files opt for "Acknowledgements". Even industry giants like Google have made this oversight.
  6. Content-Type Compliance: Surprisingly, 3% of the domains serve the security.txt file in a format other than the prescribed text/plain.
  7. Line Separator Standard: A critical formatting requirement is that each line must end with specific characters. However, 31% of the files neglect this rule, potentially causing parsing errors.
  8. Canonical URL Alignment: For 29% of the files specifying a "Canonical" field, a mismatch with the URL from which the file was retrieved was noted, leading to potential confusion.
  9. Duplicate and Unknown fields: We found minor issues like duplicate (Expires and Preferred-Languages) fields at five domains, and 10% of files contained unknown or invalid fields.

This extensive review underlines the ongoing journey towards a universally secure and reliable internet. It showcases the progress and the areas where more attention is needed to uphold cybersecurity standards.

📝
Verify security.txt files easily on our URIports Tools page.

URIports automatically detects if monitored domains publish a security.txt file, checks for errors, and notifies administrators for quick issue resolution.