From 4dbb85a6e47ee9ac7f7a898ba74840420c04b214 Mon Sep 17 00:00:00 2001 From: Max Phillips Date: Thu, 26 Jun 2025 17:01:10 -0500 Subject: [PATCH 1/6] Add DLP caveat --- .../cloudflare-one/gateway/order-of-enforcement.mdx | 4 +++- .../cloudflare-one/gateway/order-of-precedence.mdx | 11 ++++++----- 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx index 8e644fb54c6d6ec..69de0a1a2040c7a 100644 --- a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx +++ b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx @@ -198,7 +198,9 @@ The only exception is if you are using [Clientless Web Isolation](/cloudflare-on Next, Gateway checks decrypted traffic against your Isolate policies. When a user makes a request which triggers an Isolate policy, the request will be rerouted to a [remote browser](/cloudflare-one/policies/browser-isolation/). -Lastly, Gateway evaluates all Allow, Block, and Do Not Scan policies. These policies apply to both isolated and non-isolated traffic. For example, if `example.com` is isolated and `example.com/subpage` is blocked, Gateway will block the subpage inside of the remote browser. +Next, Gateway evaluates all Allow, Block, and Do Not Scan policies. These policies apply to both isolated and non-isolated traffic. For example, if `example.com` is isolated and `example.com/subpage` is blocked, Gateway will block the subpage inside of the remote browser. + +Lastly, Gateway evaluates the body of the HTTP request by evaluating DLP policies and running anti-virus scanning and file sandboxing. If DLP policies are present, the action Gateway takes may not [match its logs](#dlp-policy-precedence). ### Resolver policies diff --git a/src/content/partials/cloudflare-one/gateway/order-of-precedence.mdx b/src/content/partials/cloudflare-one/gateway/order-of-precedence.mdx index e4d121b39a38019..2a71d196e0f99ae 100644 --- a/src/content/partials/cloudflare-one/gateway/order-of-precedence.mdx +++ b/src/content/partials/cloudflare-one/gateway/order-of-precedence.mdx @@ -1,14 +1,15 @@ --- inputParameters: param1 - --- -import { Markdown } from "~/components" - Order of precedence refers to the priority of individual policies within the {props.one} policy builder (lowest value first, or from top to bottom as shown in the dashboard). You can modify the order of precedence by dragging and dropping individual policies in the dashboard. In Gateway, the order of precedence follows the first match principle — once a site matches an Allow or Block policy, evaluation stops and no subsequent policies can override the decision. Therefore, Cloudflare recommends putting the most specific policies and exceptions at the top of the list and the most general policies at the bottom. -If Gateway traffic is headed to a private IP address protected as an Access application, that traffic will still be evaluated by the destination application's Access policies, even if a Gateway Allow rule matched first. Block policies that match traffic will terminate any other policy evaluation. +#### DLP policy precedence + +For Gateway configurations with DLP policies, Gateway will filter and log traffic based on first match, then scan the body of the HTTP request for matching content. For example, if traffic is first allowed with an Allow HTTP policy, then blocked with a DLP Block policy, Gateway will log the initial Allow action despite ultimately blocking the request. + +#### Access applications -This is expected behavior. A Gateway Allow policy does not override or bypass Access policies. +If Gateway traffic is headed to a private IP address protected as an Access application, that traffic will still be evaluated by the destination application's Access policies, even if a Gateway Allow rule matched first. Block policies that match traffic will terminate any other policy evaluation. This is expected behavior. A Gateway Allow policy does not override or bypass Access policies. From f7811b86725a8d03125ac46cd45f18e00a7d300c Mon Sep 17 00:00:00 2001 From: Max Phillips Date: Fri, 27 Jun 2025 12:00:40 -0500 Subject: [PATCH 2/6] Remove unneeded partial --- .../gateway/order-of-enforcement.mdx | 18 ++++++++++++------ .../gateway/order-of-precedence.mdx | 15 --------------- 2 files changed, 12 insertions(+), 21 deletions(-) delete mode 100644 src/content/partials/cloudflare-one/gateway/order-of-precedence.mdx diff --git a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx index 69de0a1a2040c7a..0b6e984d7582018 100644 --- a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx +++ b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx @@ -200,7 +200,7 @@ Next, Gateway checks decrypted traffic against your Isolate policies. When a use Next, Gateway evaluates all Allow, Block, and Do Not Scan policies. These policies apply to both isolated and non-isolated traffic. For example, if `example.com` is isolated and `example.com/subpage` is blocked, Gateway will block the subpage inside of the remote browser. -Lastly, Gateway evaluates the body of the HTTP request by evaluating DLP policies and running anti-virus scanning and file sandboxing. If DLP policies are present, the action Gateway takes may not [match its logs](#dlp-policy-precedence). +Lastly, Gateway evaluates the body of the HTTP request by evaluating DLP policies and running anti-virus scanning and file sandboxing. If DLP Block policies are present, the action Gateway ultimately takes may not match the action it initially logs. For more information, refer to [DLP policy precedence](#dlp-policy-precedence). ### Resolver policies @@ -208,11 +208,17 @@ When [resolver policies](/cloudflare-one/policies/gateway/resolver-policies/) ar ### Order of precedence - +Order of precedence refers to the priority of individual policies within the DNS, network, or HTTP policy builder (lowest value first, or from top to bottom as shown in the dashboard). You can modify the order of precedence by dragging and dropping individual policies in the dashboard. + +In Gateway, the order of precedence follows the first match principle — once a site matches an Allow or Block policy, evaluation stops and no subsequent policies can override the decision. Therefore, Cloudflare recommends putting the most specific policies and exceptions at the top of the list and the most general policies at the bottom. + +#### DLP policy precedence + +For Gateway configurations with DLP policies, Gateway will filter and log traffic based on first match, then scan the body of the HTTP request for matching content. For example, if traffic is first allowed with an Allow HTTP policy, then blocked with a DLP Block policy, Gateway will log the initial Allow action despite ultimately blocking the request. + +#### Access applications + +If Gateway traffic is headed to a private IP address protected as an Access application, that traffic will still be evaluated by the destination application's Access policies, even if a Gateway Allow rule matched first. Block policies that match traffic will terminate any other policy evaluation. This is expected behavior. A Gateway Allow policy does not override or bypass Access policies. diff --git a/src/content/partials/cloudflare-one/gateway/order-of-precedence.mdx b/src/content/partials/cloudflare-one/gateway/order-of-precedence.mdx deleted file mode 100644 index 2a71d196e0f99ae..000000000000000 --- a/src/content/partials/cloudflare-one/gateway/order-of-precedence.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -inputParameters: param1 ---- - -Order of precedence refers to the priority of individual policies within the {props.one} policy builder (lowest value first, or from top to bottom as shown in the dashboard). You can modify the order of precedence by dragging and dropping individual policies in the dashboard. - -In Gateway, the order of precedence follows the first match principle — once a site matches an Allow or Block policy, evaluation stops and no subsequent policies can override the decision. Therefore, Cloudflare recommends putting the most specific policies and exceptions at the top of the list and the most general policies at the bottom. - -#### DLP policy precedence - -For Gateway configurations with DLP policies, Gateway will filter and log traffic based on first match, then scan the body of the HTTP request for matching content. For example, if traffic is first allowed with an Allow HTTP policy, then blocked with a DLP Block policy, Gateway will log the initial Allow action despite ultimately blocking the request. - -#### Access applications - -If Gateway traffic is headed to a private IP address protected as an Access application, that traffic will still be evaluated by the destination application's Access policies, even if a Gateway Allow rule matched first. Block policies that match traffic will terminate any other policy evaluation. This is expected behavior. A Gateway Allow policy does not override or bypass Access policies. From 1b5521cc8d9bcb3169080fdbf862ee21f1cefeb6 Mon Sep 17 00:00:00 2001 From: Max Phillips Date: Fri, 27 Jun 2025 12:08:22 -0500 Subject: [PATCH 3/6] Add additional context to Gateway decision --- .../partials/cloudflare-one/gateway/order-of-enforcement.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx index 0b6e984d7582018..9e5c4625692b07a 100644 --- a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx +++ b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx @@ -214,7 +214,7 @@ In Gateway, the order of precedence follows the first match principle — once a #### DLP policy precedence -For Gateway configurations with DLP policies, Gateway will filter and log traffic based on first match, then scan the body of the HTTP request for matching content. For example, if traffic is first allowed with an Allow HTTP policy, then blocked with a DLP Block policy, Gateway will log the initial Allow action despite ultimately blocking the request. +For Gateway configurations with DLP policies, Gateway will filter and log traffic based on first match, then scan the body of the HTTP request for matching content. Because of the first match principle, Gateway may perform and log a decision for traffic, then perform a contradicting decision. For example, if traffic is first allowed with an Allow HTTP policy, then blocked with a DLP Block policy, Gateway will log the initial Allow action despite ultimately blocking the request. #### Access applications From 38cd7a0a572e9b809a34bb929ee7ce452776abbd Mon Sep 17 00:00:00 2001 From: Max Phillips Date: Mon, 30 Jun 2025 16:56:55 -0400 Subject: [PATCH 4/6] Apply suggestions from code review Co-authored-by: Kate Tungusova <70746074+deadlypants1973@users.noreply.github.com> --- .../partials/cloudflare-one/gateway/order-of-enforcement.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx index 9e5c4625692b07a..dec8278ff0fbc5b 100644 --- a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx +++ b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx @@ -198,9 +198,9 @@ The only exception is if you are using [Clientless Web Isolation](/cloudflare-on Next, Gateway checks decrypted traffic against your Isolate policies. When a user makes a request which triggers an Isolate policy, the request will be rerouted to a [remote browser](/cloudflare-one/policies/browser-isolation/). -Next, Gateway evaluates all Allow, Block, and Do Not Scan policies. These policies apply to both isolated and non-isolated traffic. For example, if `example.com` is isolated and `example.com/subpage` is blocked, Gateway will block the subpage inside of the remote browser. +Next, Gateway evaluates all Allow, Block, and Do Not Scan policies. These policies apply to both isolated and non-isolated traffic. For example, if `example.com` is isolated and `example.com/subpage` is blocked, Gateway will block the subpage (`example.com/subpage`) inside of the remote browser. -Lastly, Gateway evaluates the body of the HTTP request by evaluating DLP policies and running anti-virus scanning and file sandboxing. If DLP Block policies are present, the action Gateway ultimately takes may not match the action it initially logs. For more information, refer to [DLP policy precedence](#dlp-policy-precedence). +Lastly, Gateway inspects the body of the HTTP request by evaluating it against DLP policies, and running anti-virus scanning and file sandboxing. If DLP Block policies are present, the action Gateway ultimately takes may not match the action it initially logs. For more information, refer to [DLP policy precedence](#dlp-policy-precedence). ### Resolver policies From 10e252c4f3f313dccf899b55778fdba0bac50ec9 Mon Sep 17 00:00:00 2001 From: Max Phillips Date: Mon, 30 Jun 2025 16:15:20 -0500 Subject: [PATCH 5/6] Apply suggestions from review --- .../cloudflare-one/gateway/order-of-enforcement.mdx | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx index dec8278ff0fbc5b..8d80250e13d201a 100644 --- a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx +++ b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx @@ -208,9 +208,17 @@ When [resolver policies](/cloudflare-one/policies/gateway/resolver-policies/) ar ### Order of precedence -Order of precedence refers to the priority of individual policies within the DNS, network, or HTTP policy builder (lowest value first, or from top to bottom as shown in the dashboard). You can modify the order of precedence by dragging and dropping individual policies in the dashboard. +Order of precedence refers to the priority of individual policies within the DNS, network, or HTTP policy builder. Gateway evaluates policies in ascending order beginning with the lowest value. -In Gateway, the order of precedence follows the first match principle — once a site matches an Allow or Block policy, evaluation stops and no subsequent policies can override the decision. Therefore, Cloudflare recommends putting the most specific policies and exceptions at the top of the list and the most general policies at the bottom. +The order of precedence follows the first match principle. Once traffic matches an Allow or Block policy, evaluation stops and no subsequent policies can override the decision. Therefore, Cloudflare recommends assigning the most specific policies and exceptions with the highest precedence and the most general policies with the lowest precedence. + +#### Zero Trust dashboard + +In the Zero Trust dashboard, policies are in order of precedence from top to bottom of the list. Policies begin with precedence `1` and count upward. You can modify the order of precedence by dragging and dropping individual policies in the dashboard. + +#### Cloudflare API + +To update the precedence of a policy with the Cloudflare API, use the [Update a Zero Trust Gateway rule](/api/resources/zero_trust/subresources/gateway/subresources/rules/methods/update/) endpoint to update the `precedence` field. #### DLP policy precedence From 54f30f49fcb94eef5d6ac813a83ac84608b20752 Mon Sep 17 00:00:00 2001 From: Max Phillips Date: Tue, 1 Jul 2025 10:22:38 -0500 Subject: [PATCH 6/6] Clarify policy type --- .../partials/cloudflare-one/gateway/order-of-enforcement.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx index 8d80250e13d201a..aa6fa630e6d556e 100644 --- a/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx +++ b/src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx @@ -226,7 +226,7 @@ For Gateway configurations with DLP policies, Gateway will filter and log traffi #### Access applications -If Gateway traffic is headed to a private IP address protected as an Access application, that traffic will still be evaluated by the destination application's Access policies, even if a Gateway Allow rule matched first. Block policies that match traffic will terminate any other policy evaluation. This is expected behavior. A Gateway Allow policy does not override or bypass Access policies. +If Gateway traffic is headed to a private IP address protected as an Access application, that traffic will still be evaluated by the destination application's Access policies, even if a Gateway Allow policy matched first. Gateway Block policies that match traffic will terminate any other policy evaluation. This is expected behavior. A Gateway Allow policy does not override or bypass Access policies.