Most often the file is in the wrong place or served with the wrong headers. RFC 9116 says it belongs under /.well-known/security.txt, served over https with a Content-Type of text/plain and UTF-8 charset. Check the path, the protocol, the header and any redirects, in that order.
What the RFC specifies
The file belongs under the /.well-known/ path. For legacy compatibility it might also exist at the top level path or redirect to the well known location. If both exist, the /.well-known/ copy takes precedence. Serve it over https, as text/plain, in UTF-8.
That is the whole contract. Everything below is a way to check it.
Checklist
- Request https://your-domain/.well-known/security.txt in a browser. Do you see plain text, not a download prompt or an HTML page?
- Check the status code. A 200 is what you want. A 404 or a login redirect means a researcher gives up.
- Check the Content-Type header. It should be text/plain with charset utf-8.
- Check that http redirects to https, not the other way around.
- Check each domain and subdomain you want covered. A file on the main site does not necessarily cover another host.
- Confirm Contact and Expires are present and that the date has not passed.
- If signed, verify the signature on the live copy.
Common causes of failure
| Symptom | Likely cause | Fix |
|---|---|---|
| 404 | File in the web root only, or the dot directory is blocked | Create the well known path and allow it in the server config |
| HTML page returned | Single page app catches every route | Add a route that returns the file as plain text |
| Browser downloads the file | Wrong Content-Type | Set text/plain with charset utf-8 |
| Works in the browser, fails for tools | Bot protection or login in front | Exempt the path from challenges |
| Two different copies | Top level copy out of date | Keep them identical or redirect to the well known copy |
Why this affects customer trust
A buyer's security team often checks for this file during review. If it is missing, expired or broken, it suggests that nobody owns disclosure. Since the fix takes minutes, it is worth testing after every deployment change, such as a new CDN or a rewritten router.
Make it part of release checks
Add a small test to your pipeline that fetches the file and verifies the status, header and presence of both required fields. A failing check is cheaper than a researcher who could not reach you. For the date rule, see the Expires field.
Quick check
Does the file have to be under /.well-known/?
That is the standard location. A top level copy or redirect is allowed for legacy compatibility, and the well known copy takes precedence if both exist.
Can I serve it as HTML?
No. The RFC specifies text/plain with a UTF-8 charset.
Safeguard's asset discovery helps teams find the domains and services they run, which is a good starting list for where a security.txt should exist. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
