Recheck the full Cloudflare Access policy when adding a more specific application path

A child-path application can replace the parent policy instead of adding another restriction.

Source facts

Cloudflare Access allows different applications and policies for paths under one hostname. When a more specific path has its own rule, that specific rule takes precedence and does not inherit the parent path’s rule. If no separate child rule exists, the parent rule applies. The documented wildcard behavior also has boundaries: a subdomain wildcard does not include the apex or every nested subdomain level, and a path wildcard can omit its parent path. Query strings and browser anchor fragments are not supported application-path selectors.

Source: Cloudflare — Application paths.

Applicability

This applies to Cloudflare Access self-hosted application URL matching. An application’s internal routing and authorization can impose additional requirements and must be reviewed independently.

DSE recommendation

DSE recommends listing the URLs users actually visit, including parent pages, child pages, API calls, and static resources, before splitting policies. Reproduce every required identity and posture condition in the specific application rather than assuming inheritance. Record the intended boundary for wildcard paths and subdomains. Keep publicly reachable exceptions separate from sensitive endpoints. Have the application owner review redirects and alternate entry points so a technically valid Access rule does not leave an unintended route outside the protected set.

Verification

Use test accounts to exercise the parent URL, exact child path, a descendant path, and relevant sibling URLs. Include apex and nested hostnames where wildcards are used. Confirm the matched application and decision for each case, rather than relying on one successful browser login.

Official reference

Cloudflare — Application paths. Reviewed October 15, 2026.