¿Qué es un WAF (firewall de aplicaciones web)?

Todo sitio o API expuesto a internet recibe peticiones que no vienen de usuarios: robots que prueban formularios, escáneres que buscan fallos conocidos, intentos de inyectar código en un parámetro. Un firewall común no ve nada de eso, porque el tráfico es HTTP válido, desde IPs normales, hacia el puerto 443.

El WAF existe para cubrir ese hueco. Mira el contenido de la petición y decide si parece un ataque. Entender lo que hace (y lo que no hace) evita dos confusiones comunes: creer que lo resuelve todo o creer que es solo un nombre elegante para un firewall.

¿Qué es un WAF?#

WAF significa Web Application Firewall. Es un filtro ubicado entre el cliente y la aplicación web que inspecciona el tráfico HTTP y HTTPS. Si la petición coincide con una regla de ataque, la bloquea, la registra o la desafía (por ejemplo, con un CAPTCHA). Si no coincide, la pasa a la aplicación.

Protege contra ataques que explotan la propia aplicación, como SQL injection, XSS (cross-site scripting) e inclusión local de archivos. Esos ejemplos aparecen en la descripción del OWASP Core Rule Set (CRS), el conjunto de reglas genéricas más conocido para WAFs compatibles con ModSecurity.

¿Cómo funciona un WAF por dentro?#

El flujo básico tiene tres pasos:

1. La petición llega al WAF, que la decodifica (URL, cabeceras, cookies, parámetros, cuerpo JSON o de formulario).
2. El WAF compara cada parte con las reglas. Una regla puede ser una expresión regular, una lista de patrones o una verificación de formato.
3. Según el resultado, la deja pasar, la bloquea (normalmente con una respuesta 403) o solo la registra.

Muchos WAFs usan puntuación de anomalía. En lugar de bloquear con la primera regla que coincide, cada regla suma puntos, y la petición se bloquea cuando la suma supera un umbral. La documentación del CRS recomienda apuntar a un umbral de 5. Eso reduce los bloqueos causados por una sola señal débil.

Hay dos modelos de reglas:

• Lista de bloqueo (modelo negativo): bloquea lo que parece malo. Es fácil de activar, pero solo detecta lo que las reglas conocen.
• Lista de permitidos (modelo positivo): solo acepta lo que está descrito como válido (rutas, métodos, tipos de campo). Es más fuerte, pero cuesta mantenerlo.

¿Qué son los niveles de paranoia?#

El CRS tiene cuatro niveles de paranoia. El nivel 1 es la base para cualquier servidor HTTP, con pocas falsas alarmas. El nivel 2 se recomienda para sitios que manejan datos reales de usuarios, como una tienda. Los niveles 3 y 4 detectan más, pero exigen escribir exclusiones de reglas porque bloquean tráfico legítimo. Subir el nivel sin probar es la forma más rápida de romper un formulario que funcionaba.

Un ejemplo concreto#

Imagina una ruta de búsqueda que arma la consulta concatenando texto:

// MAL: vulnerable a SQL injection
const sql = `SELECT * FROM users WHERE name = '${req.query.name}'`;

Un atacante envía ?name=' OR '1'='1. Un WAF reconoce el patrón de inyección y devuelve 403 antes de que la petición toque el código. Pero la corrección de verdad está en la aplicación:

// BIEN: consulta parametrizada (mysql2)
const [rows] = await db.execute("SELECT * FROM users WHERE name = ?", [req.query.name]);

Con la consulta parametrizada, el valor nunca pasa a formar parte del SQL. El WAF es una segunda capa, no la primera.

Para tener una idea de cómo se escribe una regla, esta es una regla mínima de ModSecurity que bloquea la petición si algún parámetro contiene <script:

SecRule ARGS "@rx (?i)<script" \
    "id:1001,phase:2,deny,status:403,msg:'Posible XSS'"

En la práctica, rara vez escribes reglas así desde cero: usas un conjunto listo como el CRS y ajustas las excepciones.

¿Qué diferencia hay entre un WAF, un firewall de red y la protección DDoS?#

Se complementan. El WAF no está hecho para absorber un ataque volumétrico: para eso, mira qué es un ataque DDoS. Y es común que el WAF corra dentro de un proxy inverso o de una CDN, porque ese es el punto por donde ya pasa el tráfico.

¿Cuáles son los límites de un WAF?#

• Falsos positivos: una regla mal calibrada bloquea a usuarios reales, por ejemplo a quien pega un fragmento de código en un campo de texto.
• Falsos negativos: un atacante puede ofuscar el payload o usar un fallo que ninguna regla conoce.
• Fallos de lógica: un WAF no sabe que el usuario A no debería ver el pedido del usuario B. El control de acceso roto es un problema del código.
• Costo operativo: alguien tiene que leer los logs, ajustar excepciones y actualizar reglas.

Por eso el WAF entra como parte de una lista más amplia. Mira la checklist de seguridad para el deploy para saber qué hacer además de él.

¿Cuándo tiene sentido usar un WAF?#

Tiene sentido cuando la aplicación es pública y recibe entrada de usuarios: formularios, APIs con parámetros, paneles de inicio de sesión. También ayuda cuando no puedes corregir un fallo ahora mismo, porque una regla temporal (el llamado virtual patch) bloquea la explotación mientras el código no se corrige.

Importa menos en un bot que solo abre una conexión saliente con el Gateway de Discord y no recibe peticiones HTTP de fuera. Sin entrada pública, no hay nada que filtrar.

Cómo hacerlo en Square Cloud#

En Square Cloud, todos los planes incluyen un WAF y mitigación de DDoS en las capas 3, 4 y 7. La infraestructura usa contenedores aislados y una CDN Anycast con HTTP/3 y WebSockets.

Eso no reemplaza las buenas prácticas en tu código. Guarda los secretos en variables de entorno, usa consultas parametrizadas y valida la entrada. Trata el WAF como una capa extra, no como la defensa principal.

Mira la red de Square Cloud para los detalles de la CDN, el WAF y la mitigación de DDoS.