Cloudflare Gateway now runs your code inline for custom security logic

Cloudflare has announced a significant expansion of its Zero Trust platform, enabling developers to execute custom code directly within the secure web gateway policy evaluation path. Released on October 15, 2026, this update integrates Cloudflare Workers with Gateway and Data Loss Prevention (DLP) services, allowing arbitrary logic to run inline at the network edge.

What happened

For decades, secure web gateways have operated on a rigid model: traffic matches a predefined condition, and the system executes a terminal action such as allow, block, or log. While effective for standard use cases, this approach struggles with complex, environment-specific requirements. Security teams often face a binary choice between maintaining costly, custom proxy infrastructure for maximum flexibility or accepting vendor constraints that limit their ability to solve unique problems.

To address this, Cloudflare is introducing two new capabilities: the Forward action and Custom Functions. The Forward action, available in public beta today, routes matched HTTP requests to a Cloudflare Worker, which acts as inline middleware. This allows developers to modify headers, transform request bodies, or trigger asynchronous actions like logging to external systems before the traffic reaches its destination. Custom Functions, scheduled for release before the end of the year, will allow Workers to return typed values during policy evaluation, effectively creating dynamic selectors based on internal data or complex logic.

This integration leverages Cloudflare’s existing infrastructure, where Gateway and Workers run on the same machines in over 330 global locations. Because the dispatch is a local function call rather than a network hop, there is no additional latency from hairpinning traffic to a separate cloud environment. This architecture aims to provide the customization of self-hosted proxies without the operational overhead of managing infrastructure.

How it works

The Forward action transforms a Cloudflare Worker into a programmable proxy. When a Gateway policy matches a request, it forwards the full HTTP context—including headers and body—to the specified Worker. The Worker can inspect the request, modify it, and then pass it upstream using the next() function. It can also modify the response before it returns to the user. Gateway handles the underlying TCP connections, TLS termination, and certificate management, while the Worker focuses solely on application-level logic.

Custom Functions operate differently by integrating directly into the policy decision engine. A Worker receives context such as source IP, user identity, and device posture, then returns a simple string, number, or boolean. This return value becomes a new selector in the Gateway policy builder. For example, a function could parse a JSON Web Token to extract a user’s role and return it as a string. Administrators can then write rules like "Allow if Custom Function Role equals finance_contractor," combining built-in selectors with custom, computed data.

Key details

• Forward Action: Routes matched HTTP traffic to a Worker for inline transformation, available in public beta starting October 15, 2026.
• Custom Functions: Allows Workers to return typed values for use in policy conditions, expected to launch before the end of 2026.
• Zero Latency Overhead: Dispatching to a Worker is a local function call on the same machine, avoiding network round-trips.
• Universal Availability: Both features will be available on all Zero Trust plans, including Free, Paid, and Enterprise tiers.
• Billing: Traffic dispatched to Workers is billed as standard Worker requests, subject to existing execution time and daily request limits.
• Fallback Safety: Custom Functions require default values to ensure deterministic behavior if the code fails or times out.

Why it matters

For software engineers and security leads, this shift eliminates the need to deploy and maintain separate NGINX proxies or complex webhook pipelines for minor traffic transformations. Tasks that previously required standing up dedicated infrastructure—such as injecting HTTP headers based on JWT claims or creating audit trails for sensitive access—can now be handled with a few lines of TypeScript in a Worker. This reduces operational debt and accelerates the implementation of security policies that are specific to an organization’s internal tools and workflows.

The ability to run arbitrary code inline also enhances real-time responsiveness. Instead of relying on delayed logs shipped to a SIEM for alerting, a Forward action can trigger immediate notifications to Slack or PagerDuty when a DLP rule is triggered. Furthermore, Custom Functions enable more nuanced access controls by incorporating external data sources, such as internal risk scoring systems, directly into the firewall’s decision-making process without exposing those systems to the public internet.

What you can do

• Evaluate the public beta of the Forward action to test inline header injection or request modification for your internal applications.
• Identify current manual proxy tasks, such as JWT parsing or custom logging, that could be migrated to Cloudflare Workers.
• Design Custom Functions that integrate with internal databases or APIs to create dynamic policy selectors based on real-time user context.
• Review your existing DLP policies to determine where custom validation logic could reduce false positives by checking data relevance against internal records.
• Monitor Worker execution limits and costs, especially if planning to route high-volume traffic through Forward actions.
• Prepare for the end-of-year release of Custom Functions by mapping out complex evaluation logic that currently requires external post-processing.