HTTP policies

HTTP policies allow you to filter all HTTP and HTTPS requests based on URLs, hostnames, HTTP methods, file types, and other request attributes. Unlike network policies which operate at Layer 4 (TCP/UDP), HTTP policies operate at Layer 7 and can inspect the full content of web traffic.

By default, Gateway inspects HTTP traffic on port 80 and, with TLS decryption turned on, HTTPS traffic on port 443. You can also configure Gateway to inspect HTTP/HTTPS traffic on all ports. Gateway supports HTTP/3 inspection with the UDP proxy turned on.

An HTTP policy consists of an Action and a logical expression that determines the scope of the policy. To build an expression, choose a Selector and an Operator, then enter a value or range of values in the Value field. You can use And and Or logical operators to evaluate multiple conditions.

• Actions
• Selectors
• Comparison operators
• Value
• Logical operators

If a condition in an expression joins a query attribute (such as Source IP) and a response attribute (such as Resolved IP), then the condition will be evaluated when the response is received.

Actions in HTTP policies allow you to choose what to do with a given set of elements (domains, IP addresses, file types, and so on). You can assign one action per policy.

API value: allow

The Allow action allows outbound traffic to reach destinations you specify within the Selectors and Value fields. For example, the following configuration allows traffic to reach all websites we categorize as belonging to the Education content category:

The Untrusted certificate action determines how to handle insecure requests.

Allow policies can modify HTTP request headers before forwarding traffic to the destination. You can add, overwrite, or delete headers, and use dynamic variables to inject identity, device, and network context into header values.

For more information, refer to Custom headers.

API value: block

The Block action blocks outbound traffic from reaching destinations you specify within the Selectors and Value fields. For example, the following configuration blocks users from being able to upload any file type to Google Drive:

Turn on Display block notification for Cloudflare One Client to display notifications for Gateway block events. Blocked users will receive an operating system notification from the Cloudflare One Client with a custom message you set. If you do not set a custom message, the Cloudflare One Client will display a default message. Custom messages must be 100 characters or less. The Cloudflare One Client will only display one notification per minute.

Upon selecting the notification, the Cloudflare One Client will direct your users to the Gateway block page you have configured. Optionally, you can direct users to a custom URL, such as an internal support form.

When you turn on Send policy context, Gateway will append details of the matching request to the redirected URL as a query string. Not every context field will be included. Potential policy context fields include:

Ensure that your operating system allows notifications for the Cloudflare One Client. Your device may not display notifications if focus, do not disturb, or screen sharing settings are turned on. To turn on client notifications on macOS devices running DisplayLink software, you may have to allow system notifications when mirroring your display. For more information, refer to the macOS documentation ↗.

API value: redirect

The Redirect action allows you to redirect matched HTTP requests to a different URL you specify. For example, if your users browse to the public web page of a SaaS app, you can redirect them to your own self-hosted instance, a single sign-on page, or an internal policy page.

To redirect URLs with a Block action and the block page, refer to Redirect to a block page.

In Policy URL redirect, you can define what URL to redirect matched requests to. The redirect URL can contain paths and queries. For example, you can redirect example.com to cloudflare.com/path/to/page?querystring=x.

When you turn on Send policy context, Gateway will append details of the matching request to the redirected URL as a query string. Not every context field will be included. Potential policy context fields include:

When you turn on Preserve original path and query string, Gateway will append the original path and query string to the redirected URL. Paths and queries in the redirect URL take precedence over the original URL. For example, if the original URL is example.com/path/to/page?querystring=X and the redirect URL is cloudflare.com/redirect-path?querystring=Y, Gateway will redirect requests to:

cloudflare.com/redirect-path/path/to/page?querystring=Y

When you turn on both options, Gateway will preserve the original path and query string, then append policy context to the end of the redirect URL. For example, if the original URL is example.com/path/to/page?querystring=X&k=1 and the redirect URL is cloudflare.com/redirect-path?querystring=Y, Gateway will redirect requests to:

cloudflare.com/redirect-path/path/to/page?querystring=Y&k=1&cf_user_email=user@example.com

API value: isolate

The Isolate action serves matched traffic to users via Cloudflare Browser Isolation. For more information on this action, refer to Isolation policies.

API value: off

Do Not Inspect lets you bypass certain elements from inspection. To prevent Gateway from decrypting and inspecting HTTPS traffic, your policy must match against the Server Name Indication (SNI) in the TLS header. When accessing a Do Not Inspect site in the browser, your browser may display a Your connection is not private warning, which you can proceed through to connect. For more information about applications which may require a Do Not Inspect policy, refer to TLS decryption limitations.

API value: noisolate

The Do Not Isolate action turns off browser isolation for matched traffic. For more information on this action, refer to Isolation policies.

API value: noscan

When an admin enables AV scanning for uploads and/or downloads, Gateway will scan every supported file. Admins can selectively choose to disable scanning by leveraging the HTTP rules. For example, to prevent AV scanning of files uploaded to or downloaded from example.com, an admin would configure the following rule:

When a Do Not Scan rule matches, nothing is scanned, regardless of file size or whether the file type is supported or not.

API value: quarantine

The Quarantine action sends files in matching requests to a file sandbox to scan for malware. Gateway will only quarantine files not previously seen in the file sandbox. For more information on this action, refer to File sandboxing.

