Skip to content

CLOUDFLARE 2026-10-15

Read original ↗

Cloudflare: A fully programmable secure web gateway

Summary

Cloudflare is making Cloudflare Gateway and its DLP (Data Loss Prevention) engine programmable by letting customers run their own Cloudflare Worker code inline in the policy evaluation and enforcement path. The pitch is that every secure web gateway for ~30 years has worked as "traffic matches a condition → a terminal action fires (Allow / Block / Isolate / Log)," and that model has a ceiling: complex environments repeatedly need custom logic the vendor can't ship fast enough. Three new primitives break that ceiling — a new Gateway Forward action (public beta) that routes a matched HTTP request to a Worker acting as inline proxy middleware; Custom Functions (GA by end of year) that call a Worker during policy evaluation and expose its typed return value as a selector in the rule builder; and DLP custom validation functions (available now) that run a Worker to validate a detection against the customer's own source of truth before the DLP profile matches. Because Gateway and Workers run on the same machines in the same 330+ locations, the dispatch to a Worker is a local function call — no hairpinning, no network boundary — so the only added latency is the Worker's own execution time. The strategic claim: only a vendor that co-locates a full programmable compute platform with its SWG can offer this without customers stitching together a separate automation cloud. (Source: programmable-gateway-dlp)

Key takeaways

  1. The trade-off being attacked. For as long as firewalls have existed, teams chose between (a) running their own detection engine / proxy fleet — max customization, high maintenance, low portability — or (b) accepting a vendor's constraints — low maintenance, low flexibility. Cloudflare argues true programmability means running your own arbitrary code inline in the policy evaluation path at the moment the security decision is made, not just public APIs, Terraform providers, webhooks, and alerting (which it says every vendor has and which it dismisses as diluted "programmability"). (Source: sources/2026-10-15-cloudflare-a-fully-programmable-secure-web-gateway)

  2. Forward action = inline proxy middleware. A new policy action called Forward routes a matched HTTP request to a bound Worker. The Worker gets full headers + request body, can mutate the request, call next(request) to forward upstream, receive the response, mutate that too, and return the final response to the user — the classic middleware shape. The contract is a WorkerEntrypoint subclass with an async handle(request, context, next) method; context exposes Gateway state like context.srcIp. Forward policies are evaluated only for traffic already allowed by HTTP policies; the first matching Forward rule wins. Public beta today.

  3. Gateway keeps the hard parts; the Worker only transforms. Gateway still owns TCP connections, TLS termination + re-encryption, certificate management, and HTTP version negotiation. The Worker is responsible only for transformation logic — "a customizable, proxy-like extension point for your existing security stack, with none of the operational cost of hosting a traditional HTTP proxy." This is the explicit replacement for the "stand up a pool of NGINX proxies just to inject a header from a JWT claim" anti-pattern.

  4. A Forward rule need not transform at all — it can be a side-effect tap. A Worker can receive the full matched-request context asynchronously and fire a Slack message, write to R2, log to an external pipeline, call a webhook, or update a KV store, while the traffic continues to its destination "unbothered." This directly collapses the "Logpush → SIEM → Slack with 5–15 min delay and no delivery guarantee" pipeline into a real-time inline tap.

  5. Custom Functions = programmable selectors (data in, value out). A Custom Function calls a Worker inline during policy evaluation via an async compute(ctx) method and returns a typed value (string / number / boolean). Gateway exposes that value as a selector in the policy builder, usable in any network or HTTP rule condition exactly like a built-in selector (Source IP, Content Category). Example: parse the JWT Authorization header, return the user's first group, then write a rule Custom Function "JWT Role" contains "finance_contractor" → Allow. From Gateway's view the function is deterministic: data in, value out — even though the Worker underneath may call external APIs, read KV/D1, or invoke Workers AI. GA by end of year.

  6. Custom Functions work at L4 too, not just HTTP. Because they receive identity, device posture, and connection metadata (not necessarily the full HTTP request — it depends on the policy phase), they can be used in the Gateway Network policy builder against arbitrary L4 port/protocol traffic, not only HTTP.

  7. Forward vs Custom Function — the design guidance. Custom Functions are for quick, bounded, stateless evaluations that return a shaped value — think "ports within this range" or "URL paths matching this regex," extended with arbitrary/internal data sources. The Forward action is for powerful inline transformations of a live user request on egress and on the return path, and "should be thought of as transformation functions, something very few enterprise security proxies even conceptualize today" — needing careful, targeted design to avoid harming UX.

  8. No network hop by construction. "Gateway and Workers were built on the same infrastructure from the beginning. When Gateway forwards traffic to a Worker, that dispatch is a local function call. There is no hairpinning. There is no additional latency from crossing a network boundary." The only perf cost is the Worker's own execution time. This is the whole competitive moat vs standalone SASE vendors who must deploy automation in a separate cloud and eat round-trip latency + management overhead. (See patterns/co-located-inference-in-serving-layer — the same "move the code to where the traffic already is, not the traffic to the code" logic, applied to a security gateway rather than an ML serving node.)

  9. Reliability contract: default values are mandatory. When a Custom Function fails — throws, times out, or returns an unexpected value — the fallback behavior is configured per function, and a default value is required in the function contract so the rule's behavior under failure is always determinate. This is an explicit fail-open/fail-closed decision pushed to the customer at authoring time. (DLP validation has an analogous "veto" return — see takeaway 11.)

  10. DLP custom validation = "is this specific instance real?" not "does it match a pattern?" Pattern-based DLP (regex, word lists, keyword/context confidence) can only tell you data matches the shape of something sensitive, not whether this instance indicates real exfiltration. Exact data match helps but forces customers to prepare/maintain/transfer reference datasets and trust the vendor with their most sensitive source data. DLP custom validation functions instead let the customer run their own validation logic against their own source of truth inside a Worker, applied everywhere DLP is used (Gateway, AI Gateway, Email Security, and more). Available now.

  11. DLP validation contract — credential/secret liveness example. A DlpValidation entrypoint with async validate({excerpt, start, end}) returns a DlpValidationResult. The worked example detects GitHub secrets but only active ones: it decodes the matched excerpt, extracts the token, calls https://api.github.com/user with it, and returns { score: 1.0 } if the token is valid (200), { score: "veto" } on 401 to discard the match entirely, else { score: 0 }. So validation runs before the policy enforcement decision and can veto a would-be match. This is live credential verification against the real system of record.

  12. What customers can build (named use cases). (a) Purpose justification / interstitial pages — a Worker returns an interstitial demanding a written justification, writes a KV session with a TTL so the user is prompted only once per period, and writes identity + justification to D1 (or to any internal DB via Hyperdrive) as an audit trail. Cloudflare says this has been a top-requested feature for 4+ years. (b) Dynamic HTTP header injection from JWT claims — "no NGINX proxy pool." (c) File inspection — route a matched download to a third-party sandbox for detonation, or write the whole file to R2 without it leaving Cloudflare's network. (d) Real-time alerting on DLP match → Slack/PagerDuty with user email, rule name, destination URL. (e) Complex evaluation logic — internal risk scoring / behavioral analysis / conditional group membership computed in a Worker and reduced to a single selector value.

  13. Availability, pricing, roadmap. Forward is public beta today; Custom Functions GA by end of year; at GA both are on all plan types. Traffic dispatched to Workers bills as standard Worker requests (Free / Paid / Enterprise), with Free's execution-time and daily-request limits called out as a scaling consideration. The DLP validation feature is live now. Next entry point is Email Security; the stated meta-benefit is that this architecture also lets Cloudflare ship its own first-party Cloudflare One features faster.

