Security.txt

Security.txt is a standardised text file containing information about how to report security issues with a website, which is published at a standard location: /.well-known/security.txt. The standard has been defined by Internet Engineering Task Force as RFC 9116.

Before security.txt, a security investigator who discovered a vulnerability on a website had to hunt around to find out how to alert the site’s operator. That often led to issue reporting delays and reports going to the wrong place. With security.txt, there’s a single, clearly signposted route for vulnerability reporting.

The standard is managed by the Internet Engineering Task Force (IETF). It’s formally specified in RFC 9116, published via the RFC Editor.

More and more public and private sector organisations are using security.txt. In the Netherlands, the standard has been on the 'use-or-explain' list maintained by the Forum for Standardisation since May 2023. All government organisations must therefore publish valid security.txt files. Up-to-data information about the percentage of .nl domain names with valid securty.txt files is available from stats.sidnlabs.nl.

Security.txt has to be published at a standard location within the domain: /.well-known/security.txt

Your file must include at least a Contact field and an Expires field. The Contact field tells people how to make a report, e.g. by e-mail at a URL. The Expires field gives the file’s expiry date. Without those fields, your file doesn’t conform to the standard.

Optional fields include Policy, Acknowledgments, Encryption and Hiring. Those are for signposting your responsible disclosure policy, an acknowledgements page and a public key for encrypted communications. For a full list of possible fields, see RFC 9116.

Security.txt must be a plain text file in UTF-8. Each line consists of a field name and a value, separated by a colon. The date in the Expires field must be ISO 8601 format, expressed in UTC.

Basically, you need to put a text file at a particular location on your web server. Plug-ins are available for many content management systems, including WordPress, which simplify the file generation process. For example, the Registrars' Association has developed a WordPress plug-in.

In most cases, no. If you’ve got access to the web root or you’re able to create a directory called .well-known, all you have to do is put a text file there. The file must be publicly accessible, and must have the correct content type header.

Use a browser to see whether the file is available at https://example.nl/.well-known/security.txt. You can also use an online validation tool. For example, the URIports security.txt validator lets you check that your file is correctly formatted and in the right place.

Yes. Without an expiry date, a security.txt file is invalid. The date has to be specified in a field called Expires. It follows that you have to update your security.txt file from time to time. RFC 9116 recommends using a validity period of less than a year. That makes you regularly check the information in your file and make any necessary updates. The use of expiry dates prevents old contact details being left in neglected files.

Security.txt provides a technical entry point. Responsible disclosure is a set of arrangements and a process for reporting and dealing with vulnerabilities. In your security.txt file, you can signpost your responsible disclosure policy in the Policy field.

Yes. Publishing a security.txt file is useful only if incoming vulnerability reports are actually dealt with. That might mean having a special mailbox for reports, defining who is responsible for what and keeping records, for example.

The standard doesn’t say how quickly you should respond to incoming reports. In practice, it’s normal to confirm receipt within a few days and to liaise with the report’s sender about publishing details of the detected vulnerability. The NCSC provides relevant guidelines for coordinated vulnerability disclosure.

Make sure that reports are treated as confidential and accessible only to suitably authorised personnel. Consider enabling encrypted communication by including an Encryption field in your security.txt file, giving a PGP key, for example.

Security.txt reduces the risk of vulnerability reports going to the wrong place or getting neglected. As a result, vulnerabilities are more likely to be addressed sooner and reputation damage mitigated. Implementing security.txt also shows that you’re open to responsible disclosure.

Yes, indirectly. Security.txt streamlines the first step: getting information to the right person. How quickly an issue is resolved after that depends on your internal processes and capacity.

The system doesn’t resolve vulnerabilities or remove the need for security measures. Security.txt is communication protocol, not a technical security solution.

Security.txt is on the 'use-or-explain' list maintained by the Forum for Standardisation, meaning that government organisations in the Netherlands must support it. For other organisations, it’s optional. However, security.txt support is regarded as best practice for modern internet standards.

A security.txt file contains only contact info and policy references. It doesn’t directly increase your attack surface. You may see an upturn in e-mail traffic, however.

Research has shown that organisations without security.txt files are also scanned and probed for vulnerabilities. Security.txt simply makes it clear how vulnerabilities can be responsibly disclosed.

It's best to use a dedicated e-mail address for vulnerability reports. Set up filters on the mailbox, and make sure it’s actively monitored. Consider creating a web form as well.

Your security.txt file can point to your responsible disclosure policy, but isn’t a replacement for a policy. The file is a technical point of entry, while your disclosure policy explains what practical arrangements you have made.

Both files have to be placed at a standard location, and both give instructions for outsiders. Robots.txt is for search engines, while security.txt is for vulnerability reporting.

Yes. You can give the address of a bug bounty programme or disclosure platform in the Contact field or Policy field. A bug bounty is optional and separate from the standard itself.