In Sandbox file types, you can select which file types to quarantine with your policy. You must select at least one file type.

File sandboxing supports scanning the following file types:

Gateway matches HTTP traffic against the following selectors, or criteria:

All targets secured by an Access infrastructure application.

All destination IPs and hostnames secured by an Access self-hosted private application.

The review approval status of an application from Shadow IT Discovery or the Application Library. For more information, refer to Review applications.

You can apply HTTP policies to a growing list of popular web applications. Refer to Application and app types for more information.

When using the is operator with the Application selector, you can use Application Granular Controls to choose specific actions and operations to match application traffic. For example, you can block file uploads to ChatGPT without blocking all ChatGPT traffic:

You can match traffic based on Application Controls, which group multiple user actions together, or Operations, which allow for granular control of supported API-level actions for an application.

For more information, refer to Application Granular Controls.

The phase of an HTTP request. You can use this selector to specify whether to scan either the data sent in an HTTP request to your user's device or from your user's device to a destination. Policies without this selector will scan both the HTTP request and response bodies.

Applications within a specific security category as categorized by Cloudflare Radar.

The continent where the request is destined. Geolocation is determined from the target IP address. To specify a continent, enter its two-letter code into the Value field:

The country that the request is destined for. Geolocation is determined from the target IP address. To specify a country, enter its ISO 3166-1 Alpha 2 code ↗ in the Value field.

The IP address of the request's target.

With the Device Posture selector, admins can use signals from end-user devices to secure access to their internal and external resources. For example, a security admin can choose to limit all access to internal applications based on whether specific software is installed on a device and/or if the device or software are configured in a particular way.

For more information on device posture checks, refer to Device posture.

Use this selector to match against a domain and all subdomains. For example, you can match example.com and its subdomains, such as www.example.com.

Gateway policies do not support domains with non-Latin characters directly. To use a domain with non-Latin characters, add it to a list.

Use these selectors to limit the file size of upload or download transactions. File sizes are measured in mebibytes (MiB).

These selectors will scan file signatures in the HTTP body. You can select from file categories or specific file types, such as executables, archives and compressed files, unscannable files, Microsoft 365/Office documents, and Adobe files.

Gateway supports the following file types for use with the Download File Types and Upload File Types selectors:

These selectors depend on the Content-Type header being present in the request (for uploads) or response (for downloads). The MIME type value must match the format used in the Content-Type header (for example, image/png, application/pdf).

Use Cloudflare Data Loss Prevention (DLP) to scan HTTP traffic for the presence of sensitive data such as personally identifiable information (PII) or source code. You must configure a DLP profile before you can use this selector in a policy.

Use this selector to match against only the hostname specified. For example, you can match test.example.com but not example.com or www.test.example.com.

Gateway policies do not support hostnames with non-Latin characters directly. To use a hostname with non-Latin characters, add it to a list.

The HTTP request method used in the traffic.

The HTTP response status code received by the traffic.

The proxy server where your browser forwards HTTP traffic.

Applications within a specific security category as categorized by Cloudflare Radar.

The continent of the user making the request.

Geolocation is determined from the device's public IP address (typically assigned by the user's ISP). To specify a continent, enter its two-letter code into the Value field:

The country of the user making the request.

Geolocation is determined from the device's public IP address (typically assigned by the user's ISP). To specify a country, enter its ISO 3166-1 Alpha-2 code ↗ in the Value field.

Use this selector to apply HTTP policies to a private IP address, assigned by a user's local network, that requests arrive to Gateway from.

The originating IP address or addresses of a device proxied by Gateway.

Gateway ignores trailing forward slashes (/) in URLs. For example, https://example.com and https://example.com/ will count as the same URL and may return a duplicate error.

The pathname of a webpage's URL.

The pathname and query of a webpage's URL.

The query of a webpage's URL.

Use these selectors to match against identity attributes.

Use this selector to match all traffic routed through a specific Virtual Network via the Cloudflare One Client.

Comparison operators are the way Gateway matches traffic to a selector. When you choose a Selector in the dashboard policy builder, the Operator dropdown menu will display the available options for that selector.

In the Value field, you can input a single value when using an equality comparison operator (such as is) or multiple values when using a containment comparison operator (such as in). Additionally, you can use regular expressions (or regex) to specify a range of values for supported selectors.

Regular expressions are evaluated using Rust. The Rust implementation is slightly different than regex libraries used elsewhere. For more information, refer to our guide for Wildcards. To evaluate if your regex matches, you can use Rustexp ↗.

If you want to match multiple values, you can use the pipe symbol (|) as an OR operator. You do not need to use an escape character (\) before the pipe symbol. For example, the following expression evaluates to true when the hostname matches either .*whispersystems.org or .*signal.org:

In addition to regular expressions, you can use logical operators to match multiple values.

To evaluate multiple conditions in an expression, select the And logical operator. These expressions can be compared further with the Or logical operator.

The Or operator will only work with conditions in the same expression group. For example, you cannot compare conditions in Traffic with conditions in Identity or Device Posture.

If a condition in an expression joins a request attribute (such as Source IP) and a response attribute (such as a DLP Profile), then the condition will be evaluated when the response is received.