Security.txt: practical fix guide

Security researchers occasionally find something important and then lose time hunting for the right person to tell. security.txt gives them a standard reporting route at /.well-known/security.txt.

It is not a security shield, a bug bounty promise, or permission to test a site. It is a small, useful signpost. The important bit is that the contact route is real, monitored, and kept current.

What Scavo checks

Scavo requests https://your-domain/.well-known/security.txt and checks that:

• the endpoint returns 200 over HTTPS;
• the response is UTF-8 plain text;
• at least one valid Contact URI is present;
• there is exactly one future Expires date in RFC 3339 format; and
• any Canonical values are HTTPS URLs and include the URL that served the file.

A missing file is shown as an opportunity, not a broken website. A warning means a file is published but could misdirect a researcher, for example because its mailbox is missing, its expiry date has passed, or a custom error page is being returned instead of plain text.

• Scan key: security_txt
• Category: SECURITY

Why this matters

A clear reporting route can be the difference between a useful private heads-up and a vulnerability sitting unreported. It also removes guesswork for whoever receives the report: the file can point to your disclosure policy, preferred language, and encryption key.

There is an operational catch. Publishing a forgotten mailbox is worse than looking organised. Give the address an owner, test it occasionally, and renew the Expires value as part of the same routine.

If you are not technical

1. Decide who should receive vulnerability reports. This may be your developer, hosting team, IT provider, or an internal security owner.
2. Ask them to publish a short security.txt file at the standard well-known URL.
3. Send a test message through the first contact route and confirm somebody sees it.
4. Put the expiry date in the team's calendar, ideally with time to review the details before it lapses.
5. Run Scavo again and check the live response, not just the file in a code repository.

Scavo found that our security_txt check needs attention. Please publish or correct the RFC 9116 file at /.well-known/security.txt, use a monitored Contact URI, include exactly one future Expires value, return UTF-8 text/plain over HTTPS, and share the live URL once verified.

If you are technical

A useful unsigned file can stay very small:

Contact: mailto:[email protected]
Contact: https://example.com/security-report
Expires: 2027-06-30T12:00:00Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy

Use an expiry less than a year ahead where practical; RFC 9116 recommends this to reduce stale information. If you list more than one contact, put the preferred route first.

Common mistakes

• Publishing /security.txt at the site root but not the required well-known location.
• Returning an HTML page, challenge page, or branded soft 404 with status 200.
• Writing [email protected] instead of the URI form mailto:[email protected].
• Letting Expires pass while the file remains publicly available.
• Adding a Canonical URL that does not exactly identify the file being served.
• Pointing at a shared inbox that nobody actively monitors.

How to verify

curl -i https://example.com/.well-known/security.txt

Confirm the final response is HTTPS, returns 200, declares Content-Type: text/plain; charset=utf-8, and contains current Contact and Expires fields. Then test the first contact route and re-run Scavo.

Add a lightweight scheduled check for the endpoint and an expiry reminder. The file is deliberately simple, so it should not need heroic maintenance.

What this scan cannot confirm

• Scavo cannot prove that somebody reads or responds to the published contact route.
• A valid file does not mean the site is secure or that a formal disclosure programme exists.
• Automated validation cannot decide whether the policy, scope, response targets, or legal wording suit your organisation.
• The file applies to the host it was retrieved from, not automatically to every subdomain.

Sources

• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
• RFC 8615: Well-Known Uniform Resource Identifiers
• CERT Guide to Coordinated Vulnerability Disclosure