Open Terminal

security.txt Checker

Available

Check whether a website publishes security.txt for vulnerability disclosure and validate it against RFC 9116: Contact and Expires, date formats, Canonical, location and signature.

Check a security.txt

Checks /.well-known/security.txt, then /security.txt on the site’s host.

security.txt report

Fetch or paste a security.txt to validate its fields against RFC 9116.

How it works

RFC 9116 defines security.txt: a plain-text file at /.well-known/security.txt telling security researchers how to report vulnerabilities. It must contain at least one Contact and exactly one Expires field, be served over HTTPS as text/plain, and may be OpenPGP-signed. The checker validates every field, the expiry date and the Canonical location. Paste mode works in your browser; fetching live files needs the NetTools server.

Minimal valid file

Contact: mailto:[email protected]
Expires: 2027-06-30T23:00:00.000Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy

Publish it at https://your-domain/.well-known/security.txt as text/plain; charset=utf-8, keep Expires less than a year ahead, and consider signing it with OpenPGP. Specification: RFC 9116.

Safeguards & responsible use

  • Fetches only /.well-known/security.txt and /security.txt on public hosts through SSRF protection, with a 64 KiB size limit and short timeouts.
  • Per-client rate limits; neither the domain nor the file is stored.

Frequently asked questions

Does a valid security.txt mean the website is secure?

No. It only shows that the site publishes up-to-date contact details for reporting vulnerabilities. It says nothing about how secure the site actually is.

Which fields are required?

Contact (one or more mailto:, tel: or https:// URIs) and Expires (exactly once, an RFC 3339 date-time such as 2027-06-30T23:00:00Z, ideally less than a year ahead). Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy and Hiring are optional.

Where must the file be?

At /.well-known/security.txt, served over HTTPS. /security.txt at the root is a legacy location that may redirect to the well-known path.

Should I sign the file?

Signing with OpenPGP is recommended, so readers can verify it was not tampered with. If you sign it, include Canonical fields listing where the file is published.