Glossary · Cybersecurity architecture WAF (Web Application Firewall)
Security layer that inspects HTTP/HTTPS traffic to and from web applications, blocking attacks like SQL injection, XSS, and OWASP Top 10 exploits before they reach the origin server. Delivered either as a reverse-proxy service (Cloudflare, AWS WAF) or as an agent at the origin (CrowdSec, ModSecurity, HAProxy).
## What a WAF actually does
A Web Application Firewall inspects HTTP/HTTPS requests and responses moving between a client and a web application, applying rules that identify and block attacks that a network-layer firewall (which sees only IP/port information) cannot recognise. The canonical attack categories covered:
- **SQL injection** — malicious input targeting the database layer
- **Cross-site scripting (XSS)** — injecting client-side script into pages served to other users
- **Cross-site request forgery (CSRF)** — tricking authenticated users into performing unwanted actions
- **Server-side request forgery (SSRF)** — coercing the server into making requests to attacker-controlled URLs
- **XML External Entity (XXE)** — abusing XML parsers to exfiltrate data
- **Path traversal** — accessing files outside the intended directory
- **Command injection** — passing shell metacharacters to system calls
- **File upload attacks** — malicious files disguised as legitimate uploads
- **Authentication bypass and session-management flaws**
- **Business-logic abuse** — application-specific misuse (rate-limited endpoints, coupon-code abuse, credential stuffing)
The reference ruleset for most WAFs is the **OWASP Core Rule Set (CRS)**, an open-source library of pattern-based detection rules maintained by the OWASP Foundation.
## Two deployment architectures
WAFs come in two fundamentally different architectures — and the choice has structural sovereignty implications.
### Reverse-proxy WAF (cloud-hosted)
Traffic is routed to the vendor's edge network first. The vendor inspects, filters, and (if legitimate) forwards to the origin. Examples:
- **Cloudflare WAF** (US, Delaware, NYSE: NET)
- **AWS WAF** (US, Delaware, Nasdaq: AMZN)
- **Akamai Kona** (US, Nasdaq: AKAM)
- **Fastly Next-Gen WAF** (US, NYSE: FSLY)
- **Bunny.net Shield** (Slovenia, EU-controlled)
The reverse-proxy model gives the vendor enormous power (Tbps-scale DDoS absorption, global CDN, edge compute) but routes customer traffic through the vendor's infrastructure — which becomes a jurisdictional exposure if the vendor is US-parent.
### Agent-based WAF (self-hosted or on-origin)
An agent runs on the origin server (or in front of it as an inline component), inspecting traffic without routing it through an external service. Examples:
- **CrowdSec AppSec Component** (France, MIT-licensed)
- **ModSecurity** (open source, historically the reference)
- **Coraza** (Go-based ModSecurity successor)
- **HAProxy Enterprise WAF**
- **NGINX App Protect**
- **AWS-shield agent-modes**
Agent-based WAFs keep customer traffic on your own infrastructure. The vendor sees rule updates and telemetry aggregates, not the raw request stream.
## Sovereignty implications
Under the reverse-proxy model, customer traffic — including request bodies containing personal data, payment information, authentication credentials, and API tokens — flows through the WAF vendor's infrastructure. For a US-parent vendor, that flow is exposed to CLOUD Act and FISA Section 702 reach:
- Cloudflare, AWS WAF, Fastly, Akamai — parent is US-incorporated.
- Under CLOUD Act, US authorities can compel the vendor to disclose data it processes, including in-flight EU customer requests.
For European organisations operating in regulated sectors — banking, healthcare, public administration, defence — routing customer traffic through a Delaware-corp WAF is often a compliance exposure that requires either an EU-parent reverse-proxy alternative (Bunny.net Shield) or an agent-based architecture (CrowdSec + a European CDN).
## The CrowdSec + Bunny.net pattern
A common European-sovereign replacement pattern for Cloudflare's combined WAF + CDN + DDoS offering:
1. **CrowdSec** (Paris SAS, MIT open source, agent-based) handles WAF + bot management + IP reputation — running on your servers, no US-corp intermediary.
2. **Bunny.net** (Slovenia) handles CDN edge caching and origin shielding under EU jurisdiction.
3. Optional: **OVHcloud Anti-DDoS** or **Bunny Shield** handles network-layer volumetric DDoS scrubbing.
The combined stack replaces Cloudflare's useful functional surface while keeping traffic under EU-jurisdiction custody at every hop.
## NIS2 and DORA implications
- **NIS2** essential and important entities must document security controls including WAF architecture. For public-sector-adjacent entities, the WAF vendor's jurisdiction is increasingly a documented consideration.
- **DORA** operational-resilience testing for financial services requires threat-led penetration testing that covers external attack surface — including the WAF layer. Testing must include realistic adversary scenarios; if the WAF vendor itself sits in a jurisdiction where regulatory reach could be compelled, that is an operational risk factor.
## Free / open-source WAFs
For teams wanting genuine open-source WAF capability:
- **ModSecurity** — the historical reference, moved from Trustwave-maintained to OWASP-maintained in 2024. Solid but v3 has been end-of-life notice.
- **Coraza** — the modern Go-based successor recommended by OWASP for new deployments.
- **CrowdSec AppSec Component** — MIT-licensed, integrates with CrowdSec's crowdsourced blocklist and Security Engine.
For most European teams building sovereign infrastructure, the combination of Coraza (or CrowdSec AppSec) at the application edge + CrowdSec Security Engine watching logs + Bunny.net for CDN gives a fully open-source, EU-jurisdiction WAF stack at low cost.
Was this helpful?
Thanks for your feedback!