Esta es la historia de la empresa A y la empresa B, cuyos enfoques de seguridad de aplicaciones web y API, aparentemente diferentes, comparten un fallo sutil, pero crucial. Este fallo dio lugar a fugas de datos (y a todos los resultados negativos asociados) para ambas.
La empresa A dispone de la solución de protección de API más segura posible. Bloquean todas las infracciones de esquema, limitan las solicitudes excesivas y utilizan la información más reciente sobre amenazas para bloquear las direcciones IP maliciosas conocidas. Su método de autenticación de la API basado en contraseñas podría ser más seguro si se sustituyera por la autenticación mediante TLS mutuo, pero todavía no han sufrido fugas.
Sin embargo, su seguridad API, la información sobre amenazas y su WAF proceden de diferentes proveedores. Gracias a las actualizaciones de los proveedores, la información sobre amenazas notifica que la seguridad de su API ya no es compatible con su WAF, que protege la página de inicio de sesión de su cuenta. En consecuencia, un atacante puede utilizar una nueva vulnerabilidad de inyección SQL en esta página y obtener el nombre de usuario y la contraseña de un usuario legítimo. A continuación, el atacante envía solicitudes autenticadas y validadas por esquema a su API, y obtiene gran cantidad de datos confidenciales.
Mientras tanto, la aplicación web de la empresa B está totalmente protegida contra ataques DDoS. La empresa B también expone una API a usuarios de pago que quieren integrarse con la aplicación de la empresa.
El atacante compra la clave API de un usuario de pago legítimo en la web oscura. Con esta clave, el atacante lanza un ataque DDoS de baja intensidad y velocidad contra el servidor API de la empresa B. El atacante activa un bot que envía solicitudes a intervalos irregulares. El servidor de la API acepta como legítima cada solicitud de API que envía el bot porque incluye una clave de API aceptable. Además, por desgracia para la empresa B, su equipo de backend olvidó redireccionar su servidor de la API mediante proxy a través de su proveedor de mitigación de DDoS, aunque el resto de sus servidores están protegidos.
Conforme se acumulan las solicitudes, el servidor de la API se ve desbordado y finalmente no puede dar servicio a los demás usuarios de la empresa. Muchos de ellos cancelan sus cuentas de pago por las molestias.
¿Qué problema tenían en común las empresas A y B?
En estos ejemplos, los enfoques de seguridad de las aplicaciones web y API de ambas empresas eran combinaciones de soluciones de varios proveedores. Las soluciones no estaban integradas y además eran propensas a errores manuales.
Para entender por qué la adopción de diferentes soluciones es un problema, analiza los componentes típicos de un marco de seguridad de aplicaciones web y API:
WAF: bloquea los ataques contra aplicaciones y propiedades web
Gestión de bots: responsable de desafiar o bloquear los bots que puedan ser maliciosos
Mitigación de DDoS: mantiene las propiedades web en línea frente a ataques DDoS de cualquier tipo (ya sean volumétricos o de baja intensidad y velocidad)
Protección de API: incluye limitación de velocidad, validación de esquemas, autenticación, etc. para las API
La empresa A y la empresa B habían adoptado todas estas protecciones, pero como sus soluciones de seguridad de aplicaciones web eran dispares (aunque fueran las mejores de su clase), presentaban fallos que el atacante pudo vulnerar.
En el caso de la empresa A, tanto su WAF como su protección de API, al ser por capas y no integral, tuvieron que hacer frente y bloquear el ataque. Una de las técnicas podía detener el ataque, mientras que la otra podía arreglárselas. La protección DDoS de la empresa B no protegía su infraestructura de API, su gestión de bots no detectaba las solicitudes de API que procedían de bots, y su autenticación era poco segura y fácil de vulnerar.
Estos son solo un par de ejemplos de posibles vulnerabilidades. Otras deficiencias comunes en la seguridad de las aplicaciones web son:
Información limitada sobre amenazas, que no está actualizada, no llega al lugar adecuado o no está en un formato compatible, que fue lo que le ocurrió a la empresa A.
Demasiada información sobre amenazas procedente de demasiadas fuentes da lugar a falsos positivos, redundancia y otras ineficiencias.
Falsos positivos de bots que pueden frustrar a los usuarios, ralentizar el servicio y fomentar un cumplimiento poco estricto de la normativa.
Fatiga de alertas: un estudio realizado en 2025 por el Ponemon Institute confirma que la empresa media utiliza 45 herramientas de seguridad diferentes, lo que coincide con conclusiones anteriores, pero sigue reflejando la proliferación de herramientas y el aumento de la fatiga por alertas. De hecho, un análisis más reciente del sector sugiere que muchas organizaciones ahora utilizan entre 60 y 80 soluciones de seguridad diferentes, y algunas gestionan hasta 140, lo que aumenta aún más la complejidad y las cargas de gestión.
Autenticación insuficiente: tanto la empresa A como la B son vulnerables al robo de credenciales de alguna forma.
Protección contra amenazas no escalable: los dispositivos de seguridad de hardware obstaculizan el tráfico y se ven desbordados durante ataques grandes o con una variedad de ataques.
Estas deficiencias son cada vez más peligrosas conforme aumenta la complejidad y la sofisticación de los ciberataques. Según McKinsey, desde el lanzamiento de ChatGPT, los sitios de phishing detectados han aumentado un 138 %, impulsados por el papel de la IA generativa en la elaboración de correos electrónicos más convincentes y deepfakes, lo que acelera en gran medida las capacidades de los atacantes.
Los ciberdelincuentes modernos a menudo se mueven más rápido y mejoran sus tácticas más ágilmente que sus objetivos.
Las API son cada vez más importantes para la infraestructura de aplicaciones web de las organizaciones modernas. Actualmente, una parte importante del tráfico dinámico que procesa Cloudflare está basado en las API, y ese porcentaje sigue en aumento. De hecho, muchas organizaciones se describen a sí mismas como empresas que priorizan las API. Además, Cloudflare bloquea un porcentaje mayor de tráfico de API malicioso que de tráfico web, lo que demuestra que las API están en el punto de mira de los atacantes.
Dado que las API suelen estar plenamente integradas en las aplicaciones web, su seguridad debe ser primordial. Sin embargo, los equipos internos suelen implementar las API con rapidez, y a menudo sin consultar, sin mala intención, a los equipos de seguridad. El resultado es que muchas deficiencias en las aplicaciones web tienen su origen en un bajo nivel de seguridad de las API.
Un claro ejemplo de los crecientes riesgos asociados a las API inseguras lo encontramos en TotalEnergies. En 2025, una infraestructura de API deficiente provocó un aumento vertiginoso de 105 veces en los datos expuestos, pasando de solo 210 715 registros en 2024 a más de 22 millones compartidos en los mercados de la web oscura. Este espectacular avance subraya la urgente necesidad de que el sector energético, y todos los sectores, consideren la seguridad de las API como una infraestructura fundamental, y no como algo secundario.
¿Y si, en lugar de utilizar diferentes productos de seguridad, la empresa A y la empresa B hubieran combinado todos sus servicios de seguridad de aplicaciones web y API en una plataforma consolidada? ¿Y si esos diferentes servicios se integraran entre sí? ¿Y si los datos sobre el estado de la infraestructura de la empresa se mostraran en un único lugar, para que pudieran evaluar rápidamente los ataques y su postura de seguridad?
La empresa A se podría haber asegurado de que todos los componentes de su marco de seguridad de aplicaciones web y API dispusieran de la información sobre amenazas más reciente y detener el ataque antes de que empezara, ya que todo estaría en una sola plataforma. La empresa B podría haber ampliado más fácilmente su protección DDoS a todos sus servidores.
El uso de una plataforma habría simplificado la gestión con menos deficiencias.
Este enfoque consolidado de la seguridad de las aplicaciones web requiere una infraestructura muy escalable, capaz de redireccionar todo tipo de tráfico mediante proxy. En décadas anteriores, las organizaciones compraban aplicaciones cuando necesitaban defenderse de nuevos ataques, o cuando necesitaban expandirse. Sin embargo, un servicio basado en la nube se amplía más fácilmente y debe poder redireccionar cualquier tipo de infraestructura mediante proxy. Y, si bien, una plataforma consolidada no es garantía contra todos los ataques, sin duda habría ayudado a nuestras hipotéticas empresas.
No se trata de un simple ejercicio mental e hipotético. Las plataformas WAAP (protección de aplicaciones web y API) se están convirtiendo rápidamente en una infraestructura esencial, y no solo en una buena práctica teórica. El mercado global de WAAP en la nube se valoró en 6120 millones de dólares estadounidenses en 2023 y se prevé que crezca a una tasa compuesta anual del 17,8 % hasta 2032, según DataHorizzon Research.
Este crecimiento refleja la creciente necesidad de consolidar WAF, la mitigación de bots, la protección contra DDoS y la seguridad de las API en servicios en la nube escalables, especialmente a medida que las aplicaciones web y las API enfrentan un volumen creciente de amenazas complejas en entornos multinube.
WAAP no es solo un acrónimo más. Consolidar los servicios de WAF, gestión de bots, protección DDoS, seguridad API, entre otros, es cada vez más esencial para las organizaciones modernas. La naturaleza global de Internet abre las aplicaciones web y las API a vectores de ataque variados y cada vez más complejos. No es sorprendente que los costes de las fugas de datos sigan aumentando. En 2023, el coste medio global de las fugas ascendió a 4,45 millones de dólares, y las organizaciones estadounidenses sufrieron algunas de las cargas financieras más elevadas, con alrededor de 9,48 millones de dólares por incidente. A principios de 2024, esa cifra global ha crecido aún más hasta aproximadamente 4,88 millones de dólares, un aumento del 10 % en solo un año.
Si la empresa A y la empresa B crearan hoy sus aplicaciones y API desde cero, podrían alojarlas por completo en la nube, quizás con un proveedor de alojamiento para facilitar la implementación. Sin embargo, en realidad, la mayoría de las organizaciones han implementado una infraestructura híbrida con servidores de bases de datos locales heredados, API de terceros basadas en la nube y servicios de aplicaciones alojados en varias nubes. Estas implementaciones ofrecen muchas ventajas, pero también conllevan sus propios problemas de seguridad.
Por ejemplo, la seguridad nativa en una solución de un determinado proveedor de nube puede que no se implemente en la totalidad de su infraestructura. Para empezar, identificar y asignar toda su infraestructura para luego protegerla también puede ser un desafío. Y por último, sus productos de seguridad pueden no ser compatibles con otras soluciones de tu pila tecnológica.
Por lo tanto, además de consolidar las capacidades esenciales de seguridad de las aplicaciones web, las soluciones WAAP tienen que ser independientes en cuanto a la infraestructura, lo que significa que tiene que poder situarse frente a cualquier tipo de infraestructura o implementación en la nube.
Cloudflare es una empresa nativa de la nube e independiente en cuanto a la infraestructura. Ofrecemos soluciones de seguridad para aplicaciones web desde hace más de una década, y brindamos todas estas funciones como una plataforma consolidada en un panel único. Cloudflare también tiene la ventaja de ver un gran porcentaje del tráfico de Internet, ya que atiende más de 78 millones de solicitudes HTTP por segundo y bloquea ~190 en promedio MM de ciberamenazas al día. Esta capacidad proporciona a Cloudflare visibilidad única de las amenazas de día cero y nuevos ataques.
Este artículo forma parte de un conjunto de publicaciones sobre las últimas tendencias y temas que afectan a los responsables de la toma de decisiones sobre tecnología en la actualidad.
Gartner reconoció a Cloudflare como empresa líder en el informe 2022 Gartner® Magic Quadrant™ for Web Application and API Protection (WAAP).
Después de leer este artículo podrás entender:
Cómo las soluciones de seguridad dispares pueden crear deficiencias en materia de seguridad
Ejemplos de cómo se pueden manifestar estas deficiencias
Por qué Gartner recomienda consolidar las soluciones en una plataforma de seguridad de aplicaciones web independiente en cuanto a la infraestructura
Gartner® Magic Quadrant™ for Web Application and API Protection (WAAP)
Las herramientas de seguridad tradicionales se han quedado pequeñas para proteger a las API