security.txt

security.txt is a plain-text file placed at a well-known location on a web server that tells security researchers how to report vulnerabilities to the organisation. Standardised as RFC 9116, it gives researchers a reliable, machine-readable way to find a disclosure contact without having to guess email addresses or hunt through support pages.

Why Researchers Need It

When a security researcher finds a vulnerability in a site, the path to responsible disclosure is often unclear. Is there a bug bounty programme? Which email address reaches the security team? Is there a PGP key to use for encrypted reports? Without a published disclosure channel, researchers sometimes give up or resort to posting publicly — neither of which benefits the affected organisation.

A security.txt file solves this with a single, predictable location. Automated scanners, bug bounty platforms, and individual researchers all know to check /.well-known/security.txt first. The file is also machine-parseable, allowing tools to extract contact and policy details programmatically.

File Location and Format

The canonical location is https://example.com/.well-known/security.txt. RFC 9116 also permits the file at the root path https://example.com/security.txt, but /.well-known/ is the preferred location. The file must be served over HTTPS.

# Example security.txt
Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-01-01T00:00:00Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/policy
Acknowledgments: https://example.com/security/thanks
Canonical: https://example.com/.well-known/security.txt

Required Fields

RFC 9116 defines two fields as required — a file without either is not a valid security.txt:

• Contact — one or more lines specifying how to reach the security team. Values are URIs: mailto: for email, https: for a web form, or tel: for a phone number. Multiple Contact lines are permitted and list options in priority order.
• Expires — an ISO 8601 datetime indicating when the file should be considered stale. Researchers checking an expired file cannot trust that the contact details are still current. RFC 9116 recommends keeping the expiry within one year and rotating the file before it lapses.

Optional Fields

• Encryption — a URI pointing to a PGP public key, allowing researchers to send encrypted reports.
• Policy — a URI for the organisation's vulnerability disclosure or bug bounty policy, describing scope, response times, and safe harbour terms.
• Acknowledgments — a URI for a page recognising researchers who have responsibly disclosed vulnerabilities.
• Canonical — the canonical URI of the security.txt file itself, useful when the file is mirrored or referenced from multiple locations.
• Preferred-Languages — a comma-separated list of language codes indicating which languages the security team can handle.
• Hiring — a URI linking to security-related job openings.

PGP Signing

The entire security.txt file may optionally be signed using a PGP clear-text signature. This allows researchers to verify that the file is authentic and has not been tampered with — important because an attacker who can modify security.txt could redirect vulnerability reports to themselves. A signed file wraps the content between -----BEGIN PGP SIGNED MESSAGE----- and -----END PGP SIGNATURE----- markers.

Check for security.txt with the domain report →