≡En resumen
- Elegir un WAF es elegir quién mantiene las reglas: el proveedor (gestionado) o tu equipo (autoalojado).
- El mayor coste real de un WAF no es la licencia, sino los falsos positivos y las horas de ajuste.
- En OWASP CRS, subir el nivel de paranoia detecta más ataques y dispara más falsos positivos.
- El método recomendado es empezar con umbrales de anomalía altos e ir bajándolos a medida que limpias falsos positivos.
- Un parche virtual bloquea la explotación de una vulnerabilidad conocida mientras corriges el código, no en lugar de corregirlo.
01 ¿Qué es un Web Application Firewall?
Si buscas la explicación completa del concepto, cómo funciona y qué ataques del OWASP Top 10 frena, la tienes en la ficha en español sobre qué es un firewall de aplicaciones web. Esta página responde a lo que viene después: cómo elegir uno y cómo ajustarlo para que no rompa tu web.
02 WAF gestionado o autoalojado: cómo elegir
La primera decisión no es la marca, sino quién escribe y mantiene las reglas. En un WAF gestionado (en la nube o como servicio del CDN) el proveedor publica y actualiza las firmas; tú activas conjuntos de reglas y añades excepciones. En uno autoalojado instalas el motor en tu servidor o en un contenedor y tu equipo decide cada regla.
| Criterio | Gestionado (nube / CDN) | Autoalojado (motor + reglas) |
|---|---|---|
| Puesta en marcha | Cambiar DNS o activar el servicio: horas | Instalar, integrar y probar: días |
| Actualización de reglas | El proveedor, a menudo el mismo día de una vulnerabilidad sonada | Tu equipo, al ritmo al que actualice el conjunto de reglas |
| Control y transparencia | Parte de las reglas son opacas | Control total, reglas legibles |
| Datos | El tráfico, descifrado, pasa por un tercero | El tráfico no sale de tu infraestructura |
| Protección DDoS y bots | Suele venir integrada | Hay que añadirla aparte |
| Coste | Suscripción o pago por petición | Sin licencia, pero con horas de ingeniería |
| Encaja con | Webs corporativas, tiendas, SaaS con poco equipo de sistemas | Entornos regulados, datos que no pueden salir, equipos con experiencia |
03 Criterios para comparar proveedores de WAF
- ✓Conjuntos de reglas disponibles en tu plan: genéricas, OWASP, específicas de CMS o de API.
- ✓Posibilidad de modo solo registro por regla, no solo global.
- ✓Excepciones finas: por ruta, parámetro, cabecera o IP, sin desactivar la regla entera.
- ✓Acceso a los registros completos con el identificador de la regla que bloqueó cada petición.
- ✓Límites de peticiones configurables y gestión de bots con desafíos.
- ✓Protección de API: validación de esquemas, límites por token o clave.
- ✓Dónde se procesan y guardan los registros, algo relevante si contienen datos personales.
- ✓Cómo se factura: por dominio, por regla, por millón de peticiones o por ancho de banda.
04 Falsos positivos: el coste oculto de un WAF
Un falso positivo es una petición legítima que el WAF bloquea porque se parece a un ataque. Pasa con más frecuencia de lo que parece: un cliente que escribe en un comentario SELECT o un apóstrofo, un editor de contenidos que guarda HTML, una integración que envía JSON con caracteres especiales o un buscador interno con consultas largas.
Dónde aparecen
Formularios con texto libre, editores del CMS, subida de archivos, webhooks de pasarelas de pago y APIs que reciben JSON.
Cómo se detectan
Revisando los registros de bloqueo por regla y ruta, y cruzándolos con quejas de usuarios o caídas en conversiones.
Cómo se corrigen
Con una excepción acotada: esa regla, en esa ruta, para ese parámetro. Nunca desactivando la regla en toda la web.
Cómo se previenen
Probando en modo registro cada cambio de la aplicación antes de publicarlo, igual que se prueban las funcionalidades.
05 Ajustar un WAF paso a paso: paranoia levels y anomaly scoring
El OWASP Core Rule Set, el conjunto de reglas open source más usado con ModSecurity y Coraza, ofrece dos palancas de ajuste. El nivel de paranoia decide cuántas reglas se ejecutan y el umbral de anomalía cuántos puntos debe acumular una petición para bloquearse.
| Nivel | Protección | Falsos positivos | Uso orientativo |
|---|---|---|---|
| PL1 (por defecto) | Base | Casi ninguno | Cualquier web; sin datos personales sensibles |
| PL2 | Ampliada | Algunos nuevos | Webs que manejan datos de usuarios, como un e-commerce |
| PL3 | Alta | Numerosos, asumibles con ajuste | Operaciones sensibles, datos financieros |
| PL4 | Máxima | Muchos | Activos críticos con equipo dedicado a mantenerlo |
5
Umbral de anomalía de entrada por defecto (una regla crítica basta para bloquear)
Fuente: Documentación de OWASP CRS
5 / 4 / 3 / 2
Puntos por regla crítica, error, aviso y nota
Fuente: Documentación de OWASP CRS
-
1
Arranca en bloqueo con umbrales muy altos
CRS recomienda empezar en modo bloqueo con un umbral de anomalía muy alto, de forma que casi nada se bloquee pero todo se puntúe.
-
2
Recoge y agrupa los disparos
Durante días, lista qué reglas saltan en qué rutas con tráfico legítimo.
-
3
Crea exclusiones acotadas
Para cada falso positivo, excluye la regla solo en la ruta o el parámetro afectado.
-
4
Baja el umbral por tramos
Reduce el umbral poco a poco y repite el ciclo hasta llegar al valor por defecto o al que marque tu riesgo.
-
5
Sube de nivel de paranoia si lo necesitas
Usa el executing paranoia level para ejecutar reglas del nivel superior sin que cuenten para el bloqueo y evalúa su ruido antes de activarlas.
06 Virtual patching: el WAF como parche temporal
OWASP define el virtual patching como una capa de aplicación de políticas de seguridad que impide y registra los intentos de explotar una vulnerabilidad conocida. En la práctica: se publica un fallo en un plugin o librería que usas, todavía no puedes actualizar, y creas una regla en el WAF que bloquea exactamente el patrón de ese ataque.
-
1
Preparación
Ten registros HTTP completos y un proceso aprobado para publicar reglas urgentes.
-
2
Identificación y análisis
Confirma qué versión y qué ruta están afectadas y cómo se dispara el fallo.
-
3
Creación del parche
Escribe la regla más estrecha posible: sin falsos positivos ni falsos negativos.
-
4
Prueba en modo registro
Verifica que bloquea el ataque de prueba y no el tráfico legítimo.
-
5
Seguimiento
Documenta el parche y retíralo cuando el código esté corregido y actualizado.
07 Cuándo merece la pena un WAF y quién debe gestionarlo
| Proyecto | Opción razonable | Quién lo ajusta |
|---|---|---|
| Web corporativa en un CMS | WAF gestionado del CDN con reglas básicas | El proveedor de mantenimiento |
| Tienda online | WAF gestionado con reglas del CMS y límites en login y checkout | Agencia o equipo técnico, revisando tras cada cambio |
| SaaS o aplicación con API | Gestionado en el borde más reglas propias por endpoint | El equipo de desarrollo, en el mismo ciclo que el código |
| Entorno regulado o datos que no pueden salir | Autoalojado con CRS o appliance | Equipo de seguridad dedicado |
Si cobras con tarjeta en tu propio entorno, recuerda que PCI DSS v4.0 exige protección automatizada de las aplicaciones web públicas; lo tienes en cuenta desde el principio si trabajas el diseño web de tienda online con nosotros. En aplicaciones a medida, lo ideal es que la misma empresa de desarrollo web que escribe el código defina las reglas y excepciones del WAF.
Preguntas frecuentes sobre Web Application Firewall
Significa firewall de aplicaciones web: un filtro que inspecciona las peticiones HTTP a una web o API y bloquea las que parecen ataques.
Para la mayoría de webs y tiendas, uno gestionado en la nube, porque el proveedor mantiene las reglas. El autoalojado compensa cuando necesitas control total o el tráfico no puede pasar por terceros.
Es una petición legítima bloqueada por parecerse a un ataque, como un formulario con apóstrofos o un editor que guarda HTML. Se corrige con excepciones acotadas por ruta y parámetro.
PL1 es el punto de partida para cualquier web. La documentación de CRS sugiere PL2 si manejas datos de usuarios y PL3 para datos financieros, con más ajuste.
Es bloquear en el WAF la explotación de una vulnerabilidad conocida mientras se corrige el código. Es temporal y no sustituye a la actualización.
Va desde planes gratuitos con reglas básicas en algunos CDN hasta suscripciones por dominio o por volumen de peticiones. En el autoalojado no hay licencia, pero sí horas de ingeniería.
Sí, si lo configuras para ello: límites por clave o token, validación del formato de las peticiones y reglas específicas para cada endpoint.
Fuentes consultadas
Sobre el autor
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil y artículos → Ver perfil en LinkedIn ↗