WAF y DDoS de Cloudflare: qué realmente necesita una regla personalizada

Los rulesets gestionados de Cloudflare bloquean los patrones de ataque conocidos apenas se activan: inyección SQL, cross-site scripting, todo el top ten de OWASP, cubierto de fábrica. Ese es el piso, y es un piso real. También está lejos de ser todo el trabajo.

La brecha es lo que es propio de tu aplicación: el endpoint interno de API cuya forma de payload parece rara para una regla genérica y es completamente normal para esa integración puntual, el flujo de login que necesita su propio límite de tasa porque el default gestionado se ajustó para el sitio promedio, no para el tuyo.

Las reglas gestionadas son el piso, no el techo

Situación	Ruleset gestionado	Qué cierra la brecha de verdad
Un intento genérico de inyección SQL o XSS	Lo bloquea	No se necesita nada más
Una API interna con un payload inusual pero legítimo	Puede dar falso positivo	Una regla personalizada acotada a esa ruta
Un login bajo credential stuffing	Cobertura parcial	Un límite de tasa ajustado a tu volumen real de login, no un default
Un patrón de bot específico atacando el checkout	Bot Management lo puntúa	Una regla que actúa sobre el puntaje, no solo lo registra

Las dos filas del medio son donde vive la mayor parte del trabajo real, y son exactamente las que un default se salta, porque un default no puede saber cómo es tu volumen de login o tu tráfico de API interno.

La protección DDoS está siempre activa; el riesgo real es el falso positivo

La protección DDoS de Cloudflare corre en las capas 3, 4 y 7, siempre activa, sin configuración necesaria para el piso básico. Lo que queda como riesgo no es que pase un ataque, es que una regla de límite de tasa ajustada en un mes tranquilo confunda un pico real de tráfico, un lanzamiento de producto, una campaña que de verdad funcionó, con un ataque y lo bloquee.

Dónde se implementa esto en la práctica

Acertar acá tiene menos que ver con conocer el catálogo de productos de Cloudflare y más con conocer tu propio tráfico lo suficiente para escribir las dos o tres reglas que importan, dejando el resto al piso gestionado en vez de sobre-configurar reglas que compiten entre sí.

Implementamos configuración de WAF y DDoS como parte de nuestra práctica de implementación de Cloudflare, con la misma disciplina que aplicamos a cualquier proyecto de ingeniería: una revisión de tráfico antes de cambiar una sola regla, no una plantilla aplicada a ciegas. Cómo manejamos la seguridad en nuestra propia entrega, incluido bajo un BAA firmado cuando hay datos de salud, está en nuestras prácticas de seguridad.