No. Under RFC 9116, a security.txt file applies only to the domain or IP address used to retrieve it, not to its subdomains or parent domains. If researchers might report issues on app.example.com, that host should serve its own file or redirect to one.
What the standard says about scope
RFC 9116 states that a security.txt file "MUST only apply to the domain or IP address in the URI used to retrieve it, not to any of its subdomains or parent domains." The RFC's own examples make the point: a file at example.com covers example.com, and a file at subdomain.example.com covers that subdomain alone.
The same section allows a file to also apply to products and services the organization provides, and recommends the Policy field to spell out scope and process. So scope has two layers: the host that served the file, and whatever your policy page adds in words.
Where the file must live
For web services, the file belongs under the /.well-known/ path, for example https://example.com/.well-known/security.txt. For legacy compatibility it may also sit at the top-level path or redirect to the well-known location. If both exist, the well-known one is used.
Three technical rules from the RFC:
- Serve it over HTTPS.
- Use a Content-Type of text/plain with charset utf-8.
- Include Contact and Expires. Both are mandatory.
A practical plan for many hosts
| Your setup | What to publish |
|---|---|
| One marketing domain, one app domain | A file on each host, same Contact |
| Many subdomains, one security team | A file per host, or a redirect from each to one canonical file |
| Customer-facing product on its own domain | A file there, with a Policy link covering the product |
The RFC notes that retrieval may involve redirects and that researchers should check redirects are not pointing at attacker-controlled resources. Keep redirects within domains you own, and point them at the canonical file.
The Canonical field also helps: it lists the URI where the file is meant to be served, which lets a reader confirm the copy they fetched belongs to that location.
Check every host with curl
Run this for each hostname, swapping in your own:
curl -sI https://app.example.com/.well-known/security.txt
curl -s https://app.example.com/.well-known/security.txt
In the header output, look for a 200 status (or a redirect to a host you own) and a content type of text/plain with utf-8. In the body, look for a Contact line and an Expires date in the future. A 404, an HTML page served with a 200, or an expired date all mean the host is not covered in practice. If you want a refresher on the fields, read how to write a security.txt file, and keep the date fresh using security.txt Expires and signing.
Common mistakes
- Publishing only at the apex domain and assuming it covers the app subdomain.
- A single page app that returns its index page for every path, so the file URL answers 200 with HTML.
- A file that expired last year.
- Different Contact values on different hosts, so reports land in different places.
Quick check
Does the apex domain file cover www?
Not automatically. The RFC scopes the file to the exact host used to retrieve it, so serve the file on www too or redirect it to the canonical copy.
Is the root path /security.txt enough?
It is allowed for legacy compatibility, but the RFC says the well-known path must be used if both exist. Publish at /.well-known/security.txt.
Which fields are mandatory?
Contact and Expires. Everything else, including Policy, Encryption and Canonical, is optional.
If you want to see which hosts and components you expose in the first place, Safeguard includes asset discovery, and there is a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
