security.txt Checker (RFC 9116)

Is your security.txt still valid — or quietly expired?

Paste a security.txt and check it against RFC 9116. The field that catches most sites is Expires: the RFC says data in an expired file must be considered stale, so once that date passes a conforming researcher treats your file as publishing no contact at all — while the server keeps serving it, nothing 404s, and it still reads fine to a human. Nothing about that failure is visible from the outside.

Nothing is uploaded. The text you paste is parsed in this browser and never leaves your device — no small thing here, since a list of which companies someone is checking is itself sensitive.

1. Check a security.txt

security.txt contents (from /.well-known/security.txt, or a local file)

2. Result

not checked here Where the file is served from, and the media type it is served with, cannot be seen from pasted text. Those two checks need the CLI below.

Prefer a CLI, or want this as a CI gate?

The CLI fetches the file over real HTTP, tries /.well-known/security.txt first and the legacy root copy second, and adds the two checks a paste cannot support — the served location and the media type:

node check.mjs example.com
node check.mjs example.com --json
node check.mjs https://example.com/.well-known/security.txt --timeout 5000

Get check.mjs, engine.mjs and fetch-url.mjs from the repo — plain Node 18+, nothing to install. It only ever talks to the host you name; nothing goes through this site. Exit code 1 on a danger-severity finding or when no security.txt could be fetched at all, 0 otherwise.

This is the one check in this catalogue worth scheduling. Every other conformance rule here is stable once fixed — but Expires is a date, so a file that passes today fails on its own, with no commit and no deploy to blame. A monthly CI run is how you find out before a researcher does.

What's checked

Check	What it flags	Severity	Needs the CLI?
Expired	`Expires` is in the past — RFC 9116 says the whole file must then be treated as stale	Danger	No
Expires missing / duplicated / malformed	RFC 9116 requires exactly one, as an ISO 8601 timestamp	Danger	No
Expires too far out or nearly due	More than a year ahead (the RFC recommends under a year), or under 30 days left	Notice	No
Contact missing or not a URI	No `Contact` at all, or a bare address rather than a `mailto:`/`https:`/`tel:` URI	Danger	No
Insecure URI	A `Contact` over plain `http:` (danger), or another field over `http:` (notice)	Danger / Notice	No
Key pasted into the file	A PGP key block inline, which RFC 9116 forbids — `Encryption` takes a URI	Danger	No
Malformed line	A line that is neither `Field: value`, a `#` comment, nor blank	Danger	No
Silently-ignored field	`Acknowledgements` (the RFC spells it without the middle "e") and other unknown names a conforming parser drops	Notice	No
Signed with no Canonical	A cleartext-signed file that does not say where it is meant to live	Notice	No
Wrong location	Served from the site root rather than `/.well-known/security.txt`	Notice	Yes
Wrong media type	Not served as `text/plain; charset=utf-8`	Notice	Yes

More: why RFC 9116 made Expires mandatory, and what an expired file costs you. See also: how this differs from securitytxt.org's generator and validator, and where eyeballing a security.txt usually goes wrong.

Common questions

What does an expired security.txt actually break?

RFC 9116 says data in an expired file must be considered stale and should not be used. So once the Expires date passes, a conforming researcher or automated tool treats your file as if it published no contact at all — even though the server is still serving it and it still looks fine to a human reading it. Nothing goes red, nothing 404s, and the file quietly stops doing its job. That is why Expires is the field this tool checks first.

Why does Contact have to be a URI?

RFC 9116 defines Contact as a URI field so that a consumer can act on it without guessing what kind of thing it is. security@example.com could be an address or a username; mailto:security@example.com cannot be anything else. Write a web form as https:, an email address as mailto:, and a phone number as tel:. A bare address is the single most common conformance failure after the expiry date.

Where does the file have to live?

At /.well-known/security.txt. A copy at the site root is tolerated by some tooling for historical reasons, but conforming consumers look under /.well-known/ and will not find a root-only copy. The browser tool here cannot see where your file is served from — you pasted the text, not the URL — so that check is one the CLI does.

Is this a security assessment?

No. It checks whether one text file conforms to the rules RFC 9116 states about that file. It does not test the site, scan for vulnerabilities, verify that anyone reads the address you publish, or confirm that the people behind it respond. A perfectly conforming security.txt on an unmaintained inbox passes every check here.

Is your `security.txt` still valid — or quietly expired?