Inputs
Example
https://example.com/.well-known/security.txt -> Contact, Expires, Canonical, Encryption, Policy, Hiring, and Preferred-Languages.
security.txt Validator/Generator
Validate RFC 9116 vulnerability-disclosure contacts, expiry, canonical URL, policy, encryption, and hiring fields.
Use it to validate a vulnerability-disclosure contact file before publishing it under /.well-known/security.txt.
The file that decides whether researchers can reach you
When an external researcher finds a vulnerability in your infrastructure, the next thirty minutes decide whether you get a responsible report or a public write-up. RFC 9116's security.txt exists for exactly that moment: a machine-readable file at a well-known URL that says who to contact, in which language, under which policy, and with which PGP key to encrypt. It is one of the cheapest security controls available — and one of the most commonly botched.
The most frequent failure is quiet expiry. The RFC makes the Expires field mandatory precisely because stale contact files were the norm, and an expired security.txt reads as an unmaintained security function. The second failure is unreachable or misplaced files: served from the root but not from /.well-known/, redirected to a marketing page, or blocked by an overzealous WAF rule. This tool validates a fetched or pasted file against the RFC's field rules and generates a clean draft when you are starting fresh.
Validating, generating, and signing in the right order
For an existing deployment, fetch the live file and read the findings in order of severity: a missing or past Expires date first, malformed Contact entries second, then Canonical mismatches. Contact entries are listed in preference order, so put the mailbox you actually monitor first, and remember that mailto and https URIs each have syntax rules the RFC enforces strictly.
When generating, resist the temptation to fill in every optional field. A short honest file — Contact, Expires within a year, Canonical, Encryption if you can handle PGP mail — beats a long aspirational one. If you sign the file, the Canonical field becomes load-bearing: it binds the signature to the URL, so it must exactly match where the file is served. Sign locally with your own key; the page provides the gpg commands but never touches private key material.
What stays local and what the tool will not do
Pasted content stays in the browser, and URL fetches run through the same-origin helper against public hosts. The validator proves structure: that fields parse, dates conform to RFC 3339, and URIs are well-formed. It cannot prove that anyone reads the mailbox, that the PGP key referenced under Encryption is the one your team can actually decrypt with, or that your process responds within a reasonable time. Syntax is the entry ticket; the process behind it is yours.
Frequently asked questions
Why is Expires mandatory when most metadata files have no expiry?
Because contact information rots silently. An enforced expiry forces a periodic review, and researchers treat a current date as a signal that someone still owns the process. Keep validity at a year or less and renew it like a certificate.
Does the file belong at /.well-known/ or at the site root?
The canonical location is /.well-known/security.txt. Serving it additionally at /security.txt is a widely practiced legacy courtesy. If you serve both, keep them byte-identical — diverging copies are worse than a missing legacy copy.
Is signing the file worth the operational overhead?
If you list a PGP key under Encryption anyway, signing is consistent and cheap: it lets a researcher verify the contact data was published by the key holder. If your team has no PGP workflow, an unsigned but current and accurate file is far better than a signed stale one.
Can I list several Contact entries?
Yes, and order matters: the RFC defines earlier entries as preferred. A common pattern is a monitored security mailbox first, then a web form as fallback. Every listed channel must actually be monitored — each one is an implicit promise.
What does the Canonical field protect against?
Copies. If your file is mirrored or scraped to another URL, Canonical states where the authoritative version lives, and for signed files it binds the signature to that location. Without it, a stale copy elsewhere is indistinguishable from your real one.
Does a valid security.txt improve my security rating?
Several external scanners and rating services check for it, and it appears in agent-readiness and security-hygiene scoring. But the real payoff is operational: it removes every excuse for a finder not to contact you first.