Systems / concepts / patterns extracted

  • Systems: Cloudflare Gateway (primary subject — the SWG getting programmable), Cloudflare Workers (the inline compute, co-located with Gateway), Cloudflare One (the Zero Trust/SASE suite this ships under), DLP / Data Loss Prevention (significant secondary subject — custom validation functions; no dedicated page, see note), plus data/compute bindings named as building blocks: KV, D1, R2, Hyperdrive, Workers AI, and the other DLP integration surfaces AI Gateway and Email Security.
  • Concepts: concepts/control-plane-data-plane-separation (user code injected into the data plane's enforcement path — the data plane becomes programmable), concepts/fail-open-vs-fail-closed (mandatory default values / per-function fallback; DLP "veto"), concepts/network-round-trip-cost (eliminated by co-location — the local function call), concepts/audit-trail (justification pages writing identity+reason to D1), concepts/policy-as-data (adjacent but distinct — this is policy-as-code inline, see note), concepts/defense-in-depth, and TTL-based session gating for interstitial prompts.
  • Patterns: patterns/central-proxy-choke-point (Gateway is the canonical SWG choke point; programmability extends what the choke point can do inline), patterns/co-located-inference-in-serving-layer (same "move code to the traffic, not traffic to the code" moat, re-expressed for a security gateway), patterns/caching-proxy-tier (adjacent proxy-middleware framing).
  • Not minted as pages (taxonomy gate — single source, no _taxonomy.md entry): "programmable data plane / user-code inline in the vendor's policy evaluation path" and "inline validation veto before enforcement" are recorded here as tags and in prose only. If a second source describes customer code running inline in a vendor enforcement path, promote via Lint. DLP is listed in systems: frontmatter (second occurrence overall, but this article is its primary architectural description — kept as a plain-text mention, no page, per Systems gate until a dedicated DLP post lands).

Operational numbers / concrete details

  • 330+ locations run both Gateway and Workers on the same machines (the co-location claim).
  • ~30 years — age of the "match condition → terminal action" SWG model Cloudflare says it is breaking.
  • 4+ years — how long interstitial/justification pages have been a top-requested feature.
  • 5–15 min — the delivery delay of the Logpush→SIEM→Slack pipeline the inline Forward tap replaces.
  • Dispatch latency added by forwarding to a Worker = the Worker's execution time only (no network hop); no numeric figure given.
  • DLP validation return codes: {score: 1.0} (valid/active), {score: "veto"} (discard match), {score: 0} (no signal).
  • Billing: Worker dispatches = standard Worker requests; Workers Free has execution-time + daily-request caps.

Caveats

  • This is an announcement / product post, not an internals deep-dive: it ships code-shape examples (WorkerEntrypoint.handle, compute, DlpValidation.validate) and the co-location argument, but gives no throughput, latency, or failure-rate numbers, no detail on how Gateway binds a Worker, isolate scheduling under Forward load, ordering guarantees for the async side-effect case, or what "unexpected value" triggers the Custom Function fallback. It passes the scope filter because it describes a concrete architectural capability (inline user compute in the SWG enforcement path, the co-location rationale, the data-in/value-out and middleware contracts) rather than being pure marketing — borderline product launch with ≥20% real architecture content.
  • Forward is public beta; Custom Functions are not yet GA (end-of-year target). DLP custom validation is GA now.
  • The "only Cloudflare can do this" framing is the vendor's own competitive claim.

Source

Last updated · 854 distilled / 2,448 read