Application paths

Application paths define the URLs protected by an Access policy. When adding a self-hosted application to Access, you can choose to protect the entire website by entering its apex domain, or alternatively, protect specific subdomains and 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 dasard.com/eng that anyone on the engineering team should be able to access. However, a tool deployed at dasard.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 dasard.com/eng and dasard.com/eng/exec separately, the more specific rule for dasard.com/eng/exec takes precedence, and no rule is inherited from dasard.com/eng. If no separate, specific rule is set for dasard.com/eng/exec, it will inherit any rules set for dasard.com/eng.

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 are creating to multiple subdomains or paths in a given apex domain.

Using a wildcard in the Subdomain field does not cover the apex domain.

Application	Covers	Does not cover
*.example.com	alpha.example.com beta.example.com	example.com

To protect an apex domain and all of the paths under it, leave the Path field empty. Alternatively, use a wildcard in the Path field.

Application	Covers	Does not cover
example.com or example.com/*	example.com example.com/alpha example.com/beta	alpha.example.com

Using a wildcard in the Subdomain field does not cover the parent subdomain nor the apex domain.

Application	Covers	Does not cover
*.test.example.com	alpha.test.example.com beta.test.example.com	test.example.com example.com

Using a wildcard at the beginning or end of the Subdomain field does not cover multiple levels of the subdomain.

Application	Covers	Does not cover
*test.example.com	test.example.com alphatest.example.com	beta.test.example.com

Using a wildcard in the Path field does not cover the parent path nor the apex domain.

Application	Covers	Does not cover
example.com/alpha/*	example.com/alpha/one example.com/alpha/two	example.com/alpha example.com

Using a wildcard in the middle of the Path field covers multiple segments of the URL.

Application	Covers
example.com/foo*/bar	example.com/foo/bar example.com/food/bar example.com/food/stuff/bar

• At most one wildcard in between each dot in the Subdomain. For example, foo*bar*baz.example.com is not allowed.
• At most one wildcard in between each slash in the Path. For example, example.com/foo*bar*baz is not allowed.

Subdomain setups allow you to manage a child domain separately from its parent domain. In Access application paths, your configured child domains will appear in the Domain dropdown menu. If you split out a subdomain which already has an Access application, you will need to re-save the Access application to associate it with the new child domain.

Port numbers are not supported in Access application paths. If a request includes a port number in the URL, Access will strip the port number and redirect the request to the default HTTP/HTTPS port.

Query strings (such as?foo=bar) are not supported in Access application paths.

Since anchor links are processed by the browser and not the server, Access applications do not support # characters in the URL. For example, requests to dasard.com/#settings will redirect to dasard.com.