DNS Tools
VULNERABILITY DISCLOSURE

security.txt Checker

Check that your site publishes a valid security.txt so security researchers know whom to contact, and that its fields are current.

Run security.txt

The domain (or a subdomain). The check stays within that name and its www counterpart, like the full assessment.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What security.txt is

security.txt is a small text file, defined in RFC 9116, that tells people who find a vulnerability how to reach you. The standard location is /.well-known/security.txt over HTTPS. It contains fields such as Contact (required, at least once), Expires (required, exactly once), and optional Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy and Hiring. It is a convenience for responsible disclosure, not a security control: it does not protect your site, but it shortens the path from a finding to the right person.

This tool requests /.well-known/security.txt first, then the legacy /security.txt, over HTTPS only and reads up to 16 KB of each.

How to read the result

The tool shows the requests it made, then the parsed fields and findings.

  • Contact present: at least one valid contact URI such as an email address with mailto: or an https: page. A plain http: contact is flagged.
  • Expires valid: an ISO 8601 date-time in the future. Missing, malformed or past dates are reported, since an expired file should not be relied upon.
  • Location: a file served only at /security.txt is accepted but noted, because RFC 9116 asks for the .well-known path.
  • Content-Type: should be text/plain; a different type is reported.
  • Signature: a PGP cleartext signature is detected but not verified.
  • No file: informational, since the file is optional. A redirect on the request is reported without being followed, and no conclusion is drawn from it.

Why the Expires field matters

Expires exists so that outdated contact details disappear instead of lingering. A security.txt listing a mailbox that no longer exists is worse than none: reports go nowhere and researchers may give up or disclose publicly. Pick a date no more than a year ahead and put a reminder on a calendar to refresh it. The tool reports how long the file remains valid.

Who reads security.txt

Researchers, automated scanners and bug-bounty platforms look for the file when they have found a problem and want to know where to send it. Without it they may guess at an address, contact general support, or post publicly. A policy link lets you state scope, expected response times and whether you offer safe harbour, which makes reports more useful. None of this obliges you to pay for reports or to promise outcomes; it simply makes your contact path obvious.

Common problems

  • Expired file, after a one-time set-up.
  • Contact mailbox unmonitored or bouncing.
  • File on the legacy path only, or behind a redirect to a login or error page.
  • HTML served with a 200 status (a soft 404), which looks like a file but is not a valid one.
  • Wrong Content-Type or missing Contact line, making the file invalid.
  • Different hosts: the file exists on www but not on the apex, or conversely.

How to publish security.txt safely

Prerequisites: a monitored contact address, ideally a role mailbox such as [email protected], and agreement on who handles reports. Risk: low; the file is public by design, so publish only addresses and policy links you intend to be public. Rollback: delete the file or update it.

  1. Create a monitored mailbox or reporting page and decide who responds.
  2. Write the file with Contact and Expires, optionally Policy and Preferred-Languages.
  3. Serve it at /.well-known/security.txt over HTTPS as text/plain, on every host that should have one.
  4. Optionally sign it with PGP, and add the Canonical field with the file's own URL.
  5. Re-run this checker, and diary the expiry date.

Limits

Only HTTPS requests to the landing host are made and redirects are never followed. Links inside the file, such as Canonical and Policy, are listed but not requested, and signatures are detected, not verified. The tool cannot test that a contact address actually reaches a person. A valid file does not mean the site is free of vulnerabilities.

Frequently asked questions

Is security.txt required?

No. It is optional, which is why a missing file is informational.

Where must the file be located?

At /.well-known/security.txt over HTTPS. The legacy /security.txt location is also checked.

Does the tool verify the PGP signature?

No. It only detects whether the file is wrapped in a cleartext signature.

How far ahead should Expires be?

Many sites choose under a year, then renew. A short window ensures stale details disappear.

Will publishing it invite attacks?

It is a contact notice, not a vulnerability. Publish only addresses you intend to be public.

Why is a redirect not followed?

The tool does not follow redirects for this file and draws no conclusion from one.

Scope of this tool

  • Only the domain's apex and www host are contacted over HTTPS (and port 80 where stated); redirects to any other host are reported, never followed.
  • Spectra identifies itself honestly and does not imitate a browser, so sites that block automated clients may not show their real headers.
  • A single request path (/) is examined from this scanner's network position; other pages, other nodes of a load-balanced site and other regions may differ.

Written by DNS Tools editorial · Last updated 2026-10-09