security.txt Checker
Check for /.well-known/security.txt and its required fields.
The security.txt checker verifies whether a site publishes a /.well-known/security.txtfile and whether it contains the fields a security researcher needs to report a vulnerability. Enter a domain and the server fetches the standard location for you, extracting fields like Contact, Expires, Encryption, Policy and Acknowledgments and flagging anything missing.
security.txt is a plain-text file standardized as RFC 9116. It tells anyone who finds a security issue exactly where to report it, so reports don't get lost or disclosed publicly by mistake. Many government and enterprise sites already publish one, and it has become a basic signal of security maturity.
What is security.txt (RFC 9116)
security.txt is a standardized text file that states a site's security contact and vulnerability disclosure policy in a way both humans and machines can read. The canonical location is /.well-known/security.txt; some sites also keep a legacy copy at the root (/security.txt). This tool tries both.
Key fields
- Contact (required): an email, URL or phone to receive reports. At least one is needed.
- Expires (required): when the file's information stops being valid. Refresh before then.
- Encryption: where to find a public key for encrypted reports.
- Policy: a link to the vulnerability disclosure policy.
- Acknowledgments: a page thanking researchers who contributed.
- Preferred-Languages / Canonical: preferred languages and the file's canonical URL.
Authoring and operations tips
Serve the file over HTTPS and, in production, sign it (e.g. with PGP) to prevent tampering. Keep Expires within about a year and refresh it regularly. Periodically confirm the contact is still monitored and the file has not expired so reports don't fall through the cracks. Since security.txt is just one signal of security maturity, use the security headers checker to confirm baseline defenses like HSTS and CSP are in place too.
Field format at a glance
Each RFC 9116 field has a defined format and a rule about whether it may repeat. Dates in particular must be ISO 8601, and multi-value fields like Contact are listed in order of preference.
| Field | Required | Repeatable | Value format / example |
|---|---|---|---|
Contact | Yes | Yes | mailto:, tel: or https:// URI. e.g. mailto:security@example.com |
Expires | Yes | No (once) | ISO 8601 UTC. e.g. 2026-12-31T23:59:59.000Z |
Encryption | No | Yes | URI to a key, not the key itself. e.g. https://example.com/pgp-key.txt |
Policy | No | Yes | URI to the disclosure policy. e.g. https://example.com/disclosure |
Canonical | No | Yes | Canonical URL of this file. e.g. https://example.com/.well-known/security.txt |
Preferred-Languages | No | No (once) | Comma-separated BCP 47 tags. e.g. en, ko, ja |
Reading a real file
Suppose a site publishes this security.txt:
Contact: mailto:security@example.com
Contact: https://example.com/report
Expires: 2026-12-31T23:59:59.000Z
Encryption: https://example.com/pgp-key.txt
Preferred-Languages: en, ko
Canonical: https://example.com/.well-known/security.txtThe checker recognizes two Contact entries (an email and a web form) and, because Expires is in the future, marks the file valid. Policy and Acknowledgments are absent, so they show as missing — but only as a warning since they are optional. If Expires were set to a past date like 2024-01-01, the file would be reported as expired, signaling reporters that the information may be stale.
Common pitfall
- Bad Expires format: writing a date only, such as
2026-12-31, violates RFC 9116. You must use a full ISO 8601 timestamp in UTC (...T23:59:59Z). - An HTML response: when the file is absent, many servers still return HTTP 200 with a SPA's
index.html. If theContent-Typeisn'ttext/plainor you see<html>, there is effectively no security.txt. - Root-only placement: shipping only
/security.txtwithout/.well-known/security.txtmeans standards-compliant scanners may miss it. Put it at the canonical path.