Qué es un WAF (Web Application Firewall): cómo funciona, qué bloquea y errores comunes

Un WAF (Web Application Firewall) es un filtro que se interpone entre el usuario y una aplicación web (o una API) para inspeccionar el tráfico HTTP/HTTPS y bloquear peticiones que parezcan maliciosas antes de que lleguen al servidor. Donde un firewall de red mira IPs, puertos y protocolos, el WAF mira el contenido de la petición HTTP: parámetros, cabeceras, cookies, body JSON, payloads de uploads y patrones de ataque conocidos. Es el control que separa una inyección SQL exitosa de un 403 silencioso, y la primera línea defensiva exigida explícitamente por PCI DSS y recomendada en NIS2.

Esta guía explica qué es un WAF, cómo funciona internamente, qué tipo de ataques bloquea de verdad, los modelos de detección habituales, los tipos según despliegue, los errores que vemos repetirse en auditoría y cómo encaja con compliance.

Qué es un WAF

Un WAF es un proxy inverso especializado en seguridad de aplicación que inspecciona cada petición HTTP/HTTPS antes de reenviarla al backend. Se sitúa lógicamente delante de la aplicación y aplica reglas para decidir si la petición continúa, se bloquea, se ralentiza o se marca para análisis.

Lo que aporta operativamente:

• Bloqueo de ataques de capa 7 (OWASP Top 10) sin tocar el código de la aplicación.
• Mitigación de día cero mientras el equipo de desarrollo prepara un parche.
• Visibilidad del tráfico ofensivo real contra la aplicación: una buena consola de WAF es la mejor fuente para entender qué intenta romper la web cada día.
• Rate limiting y bot management sobre endpoints sensibles (login, checkout, formularios).
• Cumplimiento de requisitos explícitos de marcos como PCI DSS, NIS2 o ENS.

Lo que no es un WAF: una sustitución del desarrollo seguro. Si el pentesting de aplicaciones web detecta una IDOR o una autenticación rota, el WAF rara vez la para. Las reglas genéricas atrapan inyecciones y XSS, no errores de lógica de negocio.

Cómo funciona un WAF por dentro

Un WAF moderno combina tres motores de decisión que rara vez actúan solos.

Modelo negativo (blacklist por reglas)

Es el enfoque clásico. El WAF carga un set de firmas (regex, patrones, listas de payloads conocidos) y bloquea cualquier petición que coincida. ModSecurity con OWASP Core Rule Set (CRS) es el referente histórico: miles de reglas cubriendo SQLi, XSS, RFI, LFI, command injection y más. Los WAF cloud (Cloudflare, AWS WAF, Akamai) parten también de este modelo y añaden firmas propietarias actualizadas a diario.

Punto fuerte: cubre el 80% del ruido ofensivo automatizado con poca configuración. Punto débil: genera falsos positivos cuando la aplicación maneja inputs legítimos que disparan firmas (p.ej. campos de texto con palabras como "select", "drop", "union").

Modelo positivo (whitelist por contrato)

El WAF aprende o se configura con la forma legítima de cada endpoint (parámetros esperados, tipos, longitudes, valores permitidos) y bloquea cualquier petición fuera de ese contrato. En APIs es muy efectivo si tienes el OpenAPI/Swagger del backend: el WAF rechaza directamente cuerpos JSON con campos no contemplados.

Punto fuerte: precisión altísima cuando se mantiene el contrato actualizado. Punto débil: requiere mantenimiento continuo. Cualquier release nueva del backend que añada un parámetro rompe el modelo si no se actualiza.

Heurística y ML

Los WAF actuales (Cloudflare WAF, F5 Distributed Cloud, Imperva, AWS WAF Bot Control) suman capas de scoring por anomalía, reputación de IP, fingerprinting de cliente y modelos entrenados con tráfico de millones de sitios. La decisión final no es "regex coincide", es un score acumulado que el operador modula con umbrales por endpoint.

