security.txt (RFC 9116)

What the scanner requests

• /.well-known/security.txt
• /security.txt

What is measured

The scanner requests /.well-known/security.txt, falls back to /security.txt while following redirects, and expects HTTP 200 with a text/plain body as RFC 9116 requires. It passes when the file carries a Contact field and an Expires field whose RFC 3339 timestamp is in the future, returns partial when one of those fields is missing or Expires is malformed or already past (the file is then stale), and fails when both paths answer non-200 or return HTML.

Reproduce it yourself

You do not have to take our word for any of this. Run the same measurement against your own domain:

              DOMAIN="example.com"
for P in /.well-known/security.txt /security.txt; do echo "$P -> $(curl -sS -o /dev/null -w '%{http_code} %{content_type} %{redirect_url}' "https://$DOMAIN$P")"; done; curl -sSL "https://$DOMAIN/.well-known/security.txt" | grep -Ei '^(contact|expires|canonical|policy|preferred-languages):'
            

The fix

This is the artifact to ship. It is the complete change, not a description of one.

              # security.txt - RFC 9116
Contact: mailto:security@example.com
Expires: 2027-09-30T18:37:07Z
Canonical: https://example.com/.well-known/security.txt
Preferred-Languages: en
Policy: https://example.com/security-policy
Acknowledgments: https://example.com/hall-of-fame
            

Standards referenced

• RFC 9116

Related checks