When a researcher, customer or another IT provider notices a security problem with a website, the hardest part is often finding out who to tell. security.txt is a small text file, standardised in RFC 9116, that answers that question in a predictable place.
A complete example
Contact: mailto:security@example.com
Expires: 2027-10-01T00:00:00Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policyThe fields
- Contact (required, can repeat): a
mailto:,https:ortel:address. Use a shared mailbox, not one person's address. - Expires (required, once): when the file should be considered out of date. RFC 9116 recommends less than a year ahead, so set a reminder to update it.
- Preferred-Languages: languages you can read reports in.
- Canonical: the URL where the file officially lives, which helps if it is copied.
- Policy: a page explaining how you handle reports.
- Encryption, Acknowledgments, Hiring: optional extras most small businesses can skip.
The file can be signed with OpenPGP, which proves it has not been tampered with. That is optional and rarely needed for a small business.
Where to put it
Serve it at https://example.com/.well-known/security.txt as text/plain. On most hosts that means creating a .well-known folder in the web root. WordPress users can upload it there by SFTP or use a small plugin. Repeat for any subdomain that runs its own site.
Handling the reports
Publishing a contact is a promise to read it. For a small business, a simple process is enough:
- Route the mailbox to the business's IT provider as well as the owner.
- Acknowledge reports within a few working days.
- Be wary of messages that demand payment for a "vulnerability" before giving details. Genuine reporters usually share the problem first.
- Fix, then thank the reporter.
How it shows up in a Hookgap report
Hookgap requests /.well-known/security.txt once per check. A missing file is reported as information only and does not affect the grade, because it is good practice rather than a gap. It is still a nice, easy item for an MSP to include when hardening a client's site, alongside security headers.
Frequently asked questions
Is security.txt required?
No law requires it for small businesses, but it is a published standard (RFC 9116) and some government and industry guidance recommends it. It costs nothing and helps people who find a problem tell you instead of posting it.
Where does security.txt go?
At /.well-known/security.txt on each host, served over HTTPS as text/plain.
What fields are required in security.txt?
Contact (how to reach you) and Expires (a date after which the file should be considered stale). Everything else is optional.
Keep reading
Guide · 12 min read
Website security headers explained for small business sites
Each header in plain English, a safe starting value, how to add it on common hosts, and how to avoid breaking the site.
Guide · 10 min read
Domain and DNS security checklist for small businesses
Twelve checks that keep a business's domain, website and email in the right hands, in the order an MSP should work through them.
mixed content fix · 5 min read
Mixed content warnings: what they mean and how to fix them
Why a padlock disappears, which mixed content browsers block, and how to find and fix every http:// reference.