For nearly thirty years, the foundational architecture of network security has remained remarkably consistent. Every secure web gateway on the market has operated on a straightforward binary model: traffic matches a predefined condition, and a terminal action fires. Whether the system decides to allow, block, isolate, or log the traffic, this traditional paradigm has served as the bedrock of enterprise network security. It handles common enterprise scenarios exceptionally well, but it has a definitive ceiling, and organizations managing complex, modern environments frequently run into those limitations.
Earlier this year, Cloudflare outlined its vision for a truly programmable Secure Access Service Edge (SASE) platform, while simultaneously criticizing how the term "programmability" has been diluted across the security industry. While many cybersecurity vendors claim programmability because they offer public APIs, Terraform providers, webhooks, and alerting mechanisms—features that Cloudflare also provides—the company argued that this falls short of true flexibility. True programmability, according to Cloudflare, means the ability to run custom code—arbitrary logic written by developers for their specific organizational environment—inline within the policy evaluation path at the exact moment a critical security decision is made.
Cloudflare is now turning that vision into reality by integrating true programmability directly into Cloudflare Gateway and its Data Loss Prevention (DLP) suite, leveraging its entire global edge computing platform. The company is introducing a new class of Gateway action called Forward, alongside custom validation functions designed to be available across all Zero Trust tiers. These advanced capabilities allow security and engineering teams to deploy Cloudflare Workers to transform and manipulate live traffic or to seamlessly integrate proprietary data sources directly into policy evaluation processes.
The Persistent Trade-Off Facing Modern Security Teams
Since the inception of network firewalls, businesses have been forced to navigate a challenging binary choice. Organizations can choose to maintain their own proprietary security detection engines, building out bespoke firewalls and proxy infrastructures that come with significant maintenance overhead and low portability, all in exchange for maximum customization. Alternatively, they can accept the rigid constraints imposed by commercial security vendors, offloading the considerable maintenance costs at the expense of the flexibility required to solve unique problems native to their specific operational environments.
Over six years of developing Cloudflare Gateway, engineers have heard from thousands of customers who find themselves caught in this difficult trade-off. For instance, a security team attempting to migrate access controls for a critical internal enterprise application often needs to inject HTTP headers based on JSON Web Token (JWT) claims supplied by their identity provider. Because the required data exists within the request context, but standard gateways cannot read the JWT and write the corresponding header, teams are frequently forced to stand up entire pools of NGINX proxies solely to execute this single transformation. That auxiliary infrastructure must then be perpetually patched, monitored, and secured.
Another common scenario involves security teams that want to trigger real-time notifications via Slack the moment an employee signs up for an unauthorized or newly discovered SaaS service. While a traditional policy engine can easily detect the sign-up event, it is typically restricted to a binary allow or block action. To achieve the desired notification, the team is forced to construct a complex pipeline involving log pushes, security information and event management (SIEM) systems, and messaging tools, introducing a delay of five to fifteen minutes with no absolute guarantee of message delivery, thereby adding yet another layer of fragile infrastructure to maintain.
Similarly, dozens of enterprise customers have repeatedly requested warning pages that prompt users for explicit business justifications before granting access to sensitive destinations, followed by customized behaviors based on user identity and requested access levels. Delivering customized, dynamic responses from within a rigid policy engine has historically proven exceedingly difficult. While firewall vendors have introduced various extension points over the years, it remains virtually impossible for vendors to anticipate and build features for threat vectors as rapidly as they emerge. Recognizing this limitation, Cloudflare has designed its platform to be infinitely extensible to individual corporate environments.
Why Only Cloudflare Can Solve This Problem
Cloudflare occupies a unique position in the technology landscape because it is not merely a firewall, a secure web gateway, a content delivery network, or an edge service. It is a composable compute platform. Through Cloudflare Workers, customers already run 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 underlying hardware within the same data centers.
This unified architecture means that Cloudflare is uniquely positioned to combine distributed customer compute with a fully featured secure web gateway and firewall within a globally distributed network. Because Gateway and Workers were engineered on the same underlying infrastructure from the inception of the products, when Gateway forwards traffic to a Worker, that dispatch occurs as a local function call. There is no network hairpinning and no additional latency incurred by crossing external network boundaries. This integration grants customers absolute control over how their proxied traffic is processed, utilizing custom code without the operational burden of managing external infrastructure.
Standalone SASE providers that lack an integrated, native compute platform typically require enterprises to deploy automation scripts in a separate public cloud, manually configure webhooks, and accept the round-trip latency and management overhead of stitching together entirely disconnected systems. As digital threats evolve at speeds accelerated by artificial intelligence, this level of native flexibility and architectural agility becomes increasingly critical for enterprise security organizations.
Two New Gateway Entry Points: The Forward Action and Custom Functions
To bridge the gap between static policy enforcement and dynamic application logic, Cloudflare is introducing two distinct mechanisms to invoke a Worker from a Gateway policy: the Forward action and Custom Functions. The Forward action is available in public beta, while 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 HTTP requests to a Worker functioning as an inline proxy. Policies utilizing the Forward action are evaluated for traffic already permitted by standard HTTP policies. The first matching rule applies, sending the traffic to the designated Cloudflare Worker, which acts as inline middleware. The Worker receives the full headers and request body, enabling custom logic to modify requests before they reach the origin server, or to inspect and alter responses before they return to the end user.
Crucially, Cloudflare Gateway handles all underlying TCP connections, TLS termination, re-encryption, certificate management, and HTTP version negotiation. The Cloudflare Worker is responsible solely for the transformation logic, giving organizations a highly customizable extension point without the operational overhead of hosting traditional HTTP proxy servers. Furthermore, rules do not require traffic transformation; a rule can simply proxy a request to a Worker asynchronously to send Slack alerts, write logs to external pipelines, or update data stores while the primary traffic continues uninterrupted.
Custom Functions, on the other hand, call out to a Worker inline during the Gateway policy evaluation phase and return a typed value, such as a string, number, or boolean. Once defined, the function is exposed as a selectable parameter in the Gateway policy builder, usable in the condition of any network or HTTP rule just like built-in selectors such as source IP addresses or content categories. The Worker receives contextual information including source IPs, destinations, user identities, device posture states, and HTTP headers, processing the data and returning a deterministic value used directly in rule evaluations.
For example, administrators can deploy a custom function that parses an authorization header to extract a user’s specific organizational role, allowing them to construct rules where specific access privileges are granted dynamically based on group membership. Because these functions receive connection metadata and identity context, they can be deployed across both HTTP traffic and arbitrary Layer 4 port and protocol traffic within the network policy rule builder.
Expanding Capabilities Across Data Loss Prevention
This programmability framework extends beyond basic web filtering and secure web gateway functions into Cloudflare’s Data Loss Prevention platform. Traditional data security products typically rely on static patterns, such as regular expressions and word lists, to identify sensitive information. While keywords and contextual analysis help improve detection confidence, these conventional methods suffer from a fundamental limitation: they can only indicate whether data matches a specific pattern, not whether a specific instance of data represents an active risk of exfiltration or misuse.
To address this challenge, Cloudflare is introducing custom validation functions for its DLP platform. These validation capabilities allow organizations to define custom validation logic utilizing their own internal sources of truth directly inside a Cloudflare Worker, applying those checks across every environment protected by Cloudflare’s DLP suite. For instance, when a DLP detection engine identifies a potential API token or secret, an outbound Worker can dynamically query the relevant external API endpoint to verify whether the credential is active before an enforcement decision is made. If the token is verified as active, the security policy triggers; if the token is invalid or expired, the system can bypass the alert, dramatically reducing false positives.
Both the Forward action and the broader Workers integration are available in public beta, with custom functions expected to reach general availability before the conclusion of the year. By uniting secure web gateway enforcement, distributed edge compute, and data loss prevention into a single platform, Cloudflare aims to provide enterprise security teams with the architectural adaptability required to secure modern, fast-evolving digital environments.
Leave a Reply