security.txt Generator and Validator — générateur et validateur de security.txt

What security.txt is for

Someone who finds a vulnerability in your site needs to know whom to tell. RFC 9116 answers that with a small text file at a fixed place, https://<host>/.well-known/security.txt, that researchers and their tools know to look for. Two fields are required. Contact says how to reach you — a mailto: or tel: URI or a web form — and may appear several times, in order of preference. Expires says when the file stops being valid, as an RFC 3339 date-time; the RFC recommends less than a year ahead, so a forgotten file eventually stops misdirecting reports. Everything else is optional: Encryption points at the key reports should be encrypted with, Policy at your disclosure policy, Acknowledgments at a thanks page, Preferred-Languages lists language tags, Canonical says where the file is meant to live, and Hiring links to security jobs. The IANA registry of fields has since added CSAF, the location of machine-readable security advisories, and Bug-Bounty, whether reports are rewarded.

What the generator writes

The generator writes the required fields first — contacts in the order you give them, then Expires — and the optional ones after, one value per line. An e-mail address becomes a mailto: URI and a phone number a tel: URI, and the notes say so. An empty Expires becomes the end of the day before the same date next year, in UTC. With a site name it adds where to publish the file and suggests a matching Canonical line. The output is then run through the validator below, so the page never hands you a file that breaks the RFC without saying how.

Signing

RFC 9116 recommends signing the file with an OpenPGP cleartext signature, so a reader can tell it was not swapped on the way or on a compromised server — and a signed Canonical line also proves where the file belongs. Signing needs your private key, which never belongs on a web page: the generator gives you the gpg --clearsign command to run on your own machine, and the gpg --verify command to check the result. Publish the signature under the name security.txt.

What the validator checks

The validator reads a file the way a researcher's tool would. It applies the grammar of RFC 9116 §4 — case-insensitive field names, comments, blank lines, LF or CRLF — and checks that Contact is present and Expires appears exactly once, in the future and not too far ahead. Each value is checked against its field: URIs must be absolute and web URIs must use HTTPS, language tags must be well-formed (RFC 5646), Bug-Bounty must be True or False. It checks encoding (UTF-8 without a byte-order mark), the size limits, and the framing of an OpenPGP signature: the armour lines, the Hash: header, dash-escaping and the CRC-24 checksum, and it reads the key ID and algorithms of the signature packets. It does not verify the signature itself — that needs the signer's public key, which you should get independently. Given the URL the file is published at, it also checks that the location is right and that Canonical names it. A file that is HTML — a web server's error page served under the right name — is caught too.

What stays on your machine

Both modes run in your browser; the page makes no request of its own. Fetching the published file from a site needs a request from our servers (most sites do not allow browsers to read the file from another origin), and ecdsa.com does not make such requests yet, so the validator checks the text you paste. A share link keeps the draft or the pasted file after the # of the address, which browsers never send to a server.

While you are publishing contact details, consider the other records that tell the world how your domain is meant to be used: a CAA record from the CAA record generator, and an HTTPS configuration with HSTS from the TLS configuration generator.