The security.txt File Explained
A simple, standardized way for security researchers to find out how to responsibly report a vulnerability.
Core Concept
security.txt is a standardized text file, published at a predictable location, that tells security researchers how to responsibly report vulnerabilities to an organization.
Without it, researchers often struggle to find the right contact, sometimes resorting to public disclosure or generic support channels that delay proper handling.
Standard File Location and Format
The file follows a defined specification for both location and structure.
- Published at /.well-known/security.txt
- Plain text format with defined field names
- Optionally digitally signed for authenticity verification
Predictable Location
Placing the file at a standardized, well-known path means researchers and automated tools alike can find it without needing to search.
Key Fields in a security.txt File
A well-formed file includes several standardized fields to guide reporters.
- Contact — how to reach the security team
- Expires — when the file's information should be considered stale
- Policy — link to a full vulnerability disclosure policy
Why Responsible Disclosure Channels Matter
A clear reporting path benefits both the organization and the security research community.
Researchers who can't find a proper channel sometimes default to public disclosure, which can expose an unpatched vulnerability to a wider audience unnecessarily.
Reducing Premature Disclosure
A clear, working disclosure channel reduces the chance a researcher defaults to public disclosure simply out of frustration finding the right contact.
Maintaining the File Over Time
Like any security infrastructure, security.txt needs periodic upkeep to remain useful.
- Keep contact information current as teams change
- Update the expiration date regularly
- Verify the file remains accessible and correctly formatted
Real-World Implementation
security.txt adoption has grown steadily as a lightweight, standardized security practice.
- Major tech companies publishing detailed security.txt files
- Bug bounty programs linking directly from their security.txt
- Security scanners checking for its presence as a baseline maturity signal
For the minimal effort required to publish and maintain, security.txt meaningfully improves how quickly and safely vulnerabilities reach the right people.
Common Mistakes to Avoid
A few common mistakes reduce the usefulness of a published security.txt file.
- Publishing the file once and never updating contact information as teams change.
- Letting the expiration date lapse without renewing it.
- Placing the file somewhere other than the standardized well-known location.
- Omitting a link to a full vulnerability disclosure policy.
- Failing to verify the file remains accessible after infrastructure changes.
- Overlooking the digital signature option that adds authenticity verification to the file.
- Assuming a security.txt file, once published, never needs to be revisited.
- Failing to test that the published file is actually accessible at the standard path.
- Overlooking the Canonical field, which specifies the authoritative location of the file.
- Assuming security.txt alone is sufficient without an actual staffed response process.
- Failing to test the published contact channel periodically to confirm it's still monitored.
- Overlooking that some organizations forget to update the file after a security team restructuring.
Best Practices Checklist
These practices keep a security.txt file genuinely useful over time.
- Keep contact information current as security team responsibilities change.
- Update the expiration date on a regular recurring schedule.
- Publish the file at the standardized /.well-known/security.txt location.
- Link to a full, detailed vulnerability disclosure policy where possible.
- Verify the file remains accessible after any infrastructure or hosting change.
- Consider digitally signing the security.txt file for added authenticity assurance.
- Schedule periodic review of the file rather than treating it as permanently set.
- Verify the file is genuinely accessible at /.well-known/security.txt after publishing.
- Include the Canonical field to specify the file's authoritative location clearly.
- Ensure a genuinely staffed response process backs up the published security.txt contact.
- Periodically test the published contact channel to confirm it remains actively monitored.
- Include security.txt updates as a checklist item during any security team restructuring.
Frequently Asked Questions
Frequently asked questions about the security.txt file.
Where should security.txt be published?
At the standardized location /.well-known/security.txt, so researchers and automated tools can find it without needing to search.
What happens if security.txt information goes stale?
An outdated file with expired timestamps and old contact information can misdirect well-intentioned reports, sometimes worse than having no file at all.
Why does security.txt reduce premature public disclosure?
A clear, working reporting channel reduces the chance a researcher defaults to public disclosure simply out of frustration finding the right contact.
Can security.txt be digitally signed?
Yes — signing adds an authenticity verification layer, helping researchers confirm the file is genuinely published by the organization.
Is security.txt adoption common among major companies?
Yes — it's grown steadily as a lightweight, standardized practice, with many major tech companies publishing detailed files.
Can a security.txt file be digitally signed?
Yes — signing it adds an authenticity guarantee, helping researchers trust that the file genuinely came from the organization.
Does security.txt need ongoing maintenance after initial publication?
Yes — contact information and the expiration date should be reviewed and updated periodically to stay useful.
How can I confirm my security.txt file is properly published?
Directly requesting the standard path, /.well-known/security.txt, confirms whether it's accessible as expected.
What does the Canonical field in security.txt specify?
It identifies the authoritative URL for the file itself, helping prevent confusion if multiple copies or cached versions exist.
Is publishing security.txt enough without a response process behind it?
No — the file is only useful if a genuinely staffed process exists to receive and act on reports submitted through it.
Should security.txt be updated after a team restructuring?
Yes — outdated contact information following a reorganization can misdirect legitimate researcher reports to the wrong destination.
Check for a security.txt File
Run a security headers scan to check whether a domain publishes a security.txt file.
Launch Tool →