security.txt Checker & Validator

What this security.txt checker looks for

Enter a URL and this tool fetches /.well-known/security.txt from that site — falling back to the legacy /security.txt location if the standard one returns a 404 — and validates every field against RFC 9116, the formal specification for this file. Most sites don't have one at all, so if yours does and it validates cleanly, this report should say so plainly.

Why security.txt exists

A researcher who finds a real vulnerability on your site faces a practical problem before they can even report it: who do they email? Guessing security@, trawling a support form, or emailing a generic contact address all take time and frequently fail. Some researchers give up. Others, especially under time pressure or after being ignored once, disclose the bug publicly without warning you first. security.txt exists purely to remove that friction — one file, one predictable location, one clear answer to "who do I tell".

Contact — the one field that matters most

Contact is the only field RFC 9116 actually requires, and it has to be a URI: mailto:, https://, or tel:. A bare email address like security@example.com without the mailto: prefix is a common mistake — it reads fine to a human but fails strict parsing by automated tooling that scans security.txt files at scale. A file with no Contact field at all is close to useless: it confirms you thought about this, but gives nobody anywhere to send a report.

Expires — proof the file is maintained

Expires is also required by RFC 9116, though it is widely skipped in practice. It exists so a researcher — or automated tooling — can tell whether the file was set up once and forgotten, or is actively maintained. An expired file signals the latter is possible: if nobody has touched this file in two years, is the Contact address still monitored? We flag a missing Expires as medium severity, an expired one the same, and a date more than a year out as low — distant enough to likely be forgotten before it's renewed.

Location: .well-known vs. the legacy root

RFC 9116 defines exactly one valid location: /.well-known/security.txt. An earlier draft of the standard allowed the file at the site root, and some older tooling and guides still reference /security.txt there. If we only find the file at the root, we flag it as low severity — it works for a human reading it directly, but tooling built against the current RFC will miss it.

Encryption, Policy, Preferred-Languages, Canonical

These are all optional, and their absence is informational rather than a real gap. Encryption points to a public key so a report can be sent encrypted — worth having if your Contact is an email address, since vulnerability details are exactly the kind of thing you don't want sitting in plaintext on a mail server. Policy links to your disclosure policy, so a researcher knows the rules — scope, safe harbour, expected response time — before they report anything. Preferred-Languages saves a non-native English speaker from guessing whether to write in English. Canonical names the authoritative URL for the file itself; we check it matches wherever we actually found it, since a mismatch usually means the file is duplicated somewhere it shouldn't be.

PGP signature, HTTPS, and content type

A PGP-signed file lets a researcher verify it wasn't tampered with by a compromised proxy or CDN between you and them — a bigger deal for the Contact field than it might first seem, since a modified contact address quietly redirects every future vulnerability report to an attacker. We also check the file was served over HTTPS for the same reason, and that the server sent Content-Type: text/plain as RFC 9116 requires, rather than a type that gets misinterpreted by a browser or parser.

A complete, correct example

Copy this as a starting point and adjust the values:

Contact: mailto:security@example.com
Contact: https://example.com/security-report
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security-policy
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

Multiple Contact lines are allowed and encouraged — an email as a fallback alongside a web form covers more researchers than either alone. Place the file at /.well-known/security.txt, serve it as text/plain over HTTPS, and put a reminder in your calendar to renew the Expires date before it lapses.