Glosario · Arquitectura de ciberseguridad WAF (Web Application Firewall)
Capa de seguridad que inspecciona el tráfico HTTP/HTTPS hacia y desde aplicaciones web, bloqueando ataques como la inyección SQL, XSS y los exploits del OWASP Top 10 antes de que lleguen al servidor de origen. Se entrega como servicio de proxy inverso (Cloudflare, AWS WAF) o como agente en el origen (CrowdSec, ModSecurity, HAProxy).
## Qué hace realmente una WAF
Un Web Application Firewall inspecciona las solicitudes y respuestas HTTP/HTTPS que se mueven entre un cliente y una aplicación web, aplicando reglas que identifican y bloquean ataques que un cortafuegos de capa de red (que solo ve información de IP/puerto) no puede reconocer. Las categorías canónicas de ataques cubiertas:
- **Inyección SQL** — entrada maliciosa dirigida a la capa de base de datos
- **Cross-site scripting (XSS)** — inyectar script en el cliente en páginas servidas a otros usuarios
- **Cross-site request forgery (CSRF)** — engañar a usuarios autenticados para realizar acciones no deseadas
- **Server-side request forgery (SSRF)** — obligar al servidor a hacer peticiones a URLs controladas por el atacante
- **XML External Entity (XXE)** — abuso de parsers XML para exfiltrar datos
- **Path traversal** — acceso a archivos fuera del directorio previsto
- **Inyección de comandos** — pasar metacaracteres de shell a llamadas al sistema
- **Ataques por subida de archivos** — archivos maliciosos disfrazados de subidas legítimas
- **Bypass de autenticación y fallos de gestión de sesión**
- **Abuso de lógica de negocio** — uso indebido específico de la aplicación (endpoints con rate limit, abuso de códigos promocionales, credential stuffing)
El conjunto de reglas de referencia para la mayoría de las WAF es el **OWASP Core Rule Set (CRS)**, una biblioteca de código abierto de reglas de detección basadas en patrones mantenida por la OWASP Foundation.
## Dos arquitecturas de despliegue
Las WAF vienen en dos arquitecturas fundamentalmente distintas — y la elección tiene implicaciones estructurales de soberanía.
### WAF proxy inverso (alojado en la nube)
El tráfico se enruta primero a la red de edge del proveedor. El proveedor inspecciona, filtra y (si es legítimo) reenvía al origen. Ejemplos:
- **Cloudflare WAF** (EE. UU., Delaware, NYSE: NET)
- **AWS WAF** (EE. UU., Delaware, Nasdaq: AMZN)
- **Akamai Kona** (EE. UU., Nasdaq: AKAM)
- **Fastly Next-Gen WAF** (EE. UU., NYSE: FSLY)
- **Bunny.net Shield** (Eslovenia, controlado por la UE)
El modelo de proxy inverso da al proveedor un enorme poder (absorción de DDoS a escala de Tbps, CDN global, edge compute) pero enruta el tráfico del cliente a través de la infraestructura del proveedor — lo que se convierte en una exposición jurisdiccional si el proveedor tiene matriz estadounidense.
### WAF basada en agente (autoalojada o en el origen)
Un agente se ejecuta en el servidor de origen (o delante de él como componente inline), inspeccionando el tráfico sin enrutarlo a través de un servicio externo. Ejemplos:
- **CrowdSec AppSec Component** (Francia, licencia MIT)
- **ModSecurity** (código abierto, históricamente la referencia)
- **Coraza** (sucesor de ModSecurity basado en Go)
- **HAProxy Enterprise WAF**
- **NGINX App Protect**
- **AWS-shield agent-modes**
Las WAF basadas en agente mantienen el tráfico del cliente en su propia infraestructura. El proveedor ve actualizaciones de reglas y agregados de telemetría, no el flujo bruto de peticiones.
## Implicaciones de soberanía
Bajo el modelo de proxy inverso, el tráfico del cliente — incluidos los cuerpos de las peticiones con datos personales, información de pago, credenciales de autenticación y tokens de API — fluye a través de la infraestructura del proveedor de WAF. Para un proveedor con matriz estadounidense, ese flujo queda expuesto al alcance de la CLOUD Act y de la Sección 702 de FISA:
- Cloudflare, AWS WAF, Fastly, Akamai — la matriz está constituida en EE. UU.
- Bajo la CLOUD Act, las autoridades estadounidenses pueden obligar al proveedor a divulgar datos que procesa, incluidas las peticiones en tránsito de clientes UE.
Para las organizaciones europeas que operan en sectores regulados — banca, sanidad, administración pública, defensa — enrutar el tráfico de clientes a través de una WAF de una corporación de Delaware es a menudo una exposición de cumplimiento que exige una alternativa de proxy inverso con matriz UE (Bunny.net Shield) o una arquitectura basada en agente (CrowdSec + un CDN europeo).
## El patrón CrowdSec + Bunny.net
Un patrón habitual de sustitución europeo-soberana para la oferta combinada de WAF + CDN + DDoS de Cloudflare:
1. **CrowdSec** (SAS con sede en París, código abierto MIT, basado en agente) gestiona WAF + gestión de bots + reputación IP — ejecutándose en sus servidores, sin intermediario estadounidense.
2. **Bunny.net** (Eslovenia) gestiona el cacheo en edge del CDN y el origin shielding bajo jurisdicción UE.
3. Opcional: **OVHcloud Anti-DDoS** o **Bunny Shield** gestiona el scrubbing DDoS volumétrico de capa de red.
El stack combinado sustituye la superficie funcional útil de Cloudflare manteniendo el tráfico bajo custodia de jurisdicción UE en cada salto.
## Implicaciones de NIS2 y DORA
- **NIS2**: las entidades esenciales e importantes deben documentar los controles de seguridad, incluida la arquitectura de la WAF. Para entidades próximas al sector público, la jurisdicción del proveedor de WAF es cada vez más una consideración documentada.
- **DORA**: las pruebas de resiliencia operativa para servicios financieros requieren pruebas de penetración dirigidas por amenazas que cubran la superficie de ataque externa — incluida la capa WAF. Las pruebas deben incluir escenarios adversarios realistas; si el propio proveedor de WAF se encuentra en una jurisdicción donde puede imponerse el alcance regulatorio, esto es un factor de riesgo operativo.
## WAF gratuitas / de código abierto
Para equipos que quieren capacidad WAF de código abierto genuina:
- **ModSecurity** — la referencia histórica, pasó del mantenimiento por Trustwave al mantenimiento por OWASP en 2024. Sólido pero v3 ha anunciado su fin de vida.
- **Coraza** — el sucesor moderno basado en Go recomendado por OWASP para nuevas implementaciones.
- **CrowdSec AppSec Component** — con licencia MIT, se integra con la blocklist crowdsourced y el Security Engine de CrowdSec.
Para la mayoría de equipos europeos que construyen infraestructura soberana, la combinación de Coraza (o CrowdSec AppSec) en el borde de la aplicación + CrowdSec Security Engine vigilando los registros + Bunny.net para CDN ofrece un stack de WAF totalmente de código abierto y de jurisdicción UE a bajo coste.
¿Te resultó útil?
¡Gracias por tu opinión!