Summary: On October 15, 2026, Cloudflare announced a programmable secure web gateway by connecting Gateway and DLP to Workers. A new Forward action routes matched HTTP traffic through a Worker as inline middleware, and custom functions let you return values used in rule conditions. This closes a long-standing gap: security policies could Allow, Block, Isolate, or Log, but couldn’t run your code at decision time.
The trade-off being removed
Per Cloudflare, security teams have historically chosen between building and maintaining their own proxy infrastructure for maximum customization, or accepting vendor constraints to avoid the maintenance burden. Their examples are familiar: a team standing up a pool of NGINX proxies just to inject HTTP headers from JWT claims, or stitching together a Logpush-to-SIEM-to-Slack pipeline that adds 5 to 15 minutes of delay to a simple sign-up alert. True programmability, in their framing, means running arbitrary logic inline in the policy evaluation path — not just having APIs and Terraform providers.
Forward: the Worker as middleware
The Forward action, in public beta, routes HTTP traffic that’s already allowed by an HTTP policy to a bound Worker. Gateway handles TCP, TLS termination and re-encryption, certificates, and HTTP version negotiation; your Worker only implements the transformation logic. The snippet Cloudflare shared shows the shape:
export class GatewayMiddleware extends WorkerEntrypoint {
async handle(
request: Request,
context: GatewayMiddlewareContext,
next: GatewayMiddlewareNext,
): Promise<Response> {
request.headers.set("X-Gateway-Client-IP", context.srcIp);
const response = await next(request);
response.headers.set("X-Processed-By", "gateway-middleware");
return response;
}
}The Worker can also skip transformation entirely and just observe asynchronously — write to R2, call a webhook, log to an external pipeline — while traffic continues unbothered. Because Gateway and Workers already run on the same machines, Cloudflare says the dispatch is a local function call with no hairpinning or added network latency.
Custom functions: selectors you define
Custom functions, coming before the end of the year, are narrower by design. A Worker receives request context (source IP, destination, identity, device posture, headers) and returns a typed string, number, or boolean. That value becomes a selector in any HTTP or network policy condition, usable like a built-in one such as Source IP. Cloudflare’s example parses a JWT and returns the user’s group, enabling rules like allowing finance_contractor without any proxy pool. Because the function receives metadata rather than the full request, it also works for Layer 4 network policies.
When to use which
Cloudflare’s own guidance: custom functions are for quick, bounded, stateless evaluations — extending selector data with internal sources. Forward is for live inline transformation on both request and response, which needs more care because mistakes hit the user experience directly.
The flagship use case is purpose justification: a Worker intercepts a sensitive destination, prompts the user for a written justification, stores a TTL’d session in KV so the prompt appears once per period, and writes an audit record to D1 or Hyperdrive. Cloudflare says this was their most-requested feature for over four years.
What this means for builders
If you run Zero Trust, the practical shift is deleting sidecar infrastructure. Header injection proxies, alert pipelines, and one-off transformation services can collapse into a Worker bound to a Gateway policy. It also pairs naturally with existing patterns — if you’re already securing internal apps at the edge, per our earlier post on one-click protection for vibe-coded Workers apps, Gateway-level customization extends that control into traffic policy itself.
One limitation to plan around: Forward puts your code in the live request path, so test latency and failure behavior before shipping. Custom Functions’ December availability date is Cloudflare’s stated target, not a guarantee.