Cloudflare has announced a major architectural shift for enterprise network security, introducing native programmability to its Secure Web Gateway and Data Loss Prevention (DLP) platforms. By tightly integrating its edge computing infrastructure directly into the security policy enforcement path, the company aims to eliminate the traditional compromise security teams have faced for decades: choosing between rigid vendor-enforced constraints or maintaining costly, complex auxiliary proxy architectures.
For nearly 30 years, the foundational model of network security has remained largely unchanged across the industry. Traffic matches a specific condition, and a terminal action fires—allowing, blocking, isolating, or logging the connection. While this paradigm handles standard scenarios effectively, enterprises managing complex, distributed environments frequently encounter its limitations. Vendors have traditionally claimed "programmability" through public APIs, infrastructure-as-code providers, webhooks, and alerting integrations. However, Cloudflare argues that these offerings fall short of true programmability, which requires the ability to execute arbitrary, custom-written code inline during the security decision-making process.
The newly released capabilities bridge this gap by allowing security teams to deploy Cloudflare Workers directly within the Cloudflare Gateway and DLP evaluation paths. Available across Zero Trust plans, the release introduces a new Gateway policy action called Forward alongside custom validation functions. This synergy is powered by Cloudflare’s unique network architecture, where distributed compute nodes and security enforcement engines operate on the same physical machines across more than 330 locations worldwide.
Resolving the Long-Standing Trade-Off in Enterprise Security
Since the inception of network firewalls, organizations have been forced to navigate a difficult binary choice. Maintaining an independent security detection engine, custom proxy infrastructure, or dedicated firewall yields maximum customization but introduces steep maintenance overhead and low portability. Conversely, offloading those responsibilities to a traditional vendor reduces operational costs at the expense of the flexibility required to solve unique environmental challenges.
Over six years of developing Cloudflare Gateway, engineers heard from thousands of customers struggling with this exact trade-off. For instance, security teams migrating access controls for internal applications frequently need to inject HTTP headers derived from JSON Web Token claims provided by their identity provider. Because standard gateway engines cannot easily read custom tokens and rewrite headers on the fly, teams are often forced to provision and maintain dedicated pools of NGINX proxies solely to perform these transformations. This additional infrastructure demands continuous patching, monitoring, and security management.
Similarly, organizations looking to trigger immediate notifications—such as alerting a Slack channel the moment an employee signs up for an unauthorized SaaS application—find themselves constrained by binary allow-or-block policy engines. To achieve real-time visibility, security architects often build convoluted pipelines involving log pushing, security information and event management systems, and webhook relays, introducing latency and potential points of failure. Similar friction exists when organizations attempt to serve dynamic, customized warning pages that prompt users for business justifications before accessing sensitive destinations.
While extension points have existed across the firewall industry, proprietary engines have historically struggled to adapt to emerging threat vectors as rapidly as they appear. By coupling a globally distributed secure web gateway with an accessible edge compute platform, Cloudflare seeks to eliminate these operational bottlenecks.
Leveraging a Co-Located Compute and Security Architecture
What distinguishes Cloudflare’s approach is the physical co-location of its security enforcement and compute services. Because Cloudflare Workers and Gateway operate on the same infrastructure from the ground up, dispatching traffic from a security policy to a Worker functions as a local subroutine call. There is no network hairpinning and no additional latency incurred from crossing external network boundaries.
Standalone Secure Access Service Edge (SASE) providers that lack an integrated compute platform typically require organizations to deploy automation logic in separate cloud environments, configure manual webhooks, and absorb the round-trip latency and management overhead of stitching disparate systems together. Cloudflare’s unified model grants administrators absolute control over proxied traffic processing without requiring them to host or maintain separate proxy infrastructure.
New Gateway Entry Points: Forward Actions and Custom Functions
The integration introduces two distinct methods for invoking a Worker from within a Gateway policy: the Forward action and Custom Functions.
The Forward action, currently available in public beta, acts as a customizable proxy and traffic transformation engine. When HTTP traffic matches a specified rule, the request is routed to a bound Cloudflare Worker that acts as inline middleware. The Worker receives the full request headers and body, allowing code to modify attributes, interact with external data stores, forward requests to the origin, inspect responses, and return the final output to the user.
Significantly, Gateway handles all underlying complexities, including TCP connections, TLS termination and re-encryption, certificate management, and HTTP version negotiation. The Worker remains strictly responsible for custom transformation logic. Alternatively, a Forward rule can be used purely asynchronously to dispatch request context to a Worker—such as posting an alert to Slack, logging data to object storage, or updating a key-value store—while allowing the primary traffic to proceed to its destination uninterrupted.
Complementing the Forward action are Custom Functions, slated for release before the end of the year. These functions execute inline during Gateway policy evaluation to return a typed value—such as a string, number, or boolean—that becomes a selectable condition in the policy builder. Evaluated alongside standard selectors like source IP or content category, custom functions can process complex identity data, parse authorization headers, or execute behavioral risk-scoring logic across Layer 4 and Layer 7 traffic before an access decision is finalized.
Expanding Data Loss Prevention with Custom Validation
The programmability initiative extends beyond the Secure Web Gateway into Cloudflare’s Data Loss Prevention platform. Traditional data security products rely heavily on static pattern matching, regular expressions, and word lists to identify sensitive information. While useful, these methods can typically only determine whether data matches a specific pattern, rather than verifying whether a specific instance of data represents an active risk or exfiltration threat.
To address this limitation, Cloudflare is introducing custom validation functions for DLP. These functions allow organizations to define custom validation logic utilizing their own internal sources of truth directly inside a Cloudflare Worker. For example, when a DLP profile detects a potential GitHub secret within outbound traffic, an auxiliary Worker can query the GitHub API in real time to verify whether the token is active. Based on the API response, the validation function can instruct the DLP engine to confirm the match, treat the result as a veto, or discard the finding entirely.
By merging distributed edge computing with enterprise security controls, Cloudflare’s expanded platform provides organizations with the agility to adapt their security posture to complex, rapidly evolving enterprise requirements.
Leave a Reply