Tienes una aplicación web en un VPS. El registro de acceso muestra intentos de inicio de sesión en /wp-admin, peticiones con UNION SELECT en la cadena de consulta y tráfico constante desde rangos de IP de centros de datos que no tienen nada que hacer en tu sitio. Quieres filtrar la basura evidente antes de que llegue a tu aplicación.
Este es el momento en que la mayoría de la gente se topa con el término WAF SaaS. Para muchos lectores, «el WAF» y «Cloudflare» son lo mismo, porque Cloudflare fue lo primero con lo que se cruzaron. No son lo mismo. El WAF SaaS es una categoría: un firewall de aplicaciones web entregado desde la nube que inspecciona tu tráfico HTTP en el borde del proveedor antes de reenviarlo a tu origen. Cloudflare es un producto dentro de esa categoría.
Este artículo repasa cómo funciona el WAF SaaS, qué cobran los principales proveedores, dónde falla en la práctica y cuándo ejecutar tu propio WAF en un VPS Linux es la mejor opción.
TL;DR
- El WAF SaaS es un firewall de aplicaciones web entregado desde la nube. Enrutas el tráfico a través del proveedor o asocias el WAF a un recurso cloud compatible; el servicio evalúa las peticiones HTTP(S) antes de que la aplicación protegida las procese.
- Los grandes proveedores usan tres formas amplias de tarificación: niveles de suscripción (Cloudflare y Sucuri), facturación por uso (AWS WAF) y presupuestos a través de ventas (Imperva y Fastly). Los costes por uso suben con las peticiones procesadas y las funciones opcionales, mientras que los planes de suscripción suelen ser más predecibles.
- Existe una crítica documentada del WAF SaaS y se aborda más abajo. Apunta a la latencia, los falsos positivos, los bloqueos opacos y el enrutamiento de datos a través de terceros.
- Los WAF autoalojados en un VPS son una opción real. SafeLine y BunkerWeb son los dos proyectos de código abierto con impulso actual. Funcionan como un proxy inverso delante de tu aplicación.
- No usar WAF puede ser una decisión defendible cuando la seguridad de la aplicación es madura, la exposición está controlada, la monitorización es sólida y el riesgo restante está documentado y aceptado.
Cómo funciona el WAF SaaS
Una petición a example.com llega primero al borde del proveedor, porque tu DNS apunta allí. El nodo de borde termina el TLS, analiza la petición HTTP, la pasa por un motor de reglas y luego la reenvía a tu origen, la bloquea, la desafía (CAPTCHA, prueba de JavaScript) o limita la tasa de la fuente. Si la reenvía, tu aplicación ve la petición como si viniera de la IP del proveedor, con la IP del cliente original pasada en una cabecera como X-Forwarded-For o CF-Connecting-IP.
Muchos productos WAF SaaS usan un proxy inverso gestionado por el proveedor o una integración en el borde, pero no todos los servicios se despliegan con un cambio de DNS. Cloudflare, Sucuri y Fastly suelen situarse en la ruta de la petición, en el borde. AWS WAF se asocia a CloudFront o a recursos AWS compatibles como Application Load Balancers, APIs de API Gateway y APIs de AppSync. En todos los casos, las peticiones HTTP(S) se evalúan antes de que la aplicación protegida las procese.
Un WAF inspecciona datos de capa 7 como cabeceras de petición, rutas, cadenas de consulta, métodos, cookies y la parte configurada de los cuerpos de petición. Un firewall de red tradicional decide sobre todo en las capas 3 y 4 usando direcciones, protocolos y puertos. Nuestra guía de cortafuegos de hardware frente a software cubre la distinción más amplia.
La protección WAF gestionada suele beber de tres fuentes de reglas:
- El OWASP Core Rule Set (CRS) es una base de código abierto para ModSecurity y motores WAF compatibles. Cubre categorías de ataque habituales como inyección SQL, cross-site scripting, inyección de comandos e inclusión de archivos locales. Los productos construidos sobre ModSecurity suelen incluir CRS, mientras que muchos proveedores cloud usan sus propias reglas gestionadas.
- Los conjuntos de reglas gestionados por el proveedor son reglas propietarias que él mantiene al día. Las «Managed Rules» de Cloudflare, las «AWS Managed Rules» de AWS WAF y el feed de inteligencia de amenazas de Imperva entran aquí.
- Las reglas personalizadas son las que escribes tú. «Bloquear peticiones a /admin que no vengan de este rango de IP», «limitar /api/login a 5 por minuto y por IP».
Una regla de inyección SQL puede marcar un patrón familiar como ' OR 1=1 -- en un parámetro de consulta o en el cuerpo de la petición. Eso caza los sondeos perezosos, pero un WAF aún puede pasar por alto cargas ofuscadas, fallos de lógica y peticiones maliciosas que parecen tráfico normal de la aplicación. Evalúa señales observables de la petición, no la intención de negocio.
Contra qué protege, en términos simples:
- Ataques de inyección cuya carga coincide con una firma conocida
- Tráfico de bots procedente de escáneres conocidos
- Patrones simples de fuerza bruta
- DDoS volumétrico, cuando el proveedor también hace scrubbing de DDoS
- Abuso básico de API
Lo que no hace:
- Parchear tu aplicación
- Sustituir la validación de entradas en tu código
- Detener ataques que parecen tráfico normal
La seguridad de la aplicación sigue viniendo de la aplicación. Un WAF sube el suelo frente a ataques comunes y automatizados, pero el código seguro, los parches, la autorización, el manejo de entradas, la monitorización y la respuesta a incidentes fijan el techo.
WAF SaaS frente a appliance on-premise frente a autoalojamiento en un VPS
En 2026 hay tres modelos de despliegue de WAF habituales: WAF SaaS en la nube (Cloudflare, AWS WAF, Fastly y otros), appliances físicos o virtuales (incluidas las ofertas de F5 e Imperva), y software autoalojado en un VPS o en tu propio servidor.
Los tres difieren en cuatro preguntas prácticas: quién opera el plano de inspección, quién paga la capacidad, quién ajusta las reglas y qué pasa cuando el WAF bloquea algo que no debería. El resto del artículo usa estas cuatro como marco de comparación.
WAF SaaS en la nube
Enrutas el tráfico por el borde del proveedor o asocias el WAF a un recurso cloud compatible. El proveedor opera la capacidad de inspección y las actualizaciones gestionadas, mientras tú seleccionas reglas, creas políticas específicas de la aplicación y ajustas excepciones. Entre las opciones habituales están Cloudflare, AWS WAF, Imperva, Sucuri y Fastly.
La contrapartida: la capacidad y la operación son problema de otro. Pero cada petición HTTP también pasa por la infraestructura de otro. Tu tráfico HTTP atraviesa la infraestructura del proveedor, y los metadatos de petición o los fragmentos de carga detectados pueden registrarse según el proveedor, el producto y los ajustes de registro.
WAF en appliance on-premise
Un appliance físico o virtual se sitúa en la ruta de tu red. Los compradores suelen ser organizaciones con operaciones de seguridad de red consolidadas, requisitos de capacidad fija, controles de despliegue estrictos o relaciones existentes con proveedores. La capacidad, las actualizaciones, la alta disponibilidad y el ajuste siguen siendo responsabilidad del cliente.
Para muchos equipos pequeños y medianos, la compra del appliance, la capacidad fija y la carga operativa hacen de esta la vía menos práctica. Aun así puede encajar en organizaciones que necesitan un plano de control dentro de la red y tienen personal para operarlo.
WAF autoalojado en tu propio VPS
Instalas un WAF en un VPS Linux, apuntas tu DNS a ese VPS y el WAF queda como proxy inverso delante de tu aplicación. Tú lo operas. Tú lo ajustas. Tú te conectas a las 2 de la madrugada cuando una actualización de reglas gestionadas bloquea una petición legítima y no hay nadie más a quien llamar.
Dos proyectos de código abierto tienen impulso actual: SafeLine, un WAF open source que usa un motor de análisis semántico en lugar de simple correspondencia por expresiones regulares, y BunkerWeb, un WAF basado en NGINX que incorpora ModSecurity. Sus licencias, modelos de despliegue y consumo de recursos se ven más adelante, en la sección de autoalojamiento.
La contrapartida es la inversa del modelo SaaS. Tú controlas el plano de inspección, la capacidad, los registros y el ajuste. Eso reduce la dependencia de un proveedor WAF externo, pero las redes upstream y los alojadores siguen transportando el tráfico. Los límites de infraestructura, el ancho de banda, los parches y la respuesta a incidentes pasan a ser cosa tuya.
WAF SaaS frente a WAF autoalojado en tu VPS
La tabla comparativa siguiente se centra en las diferencias prácticas que los administradores de sistemas tienen que operar y presupuestar.
| Criterio | WAF SaaS en la nube | WAF autoalojado en un VPS |
|---|---|---|
| Quién opera el plano de inspección | El proveedor, en el borde de la red | Tú, en tu VPS |
| Quién paga la capacidad | El proveedor, y te lo refactura por suscripción o por petición | Tú, coste fijo del VPS |
| Quién ajusta las reglas | Tú configuras; el proveedor entrega las actualizaciones de reglas gestionadas | Tú, de principio a fin |
| Recurso ante falsos positivos | Ajustar reglas y excepciones dentro de los controles del proveedor; escalar los problemas de plataforma | Editar la regla tú mismo; redesplegar en minutos |
| Enrutamiento de datos | Las peticiones pasan por la infraestructura de inspección del proveedor | Las peticiones pasan por infraestructura que tú controlas antes de llegar al origen |
| Cómo se comporta el coste en un pico de tráfico | Los componentes por uso pueden subir con el volumen de peticiones | Normalmente más predecible, aunque el ancho de banda y el escalado pueden añadir coste |
| Carga operativa | Baja, limitada a la configuración y el ajuste | Tú operas el VPS y el WAF |
Precios del WAF SaaS en 2026
Los precios del WAF SaaS suelen combinar niveles de suscripción, cargos por uso o presupuestos a través de ventas. Los precios públicos no son directamente comparables porque cada proveedor empaqueta de forma distinta las reglas gestionadas, los controles de bots, el registro, el soporte y las funciones anti-DDoS.
| Proveedor | Modelo de precios | Precio de entrada | Qué incluye el nivel de entrada | Notas |
|---|---|---|---|---|
| Cloudflare | Nivel de suscripción | Gratis; Pro 20 $/mes anual o 25 $/mes mensual; Business 200 $/mes anual o 250 $/mes mensual | Free Managed Ruleset; los controles más amplios varían según el plan de pago | Verifica las reglas, los límites y las funciones de seguridad incluidas antes de comprar |
| AWS WAF | Por petición | $5 per web ACL/month plus $1 per rule or rule group/month plus $0.60 per million requests | Reglas gestionadas por ti; las AWS Managed Rules se pueden añadir como grupos de reglas gestionadas | La capacidad extra, la inspección del cuerpo, los grupos gestionados premium, CAPTCHA, Challenge, Bot Control y Fraud Control pueden sumar cargos |
| Imperva | Presupuesto empresarial | Contactar con ventas | Reglas gestionadas, inteligencia de amenazas y opciones de seguridad de API | Sin precio público de WAF de autoservicio directamente comparable |
| Sucuri Platform | Nivel de suscripción | Basic Firewall 9,99 $/mes; Basic Platform 229 $/año | Plan firewall: WAF/CDN; el paquete Platform añade escaneo y limpieza | El cortafuegos independiente y el paquete Platform anual son productos distintos |
| Fastly | A través de ventas | Contactar con ventas | Inspección en el borde o distribuida, reglas gestionadas y protección de API | Sin precio público de WAF de autoservicio directamente comparable |
AWS WAF publica el precio por componente, mientras que Cloudflare y Sucuri publican precios de planes de autoservicio. Imperva y Fastly usan precios a través de ventas para ofertas de WAF comparables.
Comprobado el 29 de julio de 2026: la página de planes de Cloudflare indica Pro a 20 $ al mes con facturación anual o 25 $ con facturación mensual, y Business a 200 $ al mes anual o 250 $ mensual. La página de precios del cortafuegos de Sucuri lists Basic Firewall at $9.99 per month and Basic Platform at $229 per year. The firewall and platform bundles are different products. The AWS WAF figures above come from los precios de AWS WAF as of the same date.
Imperva y Fastly no publican precios de WAF de autoservicio directamente comparables, así que trátalos como opciones de contactar con ventas en lugar de fiarte de estimaciones de terceros.
La página de precios de AWS WAF indica unos cargos base de 5 $ por web ACL al mes, 1 $ por regla o grupo de reglas al mes y 0,60 $ por millón de peticiones procesadas. Pueden aplicarse cargos adicionales por capacidad extra, inspección de cuerpo más amplia, acciones CAPTCHA o Challenge, grupos gestionados premium y controles de fraude o de bots. El tráfico de ataque puede por tanto subir la factura, pero el impacto depende del volumen, la duración y las funciones activadas. Las reglas basadas en tasa protegen la aplicación; no hacen gratuitas las peticiones WAF ya procesadas.
Dónde se queda corto el WAF SaaS
Los falsos positivos son la primera limitación práctica. Una subida legítima, una llamada a la API o el envío de un formulario pueden parecer un patrón de ataque y disparar una regla gestionada. El operador tiene entonces que identificar la regla que coincidió, acotarla o excluirla, y confirmar que la excepción no crea un bypass más amplio.
Los WAF deciden a partir de señales de la petición, no de la intención de negocio. Las reglas estrictas pueden bloquear tráfico legítimo; las excepciones amplias pueden debilitar la protección. Los servicios cloud suelen ofrecer registros de eventos, anulaciones de reglas y respuestas personalizadas, pero la visibilidad y los controles de ajuste disponibles varían según el plan y el proveedor.
Consejo profesional. Arranca las reglas nuevas o cambiadas de forma sustancial en modo detección o recuento. Observa tráfico representativo, prueba flujos críticos y poco frecuentes, revisa los falsos positivos y añade exclusiones muy acotadas antes de activar el bloqueo. La guía actual de ajuste de CRS recomienda de una a dos semanas, o hasta que se hayan ejercitado el tráfico pico y los flujos críticos.
La segunda limitación es la sobrecarga de rendimiento. Un benchmark de ModSecurity de 2023 midió 9.462 subidas de archivos pequeños en 7,36 segundos con CRS activado frente a 4,55 segundos sin él. El rendimiento cayó de 2.079 a 1.285 peticiones por segundo, mientras que el pico de CPU de nginx subió del 8 % al 73 %. Era una única configuración y una única carga de trabajo, así que tómalo como evidencia de que la inspección cuesta, no como una proporción universal de dimensionamiento.
La tercera limitación es el enrutamiento de datos. Cada petición HTTP, cuerpo incluido, pasa por la infraestructura del proveedor. Para aplicaciones que manejan datos personales, transacciones financieras o datos médicos, esto es una cuestión concreta de soberanía de datos. Una aplicación alojada en la UE que enruta las peticiones de sus clientes a través de un proveedor WAF estadounidense tiene un rastro de auditoría más difícil de justificar, y unas cuantas cláusulas contractuales más que firmar, que esa misma aplicación con un proxy inverso autoalojado en un VPS de la misma jurisdicción.
La cuarta limitación es la carga de ajuste. Los retos de ajustar un WAF incluyen los falsos positivos, el contexto de aplicación limitado y las reglas que deben seguir el ritmo de cambios frecuentes en el código. La fuente es la de un proveedor, pero el patrón operativo es real: los equipos o invierten en ajuste continuo o dejan más reglas en modo solo detección.
Esa misma crítica de 2023 sostiene que los WAF pueden convertirse en teatro de seguridad cuando los equipos se apoyan en ellos en vez de arreglar la aplicación. El argumento es más fuerte para equipos con seguridad de aplicación madura: acceso parametrizado a la base de datos, autorización sólida, escaneo periódico de dependencias, despliegues inmutables y monitorización eficaz. En entornos menos maduros, un WAF sí puede reducir la exposición a los sondeos automatizados habituales. Ambas cosas pueden ser ciertas.
Los WAF son una capa dentro de una defensa en profundidad. No sustituyen a la seguridad de la aplicación, y tampoco son teatro de seguridad. El valor marginal de un WAF es alto para algunos equipos y bajo para otros. Lo que decide es cómo está la aplicación por debajo.
Cuándo tiene sentido autoalojar un WAF
El autoalojamiento gana en tres situaciones. Pierde en otras tres. Empecemos por las que gana.
El autoalojamiento gana cuando restricciones de política o de soberanía de datos descartan la inspección por un intermediario WAF SaaS externo, cuando los patrones de tráfico hacen que la tarificación por uso resulte menos atractiva que operar infraestructura dedicada, y cuando un equipo quiere control directo sobre las decisiones de bloqueo y la corrección de falsos positivos.
El autoalojamiento pierde cuando no hay capacidad operativa, cuando la aplicación vive en una plataforma gestionada cuyo modelo de enrutamiento hace incómodo un proxy externo, o cuando un nivel gratuito gestionado por el proveedor ya cubre los controles necesarios con menos complejidad.
El plan gratuito de Cloudflare puede ser un punto de partida práctico para equipos pequeños y medianos que ya usan su DNS o su CDN y aceptan su modelo de inspección de tráfico. El autoalojamiento gana atractivo cuando el enrutamiento de datos, el control directo de las reglas o unos costes de infraestructura predecibles pesan más que minimizar la operación.
SafeLine y BunkerWeb
Merece la pena conocer dos WAF de código abierto autoalojables.
SafeLine se publica bajo licencia GPL-3.0, se despliega con Docker Compose y se apoya en análisis semántico en vez de en un conjunto de reglas CRS puro. El repositorio de SafeLine declara un 71,65 % de detección, un 0,07 % de falsos positivos y un 99,45 % de precisión global en modo Balance, sobre su propia evaluación de 33.669 muestras. Son mediciones de los mantenedores del proyecto, no un benchmark independiente, y no deben generalizarse más allá de ese conjunto de pruebas.
BunkerWeb se publica bajo licencia AGPL-3.0 y usa NGINX por debajo. Integra ModSecurity con el OWASP Core Rule Set y admite varios modelos de despliegue, entre ellos Linux, Docker, Swarm y Kubernetes.
Dimensiona cualquiera de los dos a partir de un volumen de peticiones medido, las protecciones activadas, el trabajo de TLS y la retención de registros. Para un despliegue de SafeLine con poco tráfico, 2 vCPU y 4 GB de RAM son un punto de partida conservador, con margen por encima del mínimo de instalación. La guía de inicio rápido actual de BunkerWeb recomienda al menos 2 vCPU y 8 GB de RAM para pruebas o muy pocos servicios, y 4 vCPU con 16 GB de RAM para entornos de producción que protejan muchos servicios. El almacenamiento depende sobre todo del ritmo de registros y de la retención: mídelo en vez de prometer un número fijo de meses.
Consejo profesional. Ejecuta el WAF autoalojado en la misma región que el origen de la aplicación siempre que puedas. Un proxy lejano añade un viaje de ida y vuelta interregional a cada petición y puede degradar la latencia sin hacer ruido. Mide el tiempo de respuesta de extremo a extremo desde las regiones de tus usuarios antes del cambio a producción.
El WAF lo operas tú, lo que significa que la infraestructura de debajo también es responsabilidad tuya: disponibilidad, parches de seguridad, certificados TLS, copias de seguridad, rotación de registros, monitorización, capacidad y recuperación. Prueba el comportamiento ante fallos con tanto cuidado como las reglas de filtrado, para que el WAF no se convierta en un punto único de fallo.
Un marco de decisión
Existen cuatro caminos: el nivel gratuito de Cloudflare, un WAF SaaS cloud de pago, un WAF autoalojado en un VPS y ningún WAF. La condición que elige cada uno es distinta.
Elige un nivel gratuito de WAF cloud cuando las reglas gestionadas y los límites disponibles se ajusten al riesgo de la aplicación, el modelo de enrutamiento de datos sea aceptable y minimizar el trabajo operativo sea la prioridad. Prueba flujos reales antes de dar por hecho que los valores por defecto bastan.
Elige un WAF SaaS de pago cuando necesites más reglas gestionadas, registro, controles personalizados, protección de bots o de API, soporte o capacidad de la que ofrece el nivel gratuito. Compara la matriz exacta de funciones y límites, no solo el nombre del plan. AWS WAF brilla cuando la aplicación ya usa recursos AWS compatibles y el equipo se maneja bien previendo cargos por componente.
Elige un WAF autoalojado cuando se cumplan las condiciones de autoalojamiento vistas antes y tu equipo pueda operar el proxy de forma fiable. SafeLine y BunkerWeb son los dos proyectos que evaluar primero.
No usar WAF puede ser una decisión defendible cuando la seguridad de la aplicación es madura, la exposición está deliberadamente controlada, la monitorización es sólida y el riesgo residual está documentado y aceptado. No debería ser la opción por defecto solo porque un framework valide las entradas.
Conclusión
Elige WAF SaaS por la capacidad gestionada por el proveedor y menos carga operativa. Elige el autoalojamiento por el control directo, cuando el equipo sepa operar el proxy de forma fiable. En cualquiera de los dos modelos: despliega las reglas por fases, mide la latencia y los falsos positivos, y mantén la seguridad de la aplicación en primer plano.
Si el autoalojamiento encaja con tus necesidades, empieza con un Linux VPS en la misma región que el origen. Cloudzy también ofrece despliegues de marketplace en un clic para SafeLine y para BunkerWeb, para que puedas empezar a probar sin montar la pila base a mano.
Construye sobre un VPS Linux con acceso root, NVMe y la potencia de AMD EPYC.
Ver planes LinuxPreguntas frecuentes
¿Qué es el WAF as a service?
El WAF as a service es un firewall de aplicaciones web entregado desde la nube. El tráfico llega al servicio mediante enrutamiento DNS o proxy inverso, integración en el borde o asociación con un recurso cloud compatible. El proveedor opera la capacidad de inspección y las actualizaciones gestionadas; tú eliges políticas, ajustas excepciones y añades reglas propias de la aplicación.
¿Es Cloudflare un WAF?
Sí. Cloudflare ofrece funciones de WAF como parte de una plataforma de borde más amplia que incluye también DNS, CDN y protección DDoS. Los planes gratuitos reciben el Cloudflare Free Managed Ruleset; los conjuntos de reglas más amplios, los controles, la analítica y las capacidades de gestión de bots dependen del plan elegido y de los complementos.
¿Basta con el WAF gratuito de Cloudflare?
Depende de la superficie de ataque de la aplicación, de las reglas necesarias, de las necesidades de registro y retención, de los controles de API o de bots, de los requisitos de soporte y de tu tolerancia a los falsos positivos. El Free Managed Ruleset puede ser una base útil, pero autenticación, pagos o datos regulados no se traducen automáticamente en un plan de pago concreto. Compara los límites de funciones actuales y valídalos frente a tu modelo de amenazas.
¿Cuál es la diferencia entre un WAF y un cortafuegos?
Un cortafuegos de red tradicional filtra el tráfico sobre todo con información de las capas 3 y 4: direcciones, protocolos y puertos. Un WAF evalúa peticiones HTTP(S) de capa 7, incluidas las cabeceras, rutas, parámetros y contenidos de cuerpo configurados. Los productos de seguridad modernos pueden difuminar esas fronteras, pero ambos controles siguen siendo complementarios y no intercambiables.
¿Qué es WAAP y en qué se diferencia de un WAF?
WAAP significa Web Application and API Protection. Es más amplio que un WAF tradicional: los proveedores suelen combinar reglas WAF con descubrimiento o aplicación de políticas de API, gestión de bots y controles de DDoS o de abuso en la capa de aplicación. El paquete exacto varía según el proveedor, así que WAAP no debería tratarse como un conjunto estandarizado de funciones.
¿Necesito un WAF si mi framework ya valida las entradas?
No siempre. Los controles del framework reducen el riesgo, pero no cubren todos los patrones de abuso automatizado. Añade un WAF solo cuando responda a un riesgo definido que justifique su coste y su ajuste.
