HTTP security
security.txt checker
Fetch a site's /.well-known/security.txt and check that it tells someone who has found a vulnerability how to reach you, and that it is still current.
What this checks
https://<host>/.well-known/security.txtfor the domain and itswww.name, or the subdomain entered, following one redirect.- That the answer is a security.txt file: status
200, not an HTML page, and containing aContact:line. A custom error page, or a site that answers every path with its home page, counts as no file. - At least one
Contactfield with a value, and exactly oneExpiresfield. - That
Expiresis an RFC 3339 date, such as2027-09-30T23:00:00Z, and has not passed. - The file as the site serves it, up to its first 2,000 characters.
What the result means
security.txt (RFC 9116) is a plain text file at a fixed address that tells anyone who finds a security problem on your site how to report it. Without one, a report may go to a support queue that does not know what to do with it, or not be sent at all.
RFC 9116 requires at least one Contact and exactly one Expires. The expiry date exists so that a forgotten file stops being trusted: once it has passed, a researcher should assume the contacts may be out of date.
A missing file is a finding of informational severity; an incomplete or expired one is low. Neither is a weakness in the site itself. Both make it harder for someone to tell you about one.
How to fix common issues
No security.txt
Publish /.well-known/security.txt with at least a Contact and an Expires line, for example Contact: mailto:security@example.com and Expires: 2027-12-31T23:59:59Z.
security.txt is incomplete or expired
Make sure the file has at least one Contact line and an Expires date in the future (RFC 9116), and set a reminder to update it.
Cyber Essentials and ISO 27001
Neither Cyber Essentials nor ISO 27001 requires a security.txt file. A published reporting contact is technical evidence for the broader control in ISO/IEC 27001:2022 Annex A 8.8 (management of technical vulnerabilities).
Behind the file, the organisation has to establish who reads the reporting address, how quickly reports are acknowledged and assessed, what is in scope, and who renews the file before it expires. The file shows where reports go, not what happens to them.
Scope and limitations
- Optional fields such as
Policy,Encryption,Canonical,AcknowledgmentsandPreferred-Languagesare shown in the file but not checked, and an OpenPGP signature is not verified. - It does not contact the addresses listed or test whether anyone answers.
- Only
/.well-known/security.txtis requested. A file at the older top-level location,/security.txt, is not read. - It does not judge how far ahead
Expiresis set. RFC 9116 recommends less than a year.
Related guides
Questions
- What does a minimal security.txt look like?
- Two lines: a Contact field, such as Contact: mailto:security@example.org, and an Expires date in RFC 3339 form, such as Expires: 2027-09-30T23:00:00Z. Serve it as plain text at /.well-known/security.txt over HTTPS.
- How often should I update the Expires date?
- RFC 9116 recommends an Expires date less than a year ahead. Review the file and renew the date before it passes.
- Can Contact be a web form instead of an email address?
- Yes. Contact takes a URI: mailto:, tel: or an https: address. A file can list several Contact lines, in order of preference.
Related security tools
- HTTP security headers checker - Check a site's HSTS, CSP, framing, content-type, referrer and permissions headers.
- Website security checker - Check a domain's DNS, email authentication, TLS, security headers and public technology in one pass.
- Email security checker - Check MX, SPF, DMARC and DKIM together, and the protection of a domain that sends no mail.