Respect host scope and Canonical locations
05A file retrieved for one host does not automatically cover related hosts. The optional Canonical field lists intended retrieval URIs and can help detect a copied or misplaced file, but does not by itself establish trust in every listed location.
At sub.example.com the copied file still lists only example.com as Canonical. The mismatch triggers the SHOULD NOT trust guidance before a report is sent.
Source for this drawing: RFC 9116 · Read RFC section 3.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Host scope
- Which domain or IP the retrieved file applies to.
- Canonical
- An optional list of intended file locations, not automatic cross-host authorization.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A security.txt file MUST apply only to the domain or IP address in its retrieval URI, not its parent domains or subdomains. It MAY also apply to the publishing organization’s products and services.
- A security.txt file MUST apply only to the domain or IP address in its retrieval URI, not its parent domains or subdomains. It MAY also apply to the publishing organization’s products and services.
- For example.com, the file is not automatically inherited by sub.example.com or www.example.com. The organization SHOULD use Policy to explain the scope and details of its disclosure process.
- Canonical is optional and can repeat. Web Canonical values MUST begin with https://. If Canonical appears and the retrieval URI is absent from all its values, the contents SHOULD NOT be trusted.
- A listed Canonical URI MUST NOT be interpreted to make the file apply to every canonical location listed. Researchers SHOULD use an additional trust mechanism, such as a digital signature, to decide that a particular URI is applicable.
- A redirect does not justify blindly trusting a new host. Inspect the redirect chain and the resulting file’s location and trust context before using its contacts.
The diagram separately tests host scope and exact fictional Canonical URI membership. It is not a general URL-normalization algorithm, proof of domain ownership, wildcard delegation or permission to test subdomains. A matching Canonical value passes one necessary context check; it does not authenticate the signer or the reporting destination.
Read the RFC section ↗