security.txt Validator/Generator
Validates RFC 9116 structure, dates, contacts, URIs, and draft content from pasted text or a public URL.
Web SecurityA valid security.txt removes friction at the exact moment a stranger is deciding whether to trust your organization with a vulnerability report. It is useful only when the address is watched, the key works, the expiry is owned, and the people behind the file know what happens after the first uncomfortable message arrives.
RFC 9116 standardizes a small answer to a practical problem: a researcher should not have to guess whether security@, a support form, or a social-media account reaches anyone capable of handling a vulnerability. Publish the authoritative file at https://example.com/.well-known/security.txt. Serving an identical legacy copy at /security.txt is courteous, but two divergent versions create precisely the ambiguity the standard is meant to remove.
Delivery is part of correctness. The file should return a successful response as text/plain over HTTPS, remain reachable without authentication or geofencing, and avoid a redirect to a generic marketing or login page. Check the deployed artifact with the security.txt Validator/Generator, which parses pasted content or a public URL, reports RFC field findings, and can produce a clean draft. It proves structure, not whether a human reads the mailbox; that distinction is the whole operational point.
Two fields are mandatory. At least one Contact field tells the finder where to report, and Expires gives an RFC 3339 timestamp after which the file must be treated as stale. Multiple contacts are allowed and ordered by preference. Put the channel you actually monitor first, then a genuinely independent fallback. A dead phone number plus an unowned mailbox is not resilience; it is two broken promises.
The optional fields are useful when they point to real capabilities. Canonical names the authoritative HTTPS URL and becomes especially important for signed files. Encryption links to a key, Policy explains scope and handling expectations, Acknowledgments credits reporters, Preferred-Languages sets communication expectations, and Hiring may point at relevant roles. Do not cargo-cult all of them. Every URI is another dependency to test, and every statement is something a researcher can reasonably expect you to honor.
Expires is mandatory because security contact data rots quietly. Set it no more than a year ahead, schedule renewal well before that date, and make renewal a substantive review: send a test report through every contact, fetch the PGP key from a clean machine, verify policy links, and confirm the current incident owner. Simply advancing the timestamp preserves stale assumptions with fresh paint.
Treat the file like a certificate with an owner, monitoring, and a deployment path. Alert at several lead times, but also probe the public URL after every hosting or CDN migration. Review redirect and response-header behavior with the HTTP Header Analyzer; a syntactically perfect file behind a WAF challenge is absent to an automated client and hostile to a hurried human. Keep the source in version control, require security-team review, and make organizational changes — mailbox migration, outsourcing, acquisition, domain retirement — explicit triggers outside the normal calendar.
The Encryption field normally points to an HTTPS-hosted OpenPGP key or uses an openpgp4fpr: URI. Researchers need the public key; your team needs controlled access to the corresponding private key and a tested way to decrypt without one irreplaceable laptop. Publish a stable fingerprint through an independently controlled channel, define rotation and revocation, and rehearse recovery. A key nobody can use during an incident is worse than an honest request for a secure web form.
Cleartext signing the entire file lets a finder verify that its contact instructions were produced by the key holder and prevents unnoticed modification in mirrors or archives. When you sign, include Canonical, use the key referenced by Encryption, and automate signature verification in deployment tests. The signature does not make the statements true, encrypt incoming reports, or repair a compromised hosting account. If your organization has no maintained OpenPGP practice, publish an unsigned, current, accurate file first. Cryptographic ceremony is not a substitute for reachability.
Route incoming reports to a small trained group, not a ticket queue with ordinary customer-service macros. Send a human acknowledgment quickly, preserve the original message and attachments, assign an incident owner, and establish a protected communication channel. Then reproduce without asking the reporter to keep proving the same fact, classify impact and affected assets, preserve logs, and separate containment decisions from attribution speculation. A surprising report is not evidence of bad faith.
Define authority before this moment: who may take a service offline, involve legal counsel, notify customers or regulators, request a CVE, and approve a fix? The disclosure policy should state scope, safe-harbor intent, prohibited testing, expected response cadence, and how duplicate or out-of-scope reports are handled. It should not demand silence forever or threaten researchers for good-faith work. The shortest path to public escalation is an automated rejection followed by weeks of silence.
Once reproduced, give the reporter a tracking reference and meaningful updates even when the update is “the fix needs another week.” Coordinate disclosure dates rather than assuming you control them. Validate the remediation against the original technique, search for the same defect class elsewhere, and decide whether exposed credentials, tokens, or certificates require rotation. The SSL Certificate Decoder can inspect the certificate a public host actually serves, including names, validity, algorithms, fingerprints, and the presented chain; it does not replace revocation or trust validation.
After closure, record time to acknowledgment, triage, containment, fix, and disclosure; review where evidence or authority stalled; and update both the runbook and security.txt if the routing failed. Thank the reporter in the form you agreed, including acknowledgment or bounty where applicable. A vulnerability-disclosure program becomes credible through repeated, boring execution. The file merely ensures the first packet lands in the right room.