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.
Frequently asked questions
- Is security.txt mandatory?
- Not by law. The EU NIS2 directive, however, explicitly lists vulnerability handling and disclosure among the measures affected companies have to implement. A security.txt is the simplest visible building block for that: it says where reports go.
- Does the file apply to subdomains?
- No. Under RFC 9116 a security.txt only applies to the host it was fetched from. shop.example.com needs its own file. If the subdomain redirects to a central file, that file should list the subdomain address as Canonical. The checker checks exactly the host you enter.
- Do I have to sign the file?
- No, the RFC only recommends it. If you sign, also set Canonical and re-sign the file after every change, including when you extend Expires. The checker detects the signature but does not verify it.
- Which expiry date should I set?
- Less than a year in the future, as the RFC recommends. Six to twelve months with a calendar reminder work well, or monitoring that alerts you in good time before it expires.