↓Skip to main content

Vulnerability Disclosure: security.txt

··656 words·4 mins
Kaan S. Karadag
Author
Kaan S. Karadag
Founder & Lead Cyber Security Consultant | CISSP | CEH | ECIH
Table of Contents

Introduction
#

Most security professionals are familiar with robots.txt, but fewer understand the emerging standard known as security.txt and its potential impact on vulnerability disclosure processes. This article examines this proposed standard and its practical applications for organizations seeking to streamline security communication channels.

The Vulnerability Disclosure Challenge
#

Security researchers frequently encounter obstacles when attempting to report vulnerabilities to organizations, particularly when the affected applications or systems are not covered by formal bug bounty programs. Critical questions emerge:

  1. Who is the appropriate security contact?
  2. What is the preferred communication channel?
  3. What information should be included in the disclosure?

Without clear answers, researchers often abandon disclosure attempts entirely, leaving vulnerabilities unremediated and organizations exposed to potential exploitation.

The security.txt Solution
#

Concept and Purpose
#

The security.txt standard provides a simple, standardized approach to this problem. Similar to robots.txt, it establishes a consistent location where security researchers can find essential information for responsible vulnerability disclosure.

This file contains structured metadata about:

  • Security contact information
  • Communication preferences
  • Disclosure policies
  • Encryption keys for secure communication

Standards Status
#

Note: As of the original writing of this article, security.txt had been submitted for RFC review as an Internet Draft. The standard has since progressed in the standardization process.

Implementation Details
#

Internet Draft Specifications
#

Below is an example of the Internet Draft specifications for the security.txt format:

security.txt Internet Draft specifications

Real-World Implementation
#

Google’s implementation demonstrates how major organizations are adopting this standard:

Google’s security.txt implementation

Location Standardization: The .well-known Directory
#

The .well-known directory seen in these examples is specified in RFC5785, which establishes:

It is increasingly common for Web-based protocols to require the discovery of policy or other information about a host (“site-wide metadata”) before making a request. For example, the Robots Exclusion Protocol http://www.robotstxt.org/ specifies a way for automated processes to obtain permission to access resources; likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user-agents how to discover privacy policy beforehand.

While there are several ways to access per-resource metadata (e.g., HTTP headers, WebDAV’s PROPFIND [RFC4918]), the perceived overhead (either in terms of client-perceived latency and/or deployment difficulties) associated with them often precludes their use in these scenarios.

When this happens, it is common to designate a “well-known location” for such data, so that it can be easily located. However, this approach has the drawback of risking collisions, both with other such designated “well-known locations” and with pre-existing resources.

To address this, this memo defines a path prefix in HTTP(S) URIs for these “well-known locations”, /.well-known/. Future specifications that need to define a resource for such site-wide metadata can register their use to avoid collisions and minimise impingement upon sites’ URI space.

Implementation Best Practices
#

When implementing security.txt for your organization, consider these best practices:

  1. Placement - Deploy at both /.well-known/security.txt and /security.txt (the latter with a redirect to the standardized location)
  2. Contact Information - Include multiple contact methods (email, phone, web form)
  3. PGP Key - Provide encryption options for secure communication
  4. Acknowledgment Policy - Clearly state if/how you acknowledge researchers
  5. Scope Definition - Specify which systems are in/out of scope
  6. Response Timeframe - Set expectations for initial response and resolution

Benefits to Organizations
#

Implementing security.txt offers several advantages:

  1. Streamlined Communication - Reduces friction in the disclosure process
  2. Increased Disclosures - More researchers will report issues when the process is clear
  3. Reputation Enhancement - Demonstrates security maturity and researcher-friendliness
  4. Standardization - Aligns with emerging industry best practices
  5. Minimal Implementation Effort - Simple text file with substantial security benefits

Conclusion
#

The security.txt standard represents an elegant solution to a persistent challenge in vulnerability disclosure. While not a replacement for comprehensive bug bounty programs, it serves as a valuable complementary tool that enhances the vulnerability disclosure process for both security researchers and organizations.

By implementing this standard, organizations demonstrate their commitment to security and establish clear channels for receiving critical security information from the research community.

References
#