- Cloudflare announced on October 15 that Gateway rules can call customer-written Workers, through a Forward action in public beta and custom functions it expects before year end.
- Cloudflare says the change can replace side infrastructure like proxy pools and alert pipelines, but it makes policy code something the customer must own, test and plan failure for.
- Leaders should ask who owns that code, what happens when a function fails, and what the traffic will cost on the Workers plan.
A security rule is becoming a small program
For nearly 30 years, a secure web gateway has made one kind of decision. Traffic matches a condition. One action fires: allow, block, isolate or log. Cloudflare says this model handles the common case well but hits a ceiling in complex environments.
On October 15, Cloudflare announced a way past that ceiling. Customers can send matched traffic to their own code through a Forward action, now in public beta. Cloudflare expects to let that code feed rule conditions, through custom functions, before the end of the year. The lesson here is that a security rule is turning into a small piece of software. That brings flexibility. It also gives the customer a new job: someone must own, test and monitor that code.
What the ceiling costs today
Cloudflare describes two teams that hit it. The first needed to add HTTP headers based on claims in a JSON Web Token, a signed login token from the identity provider. Gateway could not read the token and write the header. So the team built a pool of NGINX proxy servers just for that task. Those servers must be patched and monitored.
The second team wanted a Slack message when an employee signed up for a new SaaS service. The policy engine could detect the event but only allow or block it. The team built a pipeline from Logpush to a SIEM to Slack. Alerts from that chain arrived between five and fifteen minutes late, and delivery was not assured.
Both teams ended up with extra infrastructure that did nothing but make up for a gap in the policy engine.
How the two new pieces work
The Forward action is in public beta. It sends a matched HTTP request to a Cloudflare Worker, a small program that runs on Cloudflare's network. The Worker sees the full headers and body. It can change either one, pass the request to the origin, change the response, and return the result to the user.
Gateway still handles the TCP connections, TLS encryption, certificates and HTTP version negotiation. The Worker handles only the transformation logic. A Worker can also take a copy of the request context and act on the side, such as posting to Slack or writing to storage, while the traffic continues.
Custom functions work differently, and they are not released yet. During policy evaluation, Gateway would call a Worker, which returns a string, number or true/false value. That value appears as a selector in the rule builder, like Source IP. Cloudflare's example parses a JWT, returns the user's role, and lets a rule allow anyone whose role contains "finance_contractor". Cloudflare also describes a version that sets an X-App-Role header with no NGINX proxy pool. That fix depends on custom functions, so it cannot be tried until they ship. Cloudflare says it expects them before the end of the year.
Cloudflare says Gateway and Workers run on the same machines, so the call is local and adds no network hop. That is the vendor's own claim. WebPulse has not tested it.
Data loss rules get a second opinion
Cloudflare also extends data loss prevention (DLP), which scans traffic for sensitive data. Cloudflare says most data security products look for data that matches known patterns. Such matching shows that data fits a pattern. It cannot show whether this specific data is relevant to your organization or being misused. The usual fix, exact data match, means preparing reference datasets and sending them to a vendor.
Cloudflare says its new custom validation functions let customers run their own check, against their own source of truth, inside a Worker. The company says these are available now.
What the code owner inherits
Think of a thermostat with fixed presets against one you can program. You gain control, and you also own the schedule. A Worker in the policy path works the same way. A bug there is no longer a vendor bug.
Cloudflare addresses part of this. Each custom function must declare default values. If the function throws an error, times out or returns something unexpected, the customer sets the fallback. The source does not say what the right fallback is. That is a business decision. Should a failed role lookup let a request through or stop it?
Cloudflare also says Forward Workers should be "targeted and designed carefully" to protect the user experience. Traffic sent to Workers is billed as standard Worker requests. Workers Free has execution time limits and daily request limits.
Questions to put to your team
First, which side systems exist only to work around gateway limits, and what does it cost to patch and watch them? Second, who owns and reviews each Worker that sits in a policy path? Third, for every function, is the failure default allow or block, and who chose it? Fourth, how much traffic would be sent to Workers, and what does that cost on your plan?
Forward is a beta, and custom functions are not yet released. This is one vendor's announcement, not a measured trend. Treat it as an option to evaluate, not a settled answer.
Programmable security removes a ceiling. It also removes the excuse that the vendor's rules were the only rules.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
