Cloudflare makes its secure web gateway and DLP programmable with inline Workers
On October 15, 2026, Cloudflare added a Forward action and Custom Functions to Cloudflare Gateway, running your own code at the exact moment a security policy makes its decision. If you maintain NGINX proxy pools for header injection or Logpush pipelines for alerting, replace them with a single Worker.
October 15, 2026. Cloudflare announces programmability for Cloudflare Gateway and its DLP (Data Loss Prevention) product via its edge computing platform. October 15, 2026. The Forward action enters public beta; Custom Functions land before the end of the year. 330+ locations. The network where the gateway and Workers already run on the same machines. Why it matters: for the first time, a team can run its own code at the exact point where the allow/block decision is made — without hosting a single proxy.
The binary trade-off every firewall imposes
Since firewalls existed, every security team has faced the same choice. Either it maintains its own detection engine — its firewall, its proxies — paying heavy operational overhead and low portability in exchange for total customization. Or it accepts a vendor’s constraints, offloads the maintenance, and loses the ability to solve problems specific to its own environment.
Cloudflare has heard this tension through six years of building Gateway. The clearest example: a team migrating access controls for a critical internal application needs to inject HTTP headers from the claims of a JWT issued by its identity provider. The data already sits in the request context, but Gateway can neither read the JWT nor write the header. So the team stands up a pool of NGINX proxies solely for that transformation — infrastructure that must be patched, monitored, and secured indefinitely.
Another team wants a Slack notification the moment an employee signs up for a new SaaS service. The policy engine detects the event, but it can only allow or block. So the team builds a Logpush → SIEM → Slack pipeline with five to fifteen minutes of delay and no guarantee of delivery.
In both cases the gateway already knows what needs to happen; it simply lacks permission to run the missing logic.
Why only Cloudflare can do it
The word “programmable” has been diluted across the industry. Most vendors claim it because they offer public APIs, Terraform providers, or webhooks. Cloudflare argues that real programmability means running your own code — arbitrary logic written for your environment — inline in the policy evaluation path, at the moment the security decision is made.
The structural advantage: Gateway and Workers run on the same machines, in the same data centers, across the network’s 330+ locations. When Gateway forwards traffic to a Worker, the dispatch is a local function call. There is no hairpinning and no latency from crossing a network boundary. That is what separates Cloudflare from standalone SASE vendors, which must deploy automation in a separate cloud and absorb the round-trip latency of stitching together disconnected systems.
Two entry points: Forward and Custom Functions
Two mechanisms let you call a Worker from a Gateway policy. The Forward action, available in public beta, and Custom Functions, expected before the end of the year.
The Forward action routes a matched HTTP request to a Worker that acts as inline middleware. The Worker receives the full headers and body, can modify them, forward to the origin, modify the response too, and return the final result to the user. Gateway keeps the TCP connections, TLS termination, certificates, and HTTP negotiation. The Worker carries only the transformation logic:
export class GatewayMiddleware extends WorkerEntrypoint {
async handle(request, context, next) {
const clientIP = context.srcIp;
request.headers.set("X-Gateway-Client-IP", clientIP);
const response = await next(request);
response.headers.set("X-Processed-By", "gateway-middleware");
return response;
}
}A Custom Function, by contrast, is called inline during policy evaluation and returns a typed value — string, number, or boolean — exposed as a selector in the rule builder, the same way a native selector like Source IP or Content Category works today. The contract is simple: data in, value out.
What you can build
Dynamic header injection. A Custom Function parses the JWT from the Authorization header, extracts the user’s role, and returns it as a selector value. A Gateway rule maps that value to an X-App-Role header on the upstream request. No NGINX pool, no extra infrastructure to maintain.
Real-time alerting on policy match. A Worker bound to a Forward policy receives traffic the moment a DLP profile matches, then posts a Slack or PagerDuty message with the user’s email, the fired rule, and the destination URL — with no pipeline delay.
Justification pages. A Worker intercepts access to a sensitive destination and returns an interstitial page asking the user to justify the request in writing. It writes the session to KV with a TTL so the prompt appears only once per period, and records the identity and justification in D1 for audit. This has been one of the most-requested features for over four years.
Performance, availability, and pricing
Because Gateway and Workers share the same machines, dispatching to a Worker introduces no network hop: the impact is limited to the execution time of your code. When a Custom Function fails — throws, times out, or returns an unexpected value — you configure per-function fallback behavior, and a default value is required by the contract.
On pricing, traffic dispatched to your Workers is billed as standard Worker requests across all plans. The Forward action is in public beta; Custom Functions and general availability will cover every plan type. Watch the Workers Free plan, whose execution-time and daily-request limits will bite if you push a large volume of Gateway traffic through it.
DLP learns to validate what it detects
The DLP piece makes the logic clearest. Data-protection products detect patterns — regular expressions, word lists — but they cannot tell whether a given match represents real exfiltration. A detected GitHub secret may have been revoked long ago. Custom validation functions, available today, close that gap: a Worker can call the GitHub API to check whether a detected key is still active, then decide whether the DLP profile should actually match.
File inspection. When a download matches certain criteria, a Worker can send the file to a third-party sandboxing service for detonation and analysis, or write it in full to R2 as a permanent record, without the file ever leaving the Cloudflare network.
What competitors cannot copy
Cloudflare’s position rests on an architectural coincidence that legacy SASE vendors — Zscaler, Netskope, or on-premises appliances — cannot replicate without rebuilding their networks. Those vendors own a gateway and a cloud, but not a compute platform co-located with the gateway. Their “programmability” therefore runs through webhooks, APIs, and external automation: the logic executes after the decision, never inside it.
That is the difference between a firewall you extend and a firewall you program. When threats evolve at AI speed, the former forces you to wait for the vendor’s next release; the latter lets the security team write the countermeasure itself, the same day. The Custom Functions usable in Layer 4 network rules make the point: the same logic applies to arbitrary TCP/UDP traffic, not just HTTP.
The alternative most products offer — exact data match against a reference dataset — forces you to prepare, maintain, and hand over copies of your most sensitive records to a vendor. Validation functions keep the source of truth inside your own Worker, so the check happens against your data, not a replica of it.
Verdict
If you maintain NGINX proxy pools for header injection, or Logpush → SIEM → Slack chains for alerting, migrate them to a Worker: you remove infrastructure you have to patch without losing the logic. If you run DLP on vendor secrets, test the validation functions so you block only still-active secrets — that is the difference between a false positive and an incident. If your SASE vendor has no co-located compute platform, remember that “programmable” means little: the code has to run in the decision path, not in a neighboring cloud.