security.txt Validator

Paste your security.txt (RFC 9116) content to detect syntax errors. Checks required fields like Contact and Expires and their value formats, so you can confirm it's correctly published at /.well-known/security-text.

Tips

  • The official location for security.txt is /.well-known/security-text. For compatibility, it's also worth publishing a copy at /security.txt (the site root).
  • Write Contact as a URI with a scheme, such as mailto:, https:, or tel:. A bare email address isn't RFC 9116-compliant and may not be recognized by automated parsers.
  • Set Expires no more than a year out, and extend it each time you renew. An expired file risks being treated as an abandoned, unmonitored contact.
  • All validation in this tool runs entirely in your browser — nothing you paste is sent anywhere, so it's safe to check a file before publishing it.

Frequently Asked Questions

RFC 9116 specifies https://example.com/.well-known/security-text as the official location. Many implementations also check the legacy path https://example.com/security.txt, so publishing it in both places is recommended for compatibility.

The file isn't automatically invalidated, but security researchers and automated tools will treat it as stale, unmaintained information, which lowers its trustworthiness. It's recommended to extend the date at least once a year.

No, they're different. security.txt is a contact file that tells researchers who to reach and how — it doesn't define whether a reward exists or how much it is. You can link to a bug bounty page from the Policy or Hiring field, though.

You can write one, but RFC 9116 defines Contact as a URI, so it must carry a scheme, e.g. mailto:[email protected]. Without a scheme, automated parsers may fail to recognize it correctly.

It's not required, but RFC 9116 lists an OpenPGP signature as a recommendation. Signing lets researchers verify that the file's contents haven't been tampered with by a third party.
ツールくん

Side Note — The origin of security.txt — the "first point of contact" that bug bounties alone couldn't provide

security.txt was proposed in 2017 by security researchers Ed Overflow and Kagan Baytas. At the time, researchers who found a vulnerability often had no clear way to report it, ending up stuck with a general contact form or a direct message on social media. Reports frequently took a long time to reach the right person, or were simply ignored.

The proposal was brought to the IETF (Internet Engineering Task Force), and after years of discussion and revision it became an official standard as RFC 9116 in 2022. The mechanism is simple: a site operator publishes a single text file at /.well-known/security-text, and researchers can mechanically determine who to contact, in what language, and under what policy.

Major tech companies including GitHub, Google, Facebook, and LinkedIn have all adopted security.txt, and it's common to see a link to a vulnerability disclosure or bug bounty program surfaced via the Policy field. It effectively serves as a "front door" reaching researchers who might never discover a bug bounty platform on their own.

As a natural extension of RFC 9116, a growing number of organizations link to CSAF (Common Security Advisory Framework) documents via the CSAF field, standardizing how vulnerability advisories are exchanged. security.txt is no longer just a contact file — it continues to evolve into an entry point for an organization's entire security response process.