Site security
security.txt: How Sites Publish a Security Contact
security.txt is a small text file that tells people how to report a security problem with a website. When a site has been hacked or defaced, it is often the quickest way to reach someone who can fix it.
The short answer
A site publishes security.txt at /.well-known/security.txt. It lists one or more contacts for security reports and a date after which the file should no longer be trusted. The format is defined in RFC 9116.
It is not a promise to pay for bugs or a legal agreement. It simply tells you where to send a report so that it reaches the people who run the site, rather than a general support inbox.
The fields
| Field | Required | What it says |
|---|---|---|
| Contact | Yes | Where to send reports: an email address, a web form or a phone number. Can appear more than once, in order of preference. |
| Expires | Yes | When the file goes stale. After this date, treat the contents with caution. |
| Encryption | No | Where to find a key for sending encrypted reports. |
| Policy | No | A link to the site’s disclosure policy: what to include and what is in scope. |
| Acknowledgments | No | A page thanking people who reported problems. |
| Preferred-Languages | No | Languages the team can read reports in. |
| Canonical | No | The address the file is meant to be served from, so a copy elsewhere can be spotted. |
| Hiring | No | A link to security job openings. |
A minimal file looks like this:
Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-06-30T23:00:00Z
Policy: https://example.com/security/policy
Preferred-Languages: en, frThe file can be signed with OpenPGP so readers can check that it has not been tampered with. Signing is optional, and most files are not signed.
Common mistakes
- An expired file. The Expires date passes and nobody updates it, so readers cannot tell whether the contact still works. A year ahead is a sensible maximum.
- An HTML page instead of text. Some sites answer every unknown path with their homepage. The file must be served as plain text.
- A Canonical address that does not match. If the file is copied between sites, its Canonical field may point somewhere else.
- A contact nobody reads. The address only helps if someone watches it and knows what to do with a report.
How Website Recon uses it
Each Website Recon scan checks /.well-known/security.txt and falls back to /security.txt. The Site Owner Contact card shows the contacts and other fields it found, whether the file has expired, and the address it was read from.
The card matters most for a hacked or defaced site, where the site owner is usually the first party to tell before the host. For a domain registered for phishing, the owner is the attacker, so the report should go to the host and the registrar instead. The Who to report to section explains the order.
FAQ
Does every site need a security.txt file?
It is not required, but it is cheap to publish and makes it far more likely that a report reaches the right team quickly.
Can I trust a security.txt file I find?
Treat it like any contact detail you find online. Check that it is served from the site itself, that it has not expired, and that the Canonical field, if present, matches.
Is security.txt related to DNS?
Not directly. It is served over the web, but it is often checked alongside DNS and registration data when working out who runs a site and who to contact.