Access policies allow you to protect an entire website or a particular URI (the Application Resource). Policies also define the users or groups who can, or cannot, access the Application Resource.
You can configure an access policy for an apex domain, a particular subdomain, or all subdomains using a wildcard policy.
Similarly, you can apply an access policy to an entire website or protect a specific path. If you want to protect the entire website, leave the PATH field empty. You can also specify paths, for example
/admin as shown in the example above.
Access does not support overlapping definitions. For example, if you set policies for
/admin/specific separately, /admin/specific will not inherit the policy set for
Access does not support port numbers in the URL. Requests to URLs with port numbers will be redirected to the URL with the port number stripped.
Cloudflare Access enforcement consists of two tiers: policies and rules. Policies define how a decision will be enforced. Rules define who meets the criteria of a policy decision.
Allow policies provide access to a user or group to the application. Users who meet the criteria in the Rules defined for a given Allow policy will be granted permission to reach the application.
Allow policies can contain Exclude and Require rules to enforce more granular controls.
Example: An Allow policy contains an Include rule that defined as “Emails Ending In: @example.com”. Any user with an @example.com email address, as validated against an IdP, will be permitted to reach the application. Adding a Require rule in the same policy will enforce additional checks. If the Require rule defines a set of IP Ranges, then a user must be both a member of “@example.com” and their request must originate from the IP range defined. Finally, if the policy also contains an Exclude rule, users who meet that definition will be prevented from reaching the application. If the Exclude rule defines a single email, “[email protected]”, then all users who are in @example.com and in the IP range will be granted access except for “[email protected]”.
Deny policies explicity prevent users from reaching an application behind Access. Deny policies enforce similar behavior to Allow policies that contain an Exclude rule without the need to allow specific users.
Example: A Deny policy that contains an Include rule defined as “Everyone” will restrict access to any requests that attempt to reach the application.
This policy is used to bypass Access for a specific path of the application or for the entire application. Bypass policies disable any Access enforcement on the given path.
Example: You have a website secured with Access. However, a third-party service needs access to a specific endpoint. You can configure traffic to bypass Access to hit that particular endpoint. You can whitelist a range of IP addresses to bypass Access or allow all traffic by setting the policy to include “Everyone”.
If the service does not publish its IP range, or they change periodically, you can include “Everyone” in the bypass policy to allow traffic from any request to bypass Access and hit the specified path.
When configuring bypass to allow request to a specific page, while the entire site or other pages are protected, be sure to store your assets in the path to be bypassed. Otherwise, Access will allow traffic to that page but will not retrieve assets stored in protected locations.
Note: When a bypass policy is applied, the security settings revert to the defaults configured for the zone and any page rules applied. If “Always use HTTPS” is enabled for the site, then traffic to the bypassed destination will continue to be HTTPS. If it is not, or you have applied page rules to disable it, traffic will be HTTP.
Non Identity policies enforce authentication flows that do not require an identity provider login, like service tokens and mutual TLS.
Access policies trigger in an order based on their position in policy table in the UI, with the exception of bypass policies - Access will evaluate Bypass policies first.
For Allow and Deny policies, Access will enforce the decision starting at the top of your list and moving down. You can modify the order by dragging and dropping individual policies in the UI.
You can create unique policies for parts of your application that share a root path. When multiple policies are set for a common path root, they do not inherit rules. Instead, the more specific policy takes precedence.
dashboard.com/eng/execthat only your executive team should be able to reach.
dashboard.com/eng/execthe more specific policy takes precedence. The
/execpath will be gated by “Policy B” instead of relying on the rules in “Policy A.”
Cloudflare Access can secure any subdomain of your apex domain using a wildcard policy. To create a wildcard policy, input an “*” in the subdomain field in the policy generator.
The wildcard subdomain does not cover the apex domain itself. For example, a policy that controls access in the following format:
This format will cover “alpha.example.com”, “beta.example.com”, but not “example.com”. However, you must create a separate policy for the apex domain.