security.txt Generator
Generate an RFC 9116 security.txt so vulnerability reports reach the right person.
About this tool
Builds a `security.txt` file to RFC 9116 — the standard file that tells somebody who has found a vulnerability how to report it.
The problem it solves is narrow and entirely real. A researcher who finds something on your site has no obvious way to reach you. They try the contact form, get a reply from sales, and either give up or publish. A file taking two minutes to write removes that path.
**`Expires` is mandatory**, and this is what people get wrong. A file past its expiry date is invalid, not merely old — and that is deliberate. Setting it a decade out defeats the point: the field exists so a stale file announces itself rather than quietly listing a security contact who left in 2021. A year is the usual choice.
The file goes at `/.well-known/security.txt`, served over HTTPS as `text/plain`.
Common questions
Where does the file go?
At /.well-known/security.txt, served over HTTPS with a text/plain content type. A copy at /security.txt is permitted for compatibility but the well-known path is the canonical one.
Why must Expires be set?
Because a security contact that is silently out of date is worse than none — a researcher emails an address nobody reads and concludes you were told. An expiry date makes staleness visible. A year ahead is the usual choice.
Do I need a bug bounty to publish one?
No. The file says where to send a report, not that you will pay for it. Adding a Policy link that says explicitly there is no bounty is better than leaving people to guess.
Should I sign the file?
Optional and rarely done. A PGP signature proves the file was not tampered with; for most sites, serving it over HTTPS is enough. If you do sign it, the Canonical field must be present.