For nearly three decades, the foundational architecture of network security has remained remarkably consistent. Every secure web gateway on the market has operated on a simple binary premise: traffic matches a predetermined condition, and a terminal action fires. Organizations have relied on standard allowances like Allow, Block, Isolate, and Log to secure their perimeters. While this model handles common use cases well, it has long possessed a strict architectural ceiling. Today, enterprises with complex environments routinely hit that ceiling, forcing them to compromise between rigid vendor constraints and the heavy maintenance overhead of running custom proxy infrastructure.
Seeking to dismantle this long-standing industry trade-off, Cloudflare has announced a major expansion of its security portfolio by bringing true programmability to Cloudflare Gateway and Data Loss Prevention (DLP). By deeply integrating these security services with the entirety of its edge computing platform, Cloudflare is rolling out a new type of Gateway action known as Forward, alongside custom validation functions available across all Zero Trust plans. These new capabilities allow organizations to leverage Cloudflare Workers to transform and manipulate traffic inline, or to bring their own proprietary data directly to real-time policy evaluation.
The announcement follows the company’s earlier vision to construct a fully programmable Secure Access Service Edge (SASE) platform. While the broader security industry has frequently utilized terms like programmability to describe public APIs, Terraform providers, webhooks, and alerting mechanisms, Cloudflare argues that true programmability goes significantly further. According to the company, genuine programmability means running custom code—arbitrary logic written specifically for an enterprise’s unique environment—inline within the policy evaluation path at the exact moment a security decision is made.
The Trade-Off That Every Security Team Faces
Ever since traditional firewalls first emerged, businesses have been forced into a difficult binary choice. Security teams could either maintain their own custom detection engines, building independent firewalls and proxy infrastructures that offered maximum customization at the cost of high maintenance overhead and low portability, or they could accept the rigid constraints of a vendor, offloading maintenance costs at the expense of environment-specific flexibility.
Over six years of developing Cloudflare Gateway, engineers have heard from thousands of customers struggling with this exact dilemma. For instance, when a security team needs to migrate access controls for a critical internal application, they frequently need to inject HTTP headers based on JSON Web Token (JWT) claims supplied by their identity provider. Although the data naturally exists within the request context, standard gateways historically could not read the JWT and write the header. Consequently, engineering teams have been forced to stand up entire pools of NGINX proxies solely to execute this single transformation—infrastructure that must subsequently be patched, monitored, and secured indefinitely.
Similarly, other organizations have sought automated alerts via platforms like Slack the moment an employee signs up for an unauthorized SaaS service. Because traditional policy engines can typically only execute Allow or Block commands, teams have had to construct convoluted Logpush-to-SIEM-to-Slack pipelines that introduce significant delivery delays and lack delivery guarantees. Enterprise customers have also frequently requested warning pages that prompt users for explicit business justification before granting access to sensitive destinations, followed by customized behaviors based on user identity and access levels. Serving these types of dynamic responses directly from a static policy engine has historically proven exceedingly difficult.
While firewall vendors have introduced various extension points over the years, the pace of modern threat vectors makes it impossible for standard product roadmaps to cover every customized need. Recognizing that the most effective solutions are those capable of infinite extensibility tailored to an individual environment, Cloudflare is leveraging its unique network topology to bridge this gap.
Why Only Cloudflare Can Solve This Problem
What differentiates Cloudflare from traditional standalone SASE providers or legacy firewall vendors is its composable compute architecture. Cloudflare Workers already enables customers to execute complex, distributed logic on the network edge across more than 330 cities worldwide. Simultaneously, Cloudflare Gateway evaluates and enforces security policies on user traffic at those exact same locations, running on the same physical machines within the same data centers.
Because Gateway and Workers were built upon the same foundational infrastructure from their inception, forwarding traffic from Gateway to a Worker is executed as a local function call rather than a network hop. There is no hairpinning and no additional latency introduced by crossing network boundaries. This architectural integration grants enterprise customers absolute control over how proxied traffic is processed, utilizing custom code without the operational burden of maintaining separate proxy servers.
In contrast, standalone SASE providers lacking an integrated compute platform require organizations to deploy automation across separate cloud environments, manually configure webhooks, and absorb the round-trip latency and ongoing management overhead of stitching together disconnected systems. As digital threats continue to evolve at high speeds, this native integration provides the operational agility that security organizations require.
Two Gateway Entry Points: Forward Action and Custom Functions
To make this architecture accessible, Cloudflare is introducing two distinct methods for invoking a Worker directly from a Gateway policy: the Forward action and Custom Functions. While the Forward action is available in public beta, Custom Functions are slated for release before the end of the year.
The Forward action allows administrators to customize HTTP traffic behavior by routing matched requests to a Worker that functions as a transparent proxy. These policies are evaluated for traffic already permitted by standard HTTP rules. Once matched, the request is sent to the designated Cloudflare Worker, which acts as inline middleware capable of inspecting full headers and request bodies. The Worker can modify the request before forwarding it to the origin server, intercept the returning response for further manipulation, and ultimately deliver the final payload to the end user.
Crucially, Gateway handles the heavy lifting of TCP connections, TLS termination and re-encryption, certificate management, and HTTP version negotiation, leaving the Worker responsible solely for the custom transformation logic. Furthermore, Workers do not necessarily need to transform requests at all. A rule can be configured to asynchronously proxy a request to a Worker to trigger external workflows—such as sending a Slack notification, writing records to Cloudflare R2 object storage, logging data to external pipelines, invoking webhooks, or updating Key-Value stores—while allowing the primary traffic to proceed unhindered.
Complementing the Forward action, Custom Functions provide inline policy evaluation during the Gateway decision-making process. A Custom Function calls out to a Worker inline during evaluation and returns a typed value—such as a string, number, or boolean—which is then exposed as a selector within the Gateway policy builder. This selector can be utilized within the condition of any network or HTTP rule, operating identically to built-in selectors like Source IP or Content Category. Because these functions receive contextual data such as source IP, user identity, device posture, and connection metadata, they can be applied across Layer 4 port and protocol traffic alongside HTTP requests.
DLP Custom Functions for Inline Detection Validation
Expanding beyond secure web gateways, Cloudflare’s fully programmable SASE platform also extends its capabilities to Data Loss Prevention. Standard data security products typically rely on predefined patterns, regular expressions, or word lists to detect sensitive information. While keywords and context analysis can assist in identifying potential matches, these traditional methods suffer from a fundamental limitation: they can only indicate whether data matches a specific pattern, rather than verifying whether a specific instance of data represents an active risk of exfiltration.
To address this challenge without forcing organizations to transfer sensitive reference datasets to third-party vendors, Cloudflare is introducing custom validation functions for DLP. These capabilities allow enterprises to define custom validation logic utilizing their own internal sources of truth directly inside a Cloudflare Worker. When a DLP detection rule matches a pattern, such as a potential GitHub secret, an outbound Worker can execute verification logic against the appropriate API endpoint before a policy enforcement decision is made. If the token is verified as active, the policy can take action; if the token is invalid or expired, the detection can be automatically dismissed, drastically reducing false positives.
Looking ahead, Cloudflare plans to expand these programmable entry points across the broader Cloudflare One suite, with Email Security positioned as the next integration target. By merging distributed edge computing with enterprise security controls, the company aims to provide organizations with the flexibility to adapt their defenses to complex, rapidly changing operational environments.
