Many VPN websites mention a bug bounty, a responsible disclosure policy or a security contact. These are statements about process, and they are easy to confuse with evidence about how secure a service is. One technical document, RFC 9116, defines a standard file called security.txt for publishing this kind of information. Reading what that document says, and what it avoids saying, helps separate a published channel from a verified security record. This guide is general information and makes no assessment of any provider.
What RFC 9116 is
RFC 9116, published by the Internet Engineering Task Force (IETF) in April 2022, defines a machine-parsable format named security.txt. Its stated purpose is to help organisations describe their vulnerability disclosure practices so that researchers can report problems more easily. The document carries the category “Informational” and is described as not being an Internet Standards Track specification. It also says that security.txt is intended to be complementary to, and not a substitute for, other public resources an organisation maintains about its security disclosure practices.
It is a technical format, not a law. The RFC describes how the file should be structured and located, and what readers should be careful about, and it does not require any organisation to publish one or say anything about the quality of an organisation’s security.
What the file contains
For web services, the file is placed at the path /.well-known/security.txt on the domain, retrieved over HTTPS. The fields defined include:
- Contact, the method researchers should use to report vulnerabilities. This field must always be present.
- Expires, the date after which the data is considered stale and should not be used. This field must also be present, and the RFC recommends a value less than a year ahead.
- Policy, a link to the organisation’s vulnerability disclosure policy.
- Acknowledgments, a link to a page recognising researchers who reported issues.
- Encryption, Canonical, Hiring and Preferred-Languages, which cover encrypted reporting, the file’s own location, security jobs and languages.
Only Contact and Expires are mandatory. Everything else, including the disclosure policy, is optional.
What the RFC warns about
The security considerations section of the document is useful for anyone reading a provider’s file.
- Stale information. The RFC states that not having a security.txt file may be preferable to having stale information in it, because outdated contacts can mean reports are lost or sent to the wrong place. The Expires date is the signal to check.
- Compromised files. An attacker who compromises a website can alter the file or set up a redirect. The RFC advises organisations to use the Canonical field and digital signatures, and advises researchers to validate the file before using it.
- No implied permission to test. The RFC says researchers should not assume the presence or absence of the file grants or denies permission for security testing. Any permission may be set out in the disclosure policy.
- Limited scope. A file applies only to the domain or IP address from which it was retrieved, not its subdomains or parent domains. It may also apply to products and services provided by the organisation, so the scope depends on what the file or its policy says.
What a security.txt file cannot show
The format records how to report a problem. It does not record whether problems have been found, how quickly they were fixed, whether a test or audit has happened, or what an audit concluded. A provider with a tidy file could have a poor record, and a provider without one could have a strong record. The file is a statement by the organisation about itself, so it belongs in the “claimed” column, not the “independently verified” column.
The Acknowledgments page is the closest the format comes to evidence, since it lists researchers who have reported issues. It is still maintained by the organisation, and the RFC says only that it should list researchers who reported vulnerabilities and collaborated on fixes.
Questions worth asking about a VPN provider
- Is there a disclosure policy, and does it say which domains, apps and servers are in scope?
- Is the Expires date in the future, and does the contact still work as described?
- Is any claim about a bug bounty backed by a public programme page, rather than a marketing line?
- Is there a separate, independently published report on testing? See the guides on logging policies and independent audits and on a published audit and its limits.
Common questions
Does a security.txt file mean a VPN is more secure?
No. It describes a reporting channel. Security depends on how the service is built and operated, which the file does not address.
Can researchers test a provider’s servers because the file exists?
The RFC says researchers should not assume that the file grants permission to test. Any permission is a matter for the organisation’s own policy.
The bottom line
A security.txt file, as defined by RFC 9116, is a published statement of how to report vulnerabilities, with an expiry date, optional links to a policy and an acknowledgments page, and a scope limited to the domain that serves it. It is useful as a sign that a reporting route has been described, and the RFC itself cautions about stale data, tampering and over-reading permission. It is not a record of vulnerabilities found or fixed, and it does not replace independent testing reports. For a VPN provider, treat it as a claim about process, and look elsewhere for verification.
Sources
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (rfc-editor.org, IETF, April 2022)