Security researchers discover vulnerabilities in websites every day. Without a clear disclosure channel, they may not know who to contact — or give up entirely. A security.txt file is a two-minute setup that gives researchers a verified, machine-readable path to report what they find.
security.txt is a proposed standard (RFC 9116, published April 2022) that defines a plain-text file organisations can publish to communicate their security disclosure preferences. It tells security researchers: here's how to contact us, here's our disclosure policy, here's what we'd like you to include in a report.
The concept is modelled on robots.txt — a well-known convention that any tool can discover without needing to know the organisation's structure in advance. Automated vulnerability scanners, bug bounty platforms, and responsible disclosure tools all look for security.txt as the first step when reporting a finding.
Major organisations including Google, GitHub, and the UK NCSC publish security.txt files. Bug bounty programs commonly reference it. Without it, researchers who find something serious in your site often have no idea where to report it.
RFC 9116 specifies two canonical locations. Tools check them in this order:
https://yourdomain.com/.well-known/security.txt — the canonical location per RFC 8615 (Well-Known URIs)https://yourdomain.com/security.txt — a fallback location for compatibilityThe .well-known/ location is preferred. Many web servers serve files from this directory automatically, but you may need to configure your server to allow access to this path if you have rules blocking dotfiles.
The file must be served over HTTPS. An HTTP-only security.txt is considered invalid by most tooling.
RFC 9116 defines two required fields. A security.txt without both is technically non-compliant:
| Field | Required | Description |
|---|---|---|
Contact: |
Required | Where to send vulnerability reports. Can be a URL (bug bounty platform, form), an email address (mailto:), or a phone number (tel:). You can list multiple Contact fields. |
Expires: |
Required | An ISO 8601 datetime after which the file should be considered stale. Prevents outdated contact info being trusted indefinitely. Renew yearly. |
| Field | Description |
|---|---|
Encryption: | A URL pointing to a PGP public key researchers can use to encrypt reports. Useful for sensitive disclosures. |
Acknowledgments: | A URL to a page where you acknowledge researchers who have reported issues. |
Preferred-Languages: | A comma-separated list of language codes you prefer to receive reports in. |
Canonical: | The canonical URL of this security.txt file itself, for verification. |
Policy: | A URL to your vulnerability disclosure policy (scope, responsible disclosure rules, safe harbour). |
Hiring: | A URL to security-related job postings. |
When a security researcher finds a potential vulnerability on your site, their first step is typically to look for a security.txt file. They check /.well-known/security.txt and /security.txt. If they find a valid file, they know exactly who to contact and in what format.
Without a security.txt, researchers face a time-consuming search for a security contact: hunting for a security@ email address, finding a bug bounty profile, or guessing who to email. Many give up and report elsewhere, report publicly, or simply don't bother at all. A vulnerability that could have been disclosed privately ends up being published or exploited.
Automated tools like vulnerability scanners and OSINT frameworks also check for security.txt to understand a target's disclosure policy before testing. A well-written policy field can communicate your safe harbour position — protecting researchers who act in good faith and encouraging more reports.
# Security contact for example.com Contact: mailto:security@example.com Contact: https://bugcrowd.com/example Expires: 2027-01-01T00:00:00.000Z Preferred-Languages: en, hi Policy: https://example.com/security-policy Acknowledgments: https://example.com/security/hall-of-fame Canonical: https://example.com/.well-known/security.txt
Contact: mailto:security@yourdomain.com Expires: 2027-06-01T00:00:00.000Z Preferred-Languages: en
RFC 9116 allows the security.txt file to be PGP-signed. A signed file lets researchers verify the contact information hasn't been tampered with — important if an attacker compromised your server and changed the contact email to their own address. If you publish a security.txt for a high-value target, consider signing it.
Expires: date. Update the date and, if using PGP, re-sign the file. An expired security.txt is better than none, but tools will flag it as stale.
WebAudit checks for a valid security.txt at both canonical locations during every scan. It verifies the file is reachable over HTTPS, has a Contact field, and has a non-expired Expires field. For creating and validating your own file, use the WebAudit security.txt validator and generator.
WebAudit checks for security.txt as part of every scan and helps you generate a valid RFC 9116 compliant file.
Check your site's security now →