Protect the origin and constrain discovered policy
04A predictable path is visible to browsers and can affect an origin. Shared hosting, injected scripts and guessed cross-origin scope create risks.
No application rule authorizes this metadata to control department.api.example or a different port. The example’s proposed extension stops at the scope check.
Source for this drawing: RFC 8615 · Read RFC section 4.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
- Origin
- For the depicted HTTPS URIs, scheme, hostname and effective port together.
- Injected script
- Attacker-controlled code running in content on the origin, for example through cross-site scripting.
- ACL
- Access-control list: a deployment’s rules for who may read or write.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Control who can write discovery data; the path itself is neither isolation nor proof of authority over other origins.
- Operators should control writes to well-known resources, including local filesystem and external server permissions. Shared origins need particular care. A dot-prefixed directory can be hidden from an administrator’s normal listing while remaining writable to an attacker; hidden is not protected.
- HTTP(S) resources are accessible to browsers. Content injected elsewhere on the same origin can make requests to them. Applications cannot assume exclusive access to the origin’s cookies, storage or capabilities. Merely using a special path does not create an application security boundary.
- Section 4.2 discusses context-dependent mitigations: protect sensitive data, avoid identifier collisions, consider HttpOnly and cookie Path, nosniff, application-specific media types with client failure on mismatch, CSP and Referrer-Policy, and avoid compression of sensitive values. These are not a universal mandatory checklist. Cookie Path alone is not shown as isolation from same-origin malicious script.
- Application discovery and scope must be specified. Extending metadata to a different hostname, scheme or port without a justified application rule assumes authority that may not exist. The example refuses that inference rather than claiming all cross-origin metadata use is prohibited.
- Applications and deployments also need to consider sensitive-data exposure, authentication of server/client, DNS rebinding, denial of service and limited server access affecting discovery data. Bootstrapping another protocol by blindly probing Web servers can flood origins that do not implement it.
For these HTTPS examples, an origin is the scheme/host/effective-port triple (RFC 6454 §§4–5). https://api.example uses port 443; https://department.api.example and https://api.example:8443 are different origins. An example ACL stops a tenant’s write in step 1. Step 2 deliberately illustrates the different risk that same-origin injected script can request the resource; it does not assert that every request is authorized or succeeds. Step 3 refuses an unjustified policy extension, not a network request. No live credentials, accounts or requests to example hosts are used.
Read the RFC section ↗