A Fully Programmable Secure Web Gateway: Forward, Custom Functions, and DLP Validation with Workers!

Hi everyone, it's Shii-chan! Today I'm covering the Cloudflare Blog post about a fully programmable secure web gateway.

Cloudflare Blog blog.cloudflare.com

What was announced?

The Cloudflare Blog introduced the connection of Gateway and Data Loss Prevention (DLP) to Cloudflare Workers. There are three pieces:

• Forward action (public beta): a new Gateway policy action that routes matching HTTP traffic to a Worker
• Custom Functions (expected before end of 2026): Workers called inline during policy evaluation that return a value used as a selector in rule conditions
• DLP custom validation functions (available now): Workers that check whether a DLP match is actually relevant, such as whether a leaked credential is still active

At general availability, these are planned for all plan types, and the post says they are available to all Zero Trust plans.

What changes

You can write security policy decisions and traffic handling as Worker code instead of fixed settings. Examples from the post:

• Justification interstitials: ask for a reason before accessing a sensitive site, store a session with a TTL in KV, and log the justification to D1 or an internal database through Hyperdrive
• JWT-based header injection: a custom function reads the role from a JWT, and a rule sets an X-App-Role header upstream, replacing an NGINX proxy pool
• File inspection: send matching downloads to a third-party sandbox or save them to R2
• DLP alerting: post the user's email, the rule name, and the URL to Slack or PagerDuty when a DLP profile matches
• Complex logic: run risk scoring or multi-condition group checks and return a single value to Gateway

Dive Deep

How it works:

• Forward: the first matching rule sends the request to its bound Worker, which receives the headers and body. The Worker can modify the request, call the origin through next(), modify the response, and return it. Gateway handles TCP, TLS, certificates, and HTTP version negotiation. A Worker can also run asynchronously, such as sending an alert, while traffic continues unchanged
• Custom Functions: the Worker receives context such as source IP, destination, identity, device posture, and headers, and returns a string, number, or boolean. It appears in the policy builder as a selector for HTTP and Network rules, including Layer 4 port and protocol rules
• Performance: Gateway and Workers run on the same machines, so dispatch is a local function call with no extra network hop. Latency comes only from the Worker's execution time
• Failures: you set fallback behavior per custom function, and default values are required

In the DLP validation example, a Worker calls the GitHub API to check a GitHub token. It returns 1.0 if the token is active, "veto" if it is invalid (401), and 0 otherwise.

How to choose:

• Custom Functions: quick, bounded, stateless checks that return a value
• Forward: transformations of live traffic, which needs more planning since it can affect the user experience

On pricing, traffic sent to Workers is billed as standard Worker requests. Workers Free, Paid, and Enterprise all support these features with no functional restrictions, but Workers Free has execution time limits and daily request limits that matter at high Gateway traffic volumes. Email Security is the next service planned for custom dispatch.

Wrap-up

• Gateway and DLP connect to Workers, so you can control them in code
• Forward is in public beta, Custom Functions are expected before end of 2026, and DLP validation is available now
• Dispatch is local, with no extra network hop
• Plan Forward carefully, since it can affect the user experience

This one is for anyone who wants fine-grained Zero Trust policy driven by their own logic!