Tres aspectos clave que todo CISO debe conocer sobre la seguridad de las API

En el tercer episodio de F5 Global CISO: Para defensores, por defensores, me acompañó Corey Ball, uno de mis hackers de API favoritos. Corey lleva 15 años activo en TI y ciberseguridad, y literalmente escribió el manual sobre hacking de APIs al descubrir que apenas existía conocimiento consolidado sobre el tema; fue entonces cuando nos conocimos.

El libro es Hacking APIs: Rompiendo interfaces de programación de aplicaciones web, que ofrece un curso intensivo sobre pruebas de seguridad de API web. Corey también fundó APIsec University, un recurso gratuito para aprender sobre seguridad de API, y es fundador y CEO de hAPI Labs, que realiza pruebas de seguridad en API y aplicaciones web.

Corey es un experto en seguridad de API, así que le pregunté la cuestión del día: ¿Cuáles son las tres cosas que todo CISO debe conocer sobre la seguridad de API? Quería saber, en especial, qué cree que los defensores pueden aprender al analizar la seguridad de API desde el punto de vista del atacante.

Las APIs son la tecnología que permite la transferencia de datos, uno de los recursos más valiosos del mundo. “Aunque implementamos defensas como firewalls y firewalls de aplicaciones web para proteger esos datos,” dijo Corey, “las APIs que están expuestas a internet pueden ser fácilmente una puerta de acceso para ataques.” Si una API no está protegida, no requiere autenticación ni aplica autorización, abre directamente una vía para un atacante, que puede acceder, realizar solicitudes no autorizadas y robar datos que hemos protegido con todas las demás barreras.

“Quiero asegurarme de que quienes defienden entiendan la importancia de usar las herramientas y métodos adecuados para evaluar la seguridad de sus API”, dijo. No basta con lanzar un escáner automatizado sobre una API, obtener un informe limpio y pensar que todo está protegido. Debes probar y analizar activamente las solicitudes de API para detectar problemas reales y resolver cualquier vulnerabilidad existente.

Poniendo a prueba a tus evaluadores. Una forma práctica de validar tus habilidades y herramientas de prueba, según Corey, es practicar con aplicaciones deliberadamente vulnerables, objetivos seguros y específicos que te permiten experimentar, reproducir y comprender los problemas comunes de seguridad en las API. “Por ejemplo, el Proyecto de Seguridad de API de OWASP ofrece crAPI, una herramienta de formación llena intencionadamente de vulnerabilidades en API, creada para enseñar, aprender y practicar la seguridad en APIs. Puedes dirigir tu escáner directamente a crAPI y comprobar los resultados que obtienes.” Si solo detectas vulnerabilidades superficiales, como falta de encabezados HSTS o protecciones clickjack mal configuradas, tu herramienta de prueba podría estar descartando vulnerabilidades en APIs más graves, como las que señala el OWASP API Top 10.  “Esto demostraría que tus herramientas de prueba quizás no sean tan efectivas como crees”, comentó Corey.

Corey y yo también hablamos sobre por qué las herramientas clásicas para gestionar vulnerabilidades en empresas no sirven para las API, ya que estas son susceptibles a tipos de ataques distintos a los que enfrentan las aplicaciones web tradicionales. Por ejemplo, la autorización fallida a nivel de objeto (BOLA) y la autorización fallida a nivel de propiedad del objeto (BOPLA) son vulnerabilidades en la seguridad de las API que están relacionadas con la lógica principal del negocio de la API. Le pregunté a Corey qué les estaría faltando para proteger las API si ya han desplegado un WAF y un API gateway.

Los WAF y las puertas de enlace API son fundamentales para la seguridad de las aplicaciones y la autenticación de usuarios, pero no bastan por sí solos para proteger las API. El mayor desafío al asegurar las API es la autorización: garantizar que los usuarios solo puedan acceder, ver, modificar o eliminar sus propios datos. “Tienes que asegurarte de que el usuario A solo pueda interactuar con los recursos del usuario A. No puede cambiar, leer, actualizar ni eliminar los recursos del usuario B”, explicó. “La autorización en las API es sin duda todo un reto. La petición de un atacante criminal para acceder a los recursos de otra persona se parecerá mucho a una solicitud válida, a menos que apliques reglas de autorización muy precisas.”

Los controles de autorización forman parte de un enfoque multicapa para la seguridad de las API que combina varios controles complementarios, de modo que si una capa falla, las demás sigan protegiendo.

A medida que inviertes más en IA generativa y aplicaciones impulsadas por IA, debes entender que estas tecnologías amplían la superficie de ataque de las API. Esto sucede porque las aplicaciones de IA generativa se basan completamente en API. Dicho de otro modo, el mundo de la IA es un mundo de API; la estructura básica de las aplicaciones de IA generativa depende en gran medida de las API, y casi cada componente del sistema de IA queda expuesto a través de estas interfaces.

Pero, como comentamos Corey y yo, las APIs son solo una parte del reto que supone proteger las aplicaciones y arquitecturas de IA: Los motores de IA y los modelos de lenguaje grandes (LLM) también presentan otras vulnerabilidades susceptibles de ataques. Por ejemplo, el Protocolo de Contexto del Modelo (MCP) es un estándar de código abierto que proporciona un marco unificado para conectar los LLM con herramientas y servicios externos. Aunque los MCP aportan muchas ventajas para integrar IA en las aplicaciones, también implican importantes desafíos en materia de seguridad. “Si miras lo que hay detrás de la IA generativa,” explicó Corey, “ya se basa en muchas APIs, y luego añades los MCP, que suelen ser vulnerables por controles débiles de autenticación y autorización, aunque las medidas de seguridad ya están avanzando.”

Otra consideración de seguridad en los MCP son los ataques de inyección de instrucciones y la manipulación mediante lenguaje natural. “Esto puede suponer un riesgo para el negocio cuando tus agentes de IA y chatbots representan a tu empresa. Los atacantes pueden manipular a tus agentes de IA para que digan algo inapropiado que perjudique la imagen de tu negocio o convencer a los chatbots para ofrecer descuentos sin autorización.” También debes tener claro que los chatbots pueden ser considerados representantes legales de la empresa y responder ante la ley por sus declaraciones y acciones. Tienes que actuar con precaución: no quieres dejar escapar las oportunidades que brindan las aplicaciones de IA, pero también debes asegurarte de que estén entrenadas con datos precisos y protegidas contra este tipo de inyecciones.

Siempre es un placer conversar con Corey, y quiero agradecerle que me acompañara para hablar sobre lo que podemos aprender los defensores al ver la seguridad desde el punto de vista del atacante. Como defensores, nuestra estrategia debe basarse en la ofensiva, por eso necesitamos entender cómo actúa el atacante y qué busca para poder distribuir sabiamente nuestros recursos limitados en una defensa en capas que funcione para tu empresa, ministerio o agencia.