Cloudflare's Programmable Secure Web Gateway with Edge Compute

The Challenge of Traditional Secure Web Gateways

Traditional Secure Web Gateways (SWG) operate on a rigid 'match condition, fire terminal action' model (Allow, Block, Isolate, Log). While effective for common use cases, this model quickly hits a ceiling for enterprises requiring complex, environment-specific security logic. Businesses historically face a binary choice: either manage highly customized, high-overhead on-premise security infrastructure or accept the limitations of a vendor's off-the-shelf solution, sacrificing flexibility.

Cloudflare's Programmable SASE Vision

Cloudflare redefines 'programmability' in the context of a Secure Access Service Edge (SASE) platform. Beyond public APIs and webhooks, true programmability means executing arbitrary user-written code inline within the security policy evaluation path. This allows for bespoke logic to be applied at the moment a security decision is made, addressing complex scenarios like dynamic HTTP header injection based on JWT claims, real-time notifications for security events, or custom interstitial pages with audit trails.

Architectural Integration: Gateway and Workers

The core innovation lies in Cloudflare's unique ability to co-locate its distributed customer compute platform (Cloudflare Workers) with its full-featured SWG and firewall within the same globally distributed network. Since Gateway and Workers share the same underlying infrastructure, dispatching traffic from Gateway to a Worker is a local function call with no additional latency or hairpinning. This eliminates the need for customers to deploy and maintain external proxies or stitch together disconnected cloud systems, significantly reducing operational overhead.

Programmability Entry Points

• Forward Action: A new Gateway policy action that routes matched HTTP requests to a Worker as a proxy. The Worker acts as inline middleware, receiving full request/response bodies and headers, allowing for powerful transformations, modifications, and asynchronous actions (e.g., logging to R2, sending Slack messages) before traffic reaches the origin or returns to the user.
• Custom Functions: These call a Worker inline during Gateway policy evaluation to return a typed value (string, number, boolean). This value is then used as a selector in Gateway rule conditions, extending policy logic with arbitrary external data or complex calculations (e.g., parsing JWTs for user roles). Custom functions are not limited to HTTP and can leverage identity, device posture, and connection metadata for Layer 4 traffic.

import { WorkerEntrypoint } from "cloudflare:workers";
import type { GatewayMiddlewareContext, GatewayMiddlewareNext } from "@cloudflare/zt-types";

export class GatewayMiddleware extends WorkerEntrypoint {
  async handle(
    request: Request,
    context: GatewayMiddlewareContext,
    next: GatewayMiddlewareNext,
  ): Promise<Response> {
    // Add headers before the request reaches the origin based on Gateway context
    request.headers.set("X-Gateway-Client-IP", context.srcIp);

    // Forward upstream and get the response
    const response = await next(request);

    // Modify the response before it reaches the user
    response.headers.set("X-Processed-By", "gateway-middleware");
    return response;
  }
}

This architecture shifts the paradigm from static rule-based security to a dynamic, code-driven approach, empowering security teams with unprecedented flexibility to address evolving threat landscapes and unique organizational requirements.