Written by the HackerMe team (Agura); we build HackerMe, an automated website security scanner. The first four checks only read a public file.
Someone finds a problem on your site: an exposed file, a misconfigured header, a login bug. They want to tell you. Where do they go? A contact form that routes to sales? A generic info@ inbox? A social media account?
RFC 9116 answers that with a small text file at a fixed location: /.well-known/security.txt. It does not fix anything by itself. It makes the first step of a responsible report predictable. Here are six checks for setting it up and keeping it honest.
1. Is the file where clients will look? (safe on any public site)
curl -s -D headers.txt -o security.txt https://example.com/.well-known/security.txt
head -1 headers.txt; grep -i '^content-type' headers.txt; head security.txt
You want a 200, a text/plain content type, and the file over HTTPS; RFC 9116 places it under /.well-known/ and requires HTTPS. Look at the body too: some sites answer every path with 200 and an HTML error page, or redirect to the homepage, which is not a security.txt.
2. Does it have the two required fields? (safe on any public site)
RFC 9116 requires Contact and Expires. A minimal file:
Contact: mailto:security@example.com
Expires: 2027-10-31T22:00:00.000Z
Preferred-Languages: en, he
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy
At least one Contact (a mailto:, tel: or https: URI) and exactly one Expires: the RFC says Expires must always be present and must not appear more than once. A file with only a contact, or with several expiry dates, needs fixing. Open each URI in the optional fields as well; nothing checks that they lead somewhere real.
3. Has it expired? (safe on any public site)
The RFC recommends an Expires value less than a year into the future, so stale files are noticeable. Compare the value with today's date.
A date in the past tells researchers the information may be out of date. Put the renewal in the same calendar as your domain and certificate renewals.
4. Does Canonical match where it is served? (safe on any public site)
Canonical is optional. If you use it (useful when you sign the file or serve it on several hosts), it lists the URIs where this exact file lives, and the RFC says that when Canonical fields are present and none of them matches the URI the file was retrieved from, the contents should not be trusted. A file with no Canonical field is still valid; a Canonical pointing at a different domain, a staging host or http:// is the problem.
It also does not say anything about subdomains. Per the RFC, a file applies to the host it is served from; shop.example.com needs its own file or a redirect you have thought through.
5. Signed or not? (maintainer check)
The RFC recommends signing the file with an OpenPGP cleartext signature. It is optional. If you sign, publish the signing key somewhere you control and re-sign every time you edit the file. Do not treat the Encryption field as the signing key: it points to a key for encrypting reports to you, and RFC 9116 warns researchers not to assume that key is the one used for the signature. A signature that no longer verifies is worse than none, because it trains readers to ignore failures.
6. Does a message to the contact reach a person? (maintainer check)
This is the check no scanner can do for you. Send a test message to the listed address from outside your organization and confirm:
- it is not caught by a spam filter,
- it reaches more than one person,
- someone knows what to do next.
The OWASP Vulnerability Disclosure Cheat Sheet recommends a clear process for receiving and handling reports. The file only helps if that process exists behind it.
What security.txt does not do
- It does not make a site safer. It is a contact card.
- It does not grant permission to test your site unless your policy says so. If you have rules for researchers, put them on the
Policypage. - A valid file is not evidence that reports are handled well.
About us
HackerMe runs automated checks from the outside on a domain you own or have explicit permission to test. It sees only what your server returns, so treat its results as a starting point. https://brandingme.ai/app/r/1s5brArmi4E9vtT-nWbcZg
Sources
- IETF, RFC 9116, A File Format to Aid in Security Vulnerability Disclosure: https://www.rfc-editor.org/rfc/rfc9116
- securitytxt.org (project site by the RFC authors): https://securitytxt.org/
- OWASP, Vulnerability Disclosure Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html
Comments
Join the discussionNo comments yet. Be the first to comment.