Punto fuerte: detecta variantes que las firmas no ven (payloads ofuscados, evasiones nuevas, bots cambiando user-agent). Punto débil: caja negra desde el lado del cliente. El proveedor decide qué se considera anómalo y la trazabilidad del bloqueo es menor.

Qué bloquea realmente un WAF

Las reglas que aportan valor real en producción son siempre las mismas familias de ataque:

• SQL Injection (A03:2021 OWASP). Patrones de UNION, comentarios, time-based, error-based.
• Cross-Site Scripting (A03:2021). Inyección de <script>, eventos JS en atributos, payloads ofuscados con HTML entities o JS encoding.
• Command injection y path traversal. Caracteres ;, |, &&, ../, intentos de leer /etc/passwd o web.config.
• Local/Remote File Inclusion. URLs apuntando a recursos locales o externos cuando la aplicación procesa rutas dinámicas.
• Server-Side Request Forgery (A10:2021). Peticiones intentando alcanzar metadata cloud (169.254.169.254) o servicios internos.
• Deserialización insegura. Payloads conocidos de gadgets Java, .NET o PHP.
• Cabeceras y métodos HTTP anómalos. Host manipulado, Transfer-Encoding ambiguo (HTTP request smuggling), métodos exóticos.
• Bots y credential stuffing. Patrones de tráfico automatizado, listas de credenciales filtradas, agentes maliciosos conocidos.
• DDoS de capa 7. Saturación de endpoints con peticiones legítimas en formato. Aquí el WAF actúa con rate limiting más que con firmas.

Para vulnerabilidades de la propia aplicación que el WAF no neutraliza (lógica de negocio, IDOR, control de acceso roto), revisar la guía de OWASP Top 10 2025 ayuda a entender qué queda fuera de su alcance.

Tipos de WAF según despliegue

Cinco modelos habituales según dónde corre el WAF. Cada uno encaja mejor en escenarios distintos.

Cloud / SaaS

Cloudflare, AWS WAF, Akamai, Fastly, Azure Front Door.

• Dónde corre: en la red del proveedor, delante del DNS.
• Pros: despliegue rápido, escalado automático, telemetría compartida entre tenants.
• Contras: el tráfico TLS atraviesa el proveedor, dependencia externa.

Appliance / virtual

F5 BIG-IP ASM, Imperva SecureSphere, Fortinet FortiWeb.

• Dónde corre: hardware o VM en el perímetro o el datacenter.
• Pros: control total, sin tránsito por terceros, latencia mínima.
• Contras: coste alto, escalado manual, mantenimiento del equipo.

Host-based / embebido

ModSecurity en Nginx o Apache, NAXSI.

• Dónde corre: como módulo del propio servidor web.
• Pros: coste cero o bajo, totalmente bajo control del equipo.
• Contras: carga sobre el servidor, sin protección si el host cae.

WAAP (Web App and API Protection)

Categoría que combina WAF, bot management, API security y DDoS en una sola consola cloud.

• Dónde corre: cloud del proveedor.
• Pros: integra protección de API y bot en un único producto.
• Contras: categoría joven, oferta dispar entre fabricantes.

RASP (Runtime Application Self-Protection)

• Dónde corre: como instrumentación dentro del runtime de la aplicación.
• Pros: contexto completo del flujo, baja tasa de falsos positivos.
• Contras: requiere cambios en el stack, no cubre bots ni DDoS.

La elección depende menos de la marca y más del modelo de operación. Una pyme con web pública en cloud público suele estar bien servida con Cloudflare WAF en su plan Pro/Business. Una entidad financiera con compliance estricto suele combinar WAF appliance en perímetro con WAAP cloud para mitigación volumétrica.

WAF, firewall, IPS y RASP

Cuatro nombres que se confunden con frecuencia y que cubren capas distintas.

