What is security.txt?
security.txt is a small text file that tells people how to report a security vulnerability to you. The IETF standardised the format in 2022 as RFC 9116. The file always lives at the same place, https://example.com/.well-known/security.txt, and names at least one contact and an expiry date.
Without it, security researchers have to guess: the report ends up in the sales contact form, at the imprint address, in spam or never arrives at all. In the worst case the vulnerability is published because nobody could be reached. A maintained security.txt takes five minutes and turns luck into a defined reporting channel.
Structure of the file
Every line is a field with a name and a value, comments start with #. Two fields are required, the rest is optional:
- Contact (required): an email address with mailto:, a phone number with tel: or a report form with https://. Several lines are allowed, the first one is preferred.
- Expires (required, exactly once): an RFC 3339 date until which the details are valid. Less than a year ahead is recommended. After that researchers should ignore the file.
- Encryption: address of the public key for encrypted reports.
- Policy: address of your vulnerability disclosure policy.
- Preferred-Languages: languages in which reports are welcome, for example “en, de”.
- Canonical: the address(es) this file applies to. Especially important for signed files.
- Acknowledgments and Hiring: thanks to reporters and security job openings.
Contact: mailto:security@example.com
Contact: https://example.com/security
Expires: 2027-06-30T22:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Preferred-Languages: en, de
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/policyHow to read the result
The checker separates errors that make the file invalid from deviations that only make it untidy:
- No file: information, not an error. Most domains do not have a security.txt (yet).
- Contact or Expires missing, Expires unreadable or the file served over HTTP: the file is invalid under RFC 9116 and has no effect.
- Expired: researchers should ignore an expired file. If it expires within the next 30 days, the checker warns you ahead of time.
- Content type other than text/plain, legacy location /security.txt, contact without mailto: or https://, unreadable lines, Canonical pointing elsewhere: hints, the file stays readable.
- Signed: an OpenPGP signature is detected and only the signed text is evaluated. The checker does not verify the signature itself.
Common mistakes
- Forgetting Expires: the file was created once and quietly expired a year later. By far the most common mistake.
- Wrong date format: “31.12.2026” or “Dec 31, 2026” are not RFC 3339 dates. Correct is 2026-12-31T23:00:00.000Z.
- The home page instead of the file: many single-page apps and site builders answer every address with the home page and status 200. The checker recognises HTML and treats it as “no file”.
- Email without mailto: the address is written as “security@example.com” instead of “mailto:security@example.com”.
- A mailbox nobody reads: the file is only as good as the address in it. security@ has to reach someone who knows what to do.
Monitor security.txt continuously
Because Expires is required, security.txt is not a file you create once and forget. DomainWarn checks it daily for every customer domain, opens an incident 30 days before it expires, when it has expired and when the file is invalid, and shows in the timeline when the file disappears or the security contact changes. The latter would otherwise go unnoticed.