Cloudflare Gateway gains programmable Forward action and custom policy functions

Cloudflare has rebuilt its secure web gateway around customer-written code. According to the Cloudflare blog, the company is adding two ways to invoke Cloudflare Workers from Gateway policies: a new Forward action, in public beta now, and custom validation functions, expected before the end of the year. Both are being made available across Zero Trust plans.

The argument against static gateways

Cloudflare's framing is that every secure web gateway on the market, its own included until now, reduces to a condition plus a terminal action — allow, block, isolate or log. That model has underpinned network security for nearly 30 years, but it caps out in complex environments. The post also takes aim at how loosely the industry uses the word "programmability", arguing that public APIs, Terraform providers, webhooks and alerting do not qualify. By Cloudflare's definition, real programmability means running arbitrary customer logic inline, at the exact moment a security decision is made.

What the Forward action does

Forward is a new policy action that proxies a matched HTTP request to a bound Worker. It is evaluated for traffic that HTTP policies have already allowed, and the first matching Forward rule is the one applied. The Worker then behaves as inline middleware: it sees the full headers and request body, can rewrite either, call the origin, adjust the response on the way back, and return it to the user.

Gateway keeps ownership of the plumbing — TCP connections, TLS termination and re-encryption, certificate management and HTTP version negotiation — so the Worker carries only the transformation logic. Cloudflare pitches this as a proxy-like extension point without the operational cost of hosting a traditional proxy.

A Forward rule need not transform anything. Cloudflare notes that a rule can exist purely to fan a request's context out asynchronously: post to Slack, write to R2, update KV or call a webhook, while the traffic continues to its destination untouched.

Custom functions bring outside data into policy

The second mechanism, custom functions, calls a Worker inline during policy evaluation and uses its returned value as a selector in the Gateway policy builder. That selector can appear in the condition of any network or HTTP Gateway rule, letting teams bring their own data — identity attributes, risk signals, asset inventories — directly into allow and block decisions instead of post-processing events somewhere else.

The problems Cloudflare says this removes

The blog cites recurring scenarios from six years of building Gateway: a team that had to run a pool of NGINX proxies solely to inject HTTP headers derived from JWT claims in its identity provider; another that strung together Logpush, a SIEM and Slack to alert on SaaS sign-ups, accepting a 5-to-15-minute delay with no delivery guarantee; and enterprises wanting dynamic warning pages that ask users to justify access before reaching sensitive destinations. Each case exposed the same trade-off security teams have faced since firewalls existed: maintain bespoke proxy or detection infrastructure for maximum control, or accept a vendor's fixed feature set to shed the maintenance burden.

A co-located compute claim

Cloudflare argues it is uniquely positioned to fix this because Gateway enforces policy and Workers execute in the same 330-plus data centers, on the same machines. Dispatching traffic to a Worker is, per the company, handled locally as a function call, with no extra latency from crossing a network boundary. Standalone SASE vendors without a compute platform, the post contends, push customers into separate clouds, manual webhook configuration and round-trip overhead. These are vendor claims rather than independently benchmarked figures.

Why it matters

Secure web gateways have always been policy engines you can configure but not program. Moving customer code into the enforcement path — without operating proxy farms or event pipelines — dissolves a long-standing either/or between flexibility and managed infrastructure, and could shorten detection and response loops as threat activity accelerates. It is also a strategic differentiator: if co-located compute and security enforcement holds up in practice, it raises the bar for SASE competitors that must stitch together disconnected systems. For now, only the Forward action is in public beta; custom functions have not shipped yet, so the fully programmable gateway story will take until the end of the year to verify.