What is security.txt?

security.txt (RFC 9116) is a plain-text file at a fixed, predictable location that tells a security researcher who finds a vulnerability how to actually report it - who to contact, in what language, and under what disclosure policy. Without one, a researcher has to guess: an abuse@ address, a generic contact form, a tweet - all slower and less reliable than a file built for exactly this purpose.

Where it has to live

The canonical location is /.well-known/security.txt. An earlier draft of the RFC also allowed a bare /security.txt at the site root; that's now deprecated but still checked here as a fallback, since some older tooling still only looks there.

Two fields are required, not optional

Contact (at least one, in order of preference - a mailto: address, an https: report form, or similar) and Expires (an ISO 8601 date-time). The expiry date matters more than it might seem: RFC 9116 says an expired file should be treated as no longer valid at all, on the reasoning that an unmaintained file's contact details may no longer be monitored - a stale security.txt is arguably worse than none, since it looks current without actually being current.

More than one (sub)domain? A redirect works too

RFC 9116 section 3 explicitly allows a domain's /.well-known/security.txt to redirect to another domain's file instead of publishing its own - a signed, correctly-configured redirect is treated the same as having the file directly. For an organisation running several subdomains, that usually beats keeping a separate file in step on each one: redirect every subdomain's own well-known path to a single, central file instead, for example with a line like this in the subdomain's own .htaccess:

Redirect 301 /.well-known/security.txt https://example.com/.well-known/security.txt

The Check tab above already follows a redirect like this (up to five hops) and validates whatever it actually lands on, so testing a redirecting subdomain here works exactly as expected.

What the Wizard does, and doesn't, check

This assembles a starting file from what's filled in below - it doesn't verify a contact address is reachable, doesn't check a linked policy page actually exists, and doesn't validate a PGP signature if one is added. Those are all things worth confirming yourself before publishing.

RFC references

  • RFC 9116 - A File Format to Aid in Security Vulnerability Disclosure (security.txt)

security.txt