security.txt checker

The location. The file belongs under the conventional well-known path, and automated tooling looks only there. The older root location is deprecated, so a file served only from it is a file most readers will not find.

The contact field, which is required. A file without one is unusable: it announces that reports are welcome and provides no way to send one.

The expiry field, which is also required. It is what tells a reader whether the contact is still current.

Whether the expiry date is in the past, which is the single most common finding on sites that have one at all.

Whether a disclosure policy is referenced, which is optional and sets expectations on both sides of a report.

No file leaves a reader to find a contact address the usual way — a support form, a general enquiries address. Slow, and it works.

An expired file tells them the information is stale. A careful reader does not trust the address; a less careful one writes to it and receives nothing back.

Either way the report does not reach you, which is the outcome the file was published to prevent.

The expiry date exists precisely so that a forgotten file announces itself as forgotten rather than quietly misleading people. That is the mechanism working — and it only helps if someone acts on it.

A date roughly a year ahead, renewed as part of whatever annual review the site already has, is the practical pattern.

A contact that will still be monitored in a year. A role address reaches whoever holds the role today; a named individual's address stops working when they leave.

An expiry date in the future, renewed deliberately rather than pushed far out to avoid the renewal.

A link to a disclosure policy, so a reader knows what to expect before writing.

Optionally a preferred language, an encryption key, and an acknowledgements page — all of which are useful and none of which substitute for the first two.

The change-password discovery path is a separate convention in the same directory, and it does a smaller job well.

Password managers use it to send someone straight to the screen where they change their password, instead of leaving them to find it in an account menu.

It costs one redirect to configure and it measurably increases how often people complete a password change they have started.

It is unrelated to security.txt beyond the shared directory, which is why it is reported separately rather than folded into the same finding.

`exposure.security_txt.present` fetches the file and `exposure.security_txt.location` verifies it is served from the canonical path.

`exposure.security_txt.fields` validates the required contact and expiry fields. `exposure.security_txt.expired` checks whether the expiry date has passed.

`exposure.security_txt.policy` reports whether a disclosure policy is referenced. `exposure.well_known.change_password` reports the password-change discovery path.

The file is fetched and parsed. Whether the contact address is monitored, or whether a report sent to it receives a reply, cannot be established from outside.

A signature on the file is not verified against any key.

The referenced policy is checked for being linked, not read or assessed.

Publishing the file changes nothing about the site's security. It changes what happens after someone notices something, which is a different and genuinely useful thing.