Applications and app types

Gateway allows you to create DNS, Network, and HTTP policies based on applications and application types. Because a single application often spans multiple hostnames, selecting an application by name is easier than writing separate rules for each hostname. You can select individual applications or application types to filter specific traffic on your network.

When you choose the Application selector in a Gateway policy builder, the Value field will include all supported applications and their respective app types. Alternatively, you can use the Gateway API to fetch a list of applications, app types, and ID numbers.

To manage a consolidated list of applications across Cloudflare One, you can use the Application Library.

You can create a custom application in the Application Library and select it by name in the existing Application selector for DNS, HTTP, and network policies. Custom and Cloudflare-managed applications can appear in the same condition. Custom applications are available only in the account that owns them.

For API and Terraform rules, use the application's assigned numeric ID with the existing application fields, such as app.ids, app.hosts_ids, and app.supports_ids. The human-readable Application ID entered during creation is not the numeric ID used in a rule expression.

To retrieve custom application IDs, list your account's applications with GET /accounts/{account_id}/resource-library/applications. The legacy Gateway app_types endpoint returns the Cloudflare-managed catalog and does not include custom applications.

For example, replace <CUSTOM_APPLICATION_NUMERIC_ID> with the numeric ID to match the application:

any(app.ids[*] in {<CUSTOM_APPLICATION_NUMERIC_ID>})

Editing the application's network identifiers updates what referencing rules match after the definition propagates to Gateway. You do not need to replace its ID or recreate the rules. A custom application cannot be deleted while a Gateway rule or reusable profile references it, including a rule that is turned off. Refer to Delete a custom application.

Gateway matches a custom application when the hostname or destination IP matches its definition. If the definition includes both hostnames and IP subnets, either can match independently. Multiple entries within each field are also alternatives.

Hostnames match the specified domain and its subdomains. For example, example.com matches both example.com and api.example.com. Choose specific hostnames when you need to limit the scope of a custom application.

In HTTP and network policies, configured port protocols add a restriction to the hostname or IP match. The destination must also match one of the configured port/protocol pairs or inclusive ranges. If Port protocols is empty, the definition applies to any port and protocol. A port/protocol match alone does not identify an application.

For example, define a custom application with the hostname crm.example.com, the IP subnet 192.0.2.0/24, and the port protocol tcp/443:

DNS policies match the query hostname before resolution and can also match resolved IP addresses after resolution. DNS application matching does not use the application's port/protocol constraints because a DNS query does not identify the destination port of the subsequent connection. For the example application, a query for crm.example.com can match even when the subsequent connection would use port 8443.

Support hostnames identify application dependencies. Gateway includes them in Allow policies and excludes them from Block policies, using the same behavior as support hostnames for Cloudflare-managed applications. Adding support hostnames does not replace the requirement for a primary hostname or IP subnet. Refer to custom application limits for the combined hostname limit, IP subnet limits, and port formats.

Gateway sorts applications into the following app type groups:

An application like Google Drive uses its own hostnames (for example, drive.google.com) and shared resources used by other applications (for example, accounts.google.com for login). Gateway separates these into hostnames and support hostnames so you can control the behavior of each application independently.

Hostnames are domains that are core to the application and not used by other applications. These are the domains that Gateway blocks when you block an application. The App Library surfaces these hostnames in the Hostnames table for an application.

Support hostnames are shared resources that applications depend on for content delivery, authentication, or third-party integrations. Because multiple applications share these hostnames, blocking them can cause unexpected side effects.

For example, assume that file-sharing-service.com relies on content-delivery.com. If you allow access to file-sharing-service.com and its associated subdomains but not content-delivery.com, some of the functionality of file-sharing-service.com may break when Gateway matches the traffic.

To prevent this, Gateway only uses support hostnames in Allow policies — it will allow support hostname connections but will not block them. For example, many Google applications use accounts.google.com for authentication. If you create an Allow policy for an application that lists accounts.google.com as a support hostname, Gateway will allow both accounts.google.com and the application's own domains.

When you use the Application selector in an HTTP policy with the is operator, you can choose specific actions and operations to match application traffic. Supported applications and operations include:

For more information, refer to Application Granular Controls.

Overlapping hostnames are most common for vendors with many applications, such as Google or Meta. When you use the Application selector in Gateway policies, actions taken by Gateway will be limited to the specific application defined. Gateway will also log other applications that use the same hostnames, but it will not take action unless the application was matched by the policy. For example, both the Facebook and Facebook Messenger apps use the chat-e2ee.facebook.com hostname. When evaluating traffic to the Facebook Messenger app, Gateway will only take action on Facebook Messenger traffic but may log both the Facebook and Facebook Messenger apps.

To ensure Gateway evaluates traffic with your desired precedence, order your most specific policies with the highest priority according to order of precedence.

Gateway automatically groups applications incompatible with TLS decryption into the Do Not Inspect app type. As Cloudflare identifies incompatible applications, Gateway will periodically update this app type to add new applications. To ensure Gateway does not intercept any current or future incompatible traffic, you can create a Do Not Inspect HTTP policy with the entire Do Not Inspect app type selected.

When managing applications with the Application Library, Do Not Inspect applications will appear under the corresponding application. For example, the App Library will group Google Drive (Do Not Inspect) under Google Drive.

Applications can be incompatible with TLS decryption for various reasons:

• Certificate pinning: Certificate pinning is a security mechanism used to prevent on-path attacks on the Internet by hardcoding information about the certificate that the application expects to receive. If the wrong certificate is received, even if it is trusted by the system, the application will refuse to connect.

• Non-web traffic: Some applications send non-web traffic over TLS, such as Session Initiation Protocol (SIP) for voice and video calls and Extensible Messaging and Presence Protocol (XMPP) for chat. Gateway cannot inspect these protocols.

To optimize performance for Microsoft 365 applications and services, you can bypass TLS decryption by turning on the Microsoft 365 traffic integration. This will create a Do Not Inspect policy for all Microsoft 365 domains and IP addresses ↗︎ specified by Microsoft. This policy also uses Cloudflare intelligence to identify other Microsoft 365 traffic not explicitly defined.

To turn on the Microsoft 365 integration:

1. In the Cloudflare dashboard ↗︎, go to Zero Trust > Traffic policies > Traffic settings > Policy settings.
2. In Bypass decryption of Microsoft 365 traffic, select Create policy.
3. To verify the policy was created, select View policy. Alternatively, go to Traffic policies > HTTP policies. A policy named Microsoft 365 Auto Generated will be enabled in your list.

All future Microsoft 365 traffic will bypass Gateway logging and filtering. To disable this behavior, turn off or delete the policy.

Terraform users can retrieve the app types list with the cloudflare_zero_trust_gateway_app_types_list data source. This allows you to create Gateway policies with the application's name rather than its numeric ID. For example:

data "cloudflare_zero_trust_gateway_app_types_list" "gateway_apptypes" {
  account_id = var.cloudflare_account_id
}

locals {
  apptypes_map = merge([
    for c in data.cloudflare_zero_trust_gateway_app_types_list.gateway_apptypes.result :
    { (c.name) = c.id }
  ]...)
}

resource "cloudflare_zero_trust_gateway_policy" "zt_block_dns_apps" {
  account_id = var.cloudflare_account_id
  name       = "DNS Blocked apps"
  action     = "block"
  traffic    = "any(app.ids[*] in {${join(" ", [
    local.apptypes_map["Discord"],
    local.apptypes_map["GoToMeeting"],
    local.apptypes_map["Greenhouse"],
    local.apptypes_map["Zelle"],
    local.apptypes_map["Microsoft Visual Studio"]
  ])}})"
}