security.txt Checker Guide
Use this guide to understand what the security.txt Checker is validating, what fields matter most, and how to publish a disclosure file that is clear, current, and reachable to researchers.
Overview
A valid security.txt file helps researchers know how to contact you and how you expect disclosure to work. The checker is looking for missing required fields, stale expiry dates, inconsistent locations, and weak publication hygiene.
What matters most in practice
- Contact: Give researchers a usable reporting path, not a dead mailbox or generic form with no security context.
- Expires: A stale file quickly looks abandoned, even if the rest of the content is valid.
- Location: Serve it from a standard reachable path and avoid conflicting copies.
Fields and Why They Matter
| Field | Expected use | Common issue |
|---|---|---|
| Contact | Primary security reporting channel | Mailbox is missing, dead, or routed into a general queue. |
| Expires | Signals freshness of the file | Date is in the past or never reviewed after launch. |
| Policy | Links to disclosure expectations | Policy URL is broken, vague, or missing. |
| Acknowledgments | Optional credit page for researchers | Present but stale or inconsistent with the real process. |
Example security.txt Files
Contact: mailto:security@example.com
Policy: https://example.com/security-disclosure-policy
Acknowledgments: https://example.com/security-hall-of-fame
Expires: 2026-12-31T23:59:59.000Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txtlocation = /security.txt {
return 301 https://example.com/.well-known/security.txt;
}Recommended Remediation Flow
- Publish one authoritative file Use a standard reachable location and avoid conflicting copies with different contact details.
- Review the contact path operationally Make sure the mailbox or ticket route is monitored and has a defined owner.
- Set and maintain a realistic expiry date Use expiry to prove the file is maintained, not just left behind after launch.
- Retest from the public edge Confirm the file is reachable, current, and not blocked by redirect or content-type issues.
Troubleshooting Common Issues
The file exists but the checker still flags it
The most common causes are stale Expires values, incorrect formatting, or publication at only one non-standard path.
- Check the final public URL and content body exactly as served.
- Review date formatting and line structure for syntax issues.
- Make sure a redirect does not land on an unrelated support page.
Researchers keep using the wrong contact path
That often means the file, disclosure policy, and site-wide contact messaging are inconsistent.
- Use the same reporting path across security.txt and your disclosure policy.
- Avoid generic support-only wording if security reports need a dedicated queue.
- Update stale hall-of-fame or policy links that imply a different process.
Validation Checklist
Post-fix validation
- Confirm the public file is reachable and returns the intended content.
- Verify Contact, Expires, and Policy reflect the real disclosure process.
- Check for conflicting copies at root and /.well-known paths.
- Run the security.txt Checker again and compare the result against the published file.
FAQ
Do small sites still need security.txt?
If you have a public web presence and want coordinated disclosure, it is still useful.
- It creates a clear security reporting path.
- It reduces ambiguity for researchers and automated discovery tools.
- It does not need a large bug bounty program to be worthwhile.
Should the file live only under /.well-known?
That is the preferred standard location. A root redirect can still be helpful for compatibility.
- Keep one authoritative version.
- Avoid serving different content at multiple locations.
- Validate the final public path after redirects.