14 Jan 2026 · 7 min read
What is a cloud WAF?
A clear, technical explanation of cloud web application firewalls: what they protect, how they enforce policy at the edge, and how a cloud WAF differs from legacy appliances.
What a web application firewall does
A web application firewall (WAF) is a security layer that sits in front of your web applications and APIs and inspects HTTP traffic. Where a network firewall reasons about ports and IP addresses, a WAF reasons about the request itself: the method, the path, the headers, the query string, cookies, and the body. That request-level visibility is what lets a WAF recognise the patterns behind common attacks — SQL injection, cross-site scripting, path traversal, command injection, and the other categories that dominate the OWASP Top 10 — and act on them before they reach application code.
The job of a WAF is enforcement at the application layer. It evaluates each request against a policy and decides what should happen: allow it through, log it for review, or reject it. Done well, that enforcement is a control plane for your edge security posture rather than a static appliance you configure once and forget.
So what makes a WAF a “cloud” WAF?
A cloud WAF is a web application firewall delivered as a managed service at the edge, rather than as software you install and operate on your own hardware or inside every application deployment. Traffic to your domains is routed through the provider’s enforcement layer first; requests are inspected and filtered there, and only traffic that passes policy continues to your origin servers. You manage policy through an API or console; the provider runs the data plane.
The practical difference is operational. A cloud-native web application firewall scales horizontally with your traffic, ships rule and engine updates centrally, and is administered as configuration rather than as boxes in a rack. You define what protection should look like; the platform is responsible for running it consistently across every point of presence.
How edge enforcement works
Edge enforcement means the WAF inspects and filters HTTP traffic before it reaches the origin. A request arrives at an edge node, the connection is terminated, and the WAF evaluates the full request against the active policy. Benign requests are forwarded to your application; requests that match the policy’s blocking criteria are stopped at the perimeter, so malicious payloads never touch your backend.
Pushing this work to the edge has two benefits. First, attacks are absorbed away from your origin, which keeps malicious load off the systems you care about most. Second, enforcement is consistent: the same policy applies to every request to a domain, regardless of which backend ultimately serves it. For an enforcement layer to be trustworthy it also has to be resilient — it should boot from a known-good configuration and keep serving the last-known-good policy if its control channel is briefly unavailable, rather than failing open or falling over.
Cloud WAF vs legacy appliance or self-hosted ModSecurity
The traditional way to run a WAF was a hardware appliance or a module bolted onto your web server — classically ModSecurity running inside Apache or NGINX. That approach can work, but it puts the operational burden on you: you size and patch the appliances, you maintain the rule sets, you tune every node by hand, and you scale by buying or provisioning more capacity. Configuration tends to drift between instances, and changes are slow and risky to roll out.
A cloud WAF inverts that model. It is managed, so the provider runs and patches the data plane. It is scalable, so capacity follows traffic instead of hardware purchasing cycles. And, in a modern implementation, it is programmable: policy is expressed as API resources with versioning, so changes are reviewable and reversible instead of being typed into a config file on a server. That shift — from boxes you maintain to policy you manage as code — is the real value of moving to the cloud, not just the relocation of where the software runs.
Where OWASP CRS and Coraza fit
Credible WAF protection rests on a transparent detection baseline. The OWASP Core Rule Set (CRS) is the open, community-vetted set of rules that defines what suspicious traffic looks like across the common attack categories. Because it is open, you can see exactly what is being detected and why — there is no opaque, proprietary “magic” deciding the fate of your traffic.
CRS needs an engine to run it. Coraza is a modern, open-source WAF engine that executes CRS rules and is embeddable directly in an edge data plane. Together they provide a detection foundation you can reason about: CRS supplies the rules, Coraza evaluates them, and the platform around them turns the results into enforcement decisions. ArxLayer Edge runs Coraza with the OWASP Core Rule Set for exactly this reason — protection built on standards you can inspect rather than trust blindly.
Detection versus blocking — and why the order matters
It is tempting to assume a WAF should block everything suspicious from day one. In practice, that is how you break legitimate traffic. CRS uses anomaly scoring: instead of a single rule instantly rejecting a request, matching rules contribute to a cumulative score, and a request is blocked only when that score crosses a configured threshold. Paranoia levels let you dial how aggressive detection is. This makes blocking a deliberate, tunable decision rather than an all-or-nothing switch.
The safe way to adopt enforcement is a detect → tune → block path. You start in a detection posture where the WAF scores and records what it would block without affecting live traffic. You review those events, identify false positives, and add targeted exclusions for the legitimate patterns specific to your application. Only once the signal is clean do you move that policy into blocking mode. The result is enforcement that stops real attacks without taking down real users — and a clear audit trail explaining every decision along the way.
When you actually need a cloud WAF
A cloud WAF earns its place anywhere you expose HTTP endpoints to a network you do not control. Some common cases where it is hard to do without:
- SaaS platforms, where you are responsible for protecting your own product and, often, customer-facing custom domains at scale.
- Public and partner APIs, which expose business logic directly and need request-level inspection rather than just network controls.
- Multi-tenant systems, where you need consistent policy and isolation across many tenants without managing infrastructure per tenant.
- AI-agent endpoints, where automated clients and machine identities call your APIs at volume and that traffic needs the same scrutiny as everything else.
In all of these, the common thread is the same: a large, internet-facing application-layer attack surface that you need to defend uniformly, update centrally, and operate without standing up and babysitting your own WAF fleet.
How ArxLayer approaches it
ArxLayer is an API-first, event-driven web security platform. Its WAF runs on Coraza with the OWASP Core Rule Set, so the detection baseline is open and inspectable. Policy lives in an API-first control plane as versioned resources, and configuration is distributed to the edge over an event bus so changes roll out quickly and observably. Enforcement supports the safe detect → tune → block workflow, with the evidence you need to make blocking decisions with confidence. And by design, the WAF layer holds no private keys — certificate lifecycle and key custody are handled by separate boundaries, so an enforcement layer stays an enforcement layer. You can see how the pieces fit together on the architecture page, or explore what the platform protects on the product overview.