Application paths

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 and 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 dashboard.com/eng.

In the Zero Trust dashboard, when adding a self-hosted web application, 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.