Build a well formed security.txt file or audit one you already serve, both against RFC 9116. The validator enforces the required Contact and Expires fields, calls out a file that has already expired, flags plain http where https belongs, and notes whether the file is PGP signed.
mailto:, an https:// form, or tel:. List the most preferred first.2027-01-31T23:59:59Z.A security.txt file is a small plain text file that answers one question for a security researcher: how do I report a problem to you. It lives at a predictable path, /.well-known/security.txt, so a researcher who finds a bug does not have to dig through your site for a contact. The format is standardized by RFC 9116. The file is a list of Name: value lines, one per line, and a field may appear more than once where that makes sense, such as several Contact lines.
RFC 9116 requires exactly two things. There must be at least one Contact field, and there must be exactly one Expires field holding a single ISO 8601 timestamp. Contact tells a researcher where to reach you, by email with mailto:, by a web form over https://, or by phone with tel:. Expires states the moment after which the file should no longer be trusted, which keeps a stale file from quietly misdirecting reports for years.
The differentiator in the validator is the expiry check. A file whose Expires date is in the past is, by the letter of the standard, a file that should not be relied on. The trouble is that nothing breaks visibly when it lapses: the page still loads, the contact line still reads fine, and only a careful researcher notices the date has passed. That is exactly the kind of slow drift a security program is supposed to catch. The validator surfaces an expired file as a prominent, unmissable error rather than a quiet footnote, so you fix it before it costs you a report.
Beyond the two required fields, the standard defines several optional ones. Encryption points at your OpenPGP key so a reporter can send you an encrypted message. Acknowledgments links a page that credits past reporters. Preferred-Languages is a comma list of language tags. Canonical states the HTTPS URL where the file itself lives, which lets a reader confirm they are looking at the genuine file. Policy links your disclosure policy, and Hiring links security roles. Each is a single value per line, and the generator writes them in a sensible order.
A generated file is only useful once it is served the right way. Put it at https://your-domain/.well-known/security.txt and serve it over HTTPS so it cannot be tampered with in transit. Where the file lists a Contact URL or links to a Policy, those should be HTTPS too, otherwise you steer a researcher toward a plain text page an attacker on the path could rewrite. The standard also recommends signing the file with an OpenPGP cleartext signature so a reader can confirm it was not altered. Signing is advisory, and this tool never asks for your key, so it only reports whether a signature block looks present.
The validator parses each line, splits it on the first colon into a field name and a value, and checks the result against RFC 9116. A failed required field is an error. A plain http:// URL where https:// is expected is a warning, as is a field name the standard does not define or one whose casing is off. A missing signature is advisory. A file that has already expired is the loud one. This tool reads structure and dates, it does not fetch your site or verify any signature, because verifying a signature needs the key and the key never belongs in a page like this. For the wider picture of how a disclosure path fits into a security program, the web application security guide and the AI security testing writing go deeper than a single file can.