Cloudflare Adds Programmable Workers to Gateway and DLP

A new Forward action and custom functions

Cloudflare announced two ways to run customer written code inside Cloudflare Gateway: a policy action called Forward and a policy resource called a custom function. Forward is in public beta now, while custom functions are expected before the end of the year. Both will be available on all plan types at general availability.

For nearly 30 years, secure web gateways have worked the same way: traffic matches a condition and a terminal action fires, such as Allow, Block, Isolate or Log. Cloudflare argues that public APIs, Terraform providers, webhooks and alerting are not real programmability. True programmability means running your own arbitrary logic inline at the moment a security decision is made.

The Forward action routes matched HTTP traffic to a Cloudflare Worker that acts as inline middleware. The Worker receives the full headers and request body, can modify them, forward the request to the origin, modify the response and return it to the user. Gateway handles TCP connections, TLS termination and certificate management. Rules can also pass request context to a Worker for side effects, such as a Slack message, a write to R2 or a webhook call, while traffic continues to its destination.

Custom functions call a Worker inline during policy evaluation. The Worker receives request context including source IP, destination, user identity, device posture and HTTP headers, and returns a typed value, such as a string, number or boolean. That value becomes a selector in the policy builder, usable in any network or HTTP rule alongside built in selectors like Source IP or Content Category, including for Layer 4 traffic.

No extra network hop

Cloudflare says Gateway and Workers run on the same machines in the same data centers across its 330 plus locations, so dispatching to a Worker is a local function call with no hairpinning and no added network latency. Performance impact is limited to the execution time of the Worker code. When a custom function fails, throws, times out or returns an unexpected value, administrators configure per function fallback behavior. Traffic is billed as standard Worker requests on Workers Free, Paid and Enterprise plans.

What customers can build

Cloudflare listed several use cases. A Worker can serve an interstitial page requiring written justification before access to a sensitive destination, store sessions in Cloudflare KV with a TTL and write an audit trail to D1 or Hyperdrive connected databases. Custom functions can parse a JWT and return the user's role as a selector, letting a rule inject an X App Role header without maintaining an NGINX proxy pool. Workers can send files to third party sandboxing services or store them in R2, push alerts to Slack or PagerDuty when a DLP profile matches, and run internal risk scoring logic as a deterministic extension to the policy engine.

DLP validation functions

Cloudflare also extended the approach to data loss prevention. DLP custom validation functions are available starting today and let customers define their own validation logic in a Worker using their own source of truth. In one example, a Worker intercepts a detected GitHub secret, checks its status through the GitHub API and returns a score that confirms, discards or rejects the match before policy enforcement. Dispatch entry points will expand across Cloudflare One, with Email Security coming next.

Sources: Cloudflare