Cloudflare Zero Trust allows you to create unique rules for parts of an application that share a root path. Imagine an example application is deployed at
dashboard.com/eng that anyone on the engineering team should be able to access. However, a tool deployed at
dashboard.com/eng/exec should only be accessed by the executive team.
When multiple rules are set for a common root path, the more specific rule takes precedence. For example, when setting rules for
dashboard.com/eng/exec separately, the more specific rule for
dashboard.com/eng/exec takes precedence, and no rule is inherited from
dashboard.com/eng. If no separate, specific rule is set for
dashboard.com/eng/exec, it will inherit any rules set for
In the Zero Trust dashboard, when adding a , you can choose to protect the entire website by entering its apex domain, or alternatively, you can specify any subdomains and paths in the dedicated fields.
Using wildcards in subdomains and paths
When you create an application for a specific subdomain or path, you can use asterisks (
*) as wildcards. Wildcards allow you to extend the application you’re creating to all the subdomains or paths of a given apex domain.
This is how to use wildcards effectively:
Protect all subdomains of an apex domain
Using a wildcard in the subdomain field does not cover the apex domain.
Protect all paths of an apex domain
If you want to protect an apex domain and all of the paths under it, leave the path field empty.
To protect all the paths under an apex domain, but not the apex domain itself, use a wildcard in the path field.
Protect multi-level subdomains
Using a wildcard in the subdomain field to protect multi-level subdomains does not cover that subdomain’s top subdomain nor the apex domain.
Protect multi-level paths
Using a wildcard in the path field to protect multi-level paths does not cover that subpath’s parent path nor the apex domain.