• Firewall de red. Capas 3-4. Decide por IP, puerto y protocolo. No entiende HTTP. Imprescindible pero ciego al payload.
• IPS (Intrusion Prevention System). Capa 4 alta y 7 superficial. Inspecciona patrones genéricos de red, incluyendo algunos HTTP, pero no comprende el contexto de la aplicación.
• WAF. Capa 7 profundo, especializado en HTTP/HTTPS. Entiende parámetros, cookies, JSON, multipart. Es el control adecuado para ataques sobre aplicaciones y APIs.
• RASP. Dentro de la aplicación. Ve el flujo de ejecución real (qué query SQL se construyó, qué fichero se intenta abrir). Da menos falsos positivos pero exige instrumentar el runtime.

Un mismo ataque (SQL injection) lo puede tocar el IPS, lo mira el WAF y, si llega, lo neutraliza el RASP en el último momento. Los marcos defensivos modernos los combinan, no eligen uno solo.

Errores frecuentes en despliegues de WAF

Lo que aparece en auditoría una y otra vez:

1. WAF en modo "log only" durante meses. Es válido como fase de tuning, peligroso si se queda así de forma permanente. Si nunca pasa a "block", no protege nada.
2. Reglas globales sin tunear para la aplicación. Las firmas genéricas de OWASP CRS bloquean campos legítimos de muchas aplicaciones (formularios largos, contenido generado por usuario, payloads JSON con strings que parecen SQL). El equipo desactiva el modo block en lugar de ajustar la regla, y queda servido como decoración.
3. TLS termina antes del WAF. Si el WAF está detrás de un balanceador que ya descifra y vuelve a cifrar, conviene revisar la cadena. Lo deseable es que el WAF vea tráfico en claro.
4. APIs sin protección específica. Muchas implementaciones cubren el front web y dejan las APIs detrás de paths como /api/v1/* con reglas genéricas. Para APIs lo correcto es WAAP con esquema OpenAPI cargado, o como mínimo reglas específicas por endpoint. Más detalle en la guía de pentesting de APIs REST y GraphQL.
5. No se monitorizan los bloqueos. El log del WAF es la mejor fuente de inteligencia ofensiva sobre la aplicación, y muchas veces nadie lo mira. Hay que enviar los eventos al SIEM y crear alertas para patrones nuevos.
6. Bypass por subdominio o IP de origen. El atacante descubre la IP real del servidor (Shodan, certificados antiguos, registros DNS históricos) y conecta directamente saltándose el WAF cloud. La mitigación es restringir el origen para que sólo acepte tráfico del proveedor del WAF.
7. No hay proceso de gestión de reglas custom. Las reglas se crean ad-hoc por incidente y nadie las revisa. Al cabo de meses, hay reglas obsoletas que abren huecos o duplican lógica. Conviene documentar y revisar trimestralmente.
8. WAF como única capa. El WAF mitiga, no sustituye desarrollo seguro, autenticación robusta, gestión de vulnerabilidades CVE ni bastionado del servidor.

WAF y compliance

Marcos donde el WAF aparece de forma explícita o muy fuerte:

• PCI DSS v4.0 (req. 6.4.2). Para entidades que procesan datos de tarjeta, exige bien una solución técnica automatizada que detecte y prevenga ataques web (en la práctica un WAF), bien revisiones manuales de aplicación con cadencia definida. Es el marco que históricamente convirtió al WAF en obligatorio de facto en e-commerce.
• NIS2 (artículo 21). Pide medidas técnicas adecuadas para gestionar riesgos. WAF entra como medida estándar en aplicaciones expuestas, especialmente en sectores esenciales.
• DORA (artículo 9). En entidades financieras europeas, refuerza protección de aplicaciones y APIs críticas.
• ENS (RD 311/2022, op.exp.4). Aplicaciones del sector público con exposición a internet deben contar con controles de filtrado y monitorización a nivel de aplicación.
• ISO 27001:2022 (control 8.23). Filtrado web y de aplicación como control técnico documentado dentro del SGSI.

Para auditorías reguladas, no basta con tener WAF. Hay que documentar el modo de operación (block/log), las reglas activas, el proceso de tuning, los eventos generados y la integración con el SOC.

Preguntas frecuentes

¿Un WAF sustituye al pentesting de aplicaciones web?

No. El WAF mitiga ataques genéricos y firmas conocidas, pero no detecta errores de lógica de negocio, autorización rota o flujos custom. El pentesting evalúa la aplicación tal cual es, incluyendo lo que el WAF no toca. Ambos controles se complementan: el pentesting encuentra el problema, el WAF lo contiene mientras se arregla.

¿Qué WAF es el mejor para una pyme?

Depende del stack. Para web pública detrás de Cloudflare, el propio WAF de Cloudflare (planes Pro o Business) cubre el 90% de los casos. Si la aplicación está en AWS, AWS WAF + Shield Standard funciona bien. Para entornos on-premise con presupuesto ajustado, ModSecurity con OWASP CRS sobre Nginx sigue siendo válido si hay equipo para mantenerlo.

¿El WAF protege contra ataques DDoS?

Parcialmente. Los WAF cloud incluyen mitigación de DDoS de capa 7 (saturación de aplicación) por rate limiting y bot management. Para DDoS volumétricos de capa 3-4 (saturación de red) se necesita el servicio de protección DDoS específico del proveedor (Cloudflare DDoS, AWS Shield Advanced, Akamai Prolexic).

¿Puede un WAF generar falsos positivos en aplicaciones legítimas?

Sí, especialmente con OWASP CRS sin tunear. Los falsos positivos típicos aparecen en formularios con texto libre, búsquedas internas, editores HTML/Markdown y APIs que aceptan JSON con cadenas largas. La solución es tuning por endpoint, no desactivar el modo block. Una fase inicial de "detection only" de 2 a 4 semanas con review diaria suele ser suficiente para depurar las reglas que disparan en tu tráfico legítimo.

¿Cómo se mantiene actualizado un WAF?

Los WAF cloud se actualizan en automático con las firmas del proveedor (incluyendo nuevas reglas tras CVEs críticos como Log4Shell o Spring4Shell). Los appliance y los host-based dependen del equipo: revisar mensualmente el changelog del set de reglas (OWASP CRS publica versiones), ejecutar pruebas en staging, promocionar a producción.

¿Qué métrica indica que un WAF está bien configurado?

Tres señales: bajo ratio de falsos positivos en logs (< 1% del tráfico legítimo bloqueado), bloqueo activo de campañas automatizadas (botnets escaneando vulnerabilidades), e integración con SOC/SIEM con alertas accionables. Si el WAF bloquea mucho pero nadie lo mira, está infrautilizado.

Recursos relacionados

• Pentesting de aplicaciones web: qué encuentra una auditoría que el WAF no para.
• OWASP Top 10 2025: el catálogo de vulnerabilidades que un WAF intenta cubrir.
• Pentesting de APIs REST y GraphQL: por qué las APIs necesitan WAAP, no WAF genérico.
• Pentesting de infraestructura interna y externa: el WAF protege la web, no el resto de servicios expuestos.
• Qué es un SIEM: adónde van los eventos del WAF para detección continua.
• Qué es un JWT: por qué el WAF no detecta tokens manipulados sin reglas específicas.

WAF en Secra

En Secra revisamos despliegues de WAF como parte de auditorías de aplicaciones web y de infraestructura. El alcance habitual incluye verificación del modo de operación (block real, no sólo log), análisis de reglas activas, búsqueda de bypass por origen directo o subdominios sin protección, validación de la integración con SOC/SIEM y propuesta de tuning específico para el tráfico de la aplicación. Si quieres validar la postura de tu WAF actual o necesitas apoyo para diseñar el despliegue, escríbenos a través de contacto.