security.txt is a small plain-text file a website publishes to tell security researchers how to report vulnerabilities. It is the security counterpart of robots.txt: a well-known, machine-readable location that answers "who do I contact about a security problem on this site?". Without it, researchers who find a vulnerability often have no reliable disclosure channel and end up mailing generic support addresses or giving up.

The format is standardized as RFC 9116 (April 2022, Informational). It is recommended by, among others, the US CISA, the UK government, the Dutch, French and Italian governments and the Australian Cyber Security Centre, and is published by sites such as Google, Facebook and GitHub.

The file lives under the well-known URI path of a domain:

A security.txt applies only to the host it was fetched from — the exact domain or IP address. It does not cover subdomains or parent domains: https://example.com/.well-known/security.txt says nothing about api.example.com, which needs its own file (or a redirect to a shared one). A file may, however, state that it also covers the organization's products and services.

The file is a list of Field: value lines, one field per line:

Where to send vulnerability reports. This is the only field that really matters, and it is required. It can appear multiple times; entries are listed in order of preference, the first being the preferred channel.

A web form or contact page is a valid alternative to an email address — useful when publishing a plain address would just attract spam.

When the content should be considered stale and not relied upon anymore. Required, exactly once. The RFC recommends setting it less than a year in the future, so the file is re-reviewed regularly and a forgotten file doesn't send reports to a long-gone mailbox.

Points to the key researchers should use to encrypt their report — typically an OpenPGP key (see GPG). It must be a reference to a key, never the key material itself.

A page recognizing researchers who reported vulnerabilities.

The vulnerability disclosure policy: what is in scope, how reports are handled, response times, safe-harbor terms, bug bounty details.

Languages the security team prefers for reports, as RFC 5646 tags. Appears at most once; the values are comma-separated and their order carries no meaning. If absent, English is assumed.

The URI(s) where this exact file is meant to be served from. Mainly relevant for signed files: without it, a valid signed file could be copied to a different site and still verify. If the file contains Canonical fields and the URI it was actually fetched from isn't one of them, its contents should not be trusted.

Security-related job openings at the organization.

Not part of the original RFC; registered later in the IANA registry by OASIS for the Common Security Advisory Framework. Points to the organization's CSAF provider-metadata.json, so tooling can find machine-readable security advisories.

New fields are registered in the IANA security.txt Fields registry (Expert Review). Any registered extension field is optional, and parsers ignore fields they don't support.

The file should be signed with an OpenPGP cleartext signature (RFC 4880 §7) so researchers can verify it hasn't been tampered with. A signed file should always include a Canonical field, since the signature authenticates the content but not the location it's served from.

The result looks like:

A valid signature only proves the file was signed by that key — the researcher still has to decide whether the key actually belongs to the organization.

Any static file will do. Examples:

Check it:

Points from RFC 9116 §5 worth keeping in mind — both when publishing and when consuming a file: