Tres cosas que todo CISO debería saber sobre la seguridad de las API

F5 ADSP | 30 de septiembre de 2025

En el tercer episodio de F5 Global CISO: Para defensores, por defensores, conté con la participación de Corey Ball, uno de mis hackers de API favoritos. Corey lleva 15 años trabajando en TI y ciberseguridad, y escribió literalmente el libro sobre el hackeo de API al descubrir que apenas había conocimientos recopilados sobre el tema. Fue entonces cuando nos conocimos.

El libro es Hacking APIs: Cómo vulnerar interfaces de programación de aplicaciones web, que ofrece un curso intensivo sobre pruebas de seguridad de API web. Corey también fue uno de los fundadores de APIsec University, un recurso gratuito para aprender sobre seguridad de API, y es fundador y director ejecutivo de hAPI Labs, que realiza pruebas de seguridad de API y pruebas de penetración de aplicaciones web.

Tres cosas que todo CISO debería saber sobre la seguridad de las API

Escúchalo ahora

Escucha los últimos episodios de mi pódcast:

Corey es claramente un experto en seguridad de las API, así que le hice la pregunta del día: ¿Cuáles son las tres cosas que todo CISO debería saber sobre la seguridad de las API? En concreto, quería saber qué creía que podían aprender los defensores al analizar la seguridad de las API desde la perspectiva del atacante.

Consejo 1: Pon a prueba tus herramientas de análisis de seguridad de API

Las API son la tecnología que permite transferir datos, uno de los recursos más valiosos del mundo. «Sin embargo, aunque implementamos varias capas de defensa, como cortafuegos y cortafuegos de aplicaciones web, para proteger estos datos», afirmó Corey, «las API expuestas a Internet pueden convertirse a menudo en una puerta de entrada para vulnerar la seguridad». Si una API no está protegida y no exige autenticación ni aplica controles de autorización, puede ofrecer acceso directo a un ciberdelincuente, que podría realizar solicitudes no autorizadas y robar los datos protegidos por todas esas otras capas.

«Quiero asegurarme de que los responsables de la defensa entiendan que deben utilizar las herramientas y los enfoques adecuados para comprobar la seguridad de sus API», afirmó. No basta con dirigir un escáner automatizado a una API, obtener un informe sin incidencias y dar por sentado que todo es seguro. Los responsables de la defensa deben probar y analizar activamente las solicitudes a las API para detectar problemas reales y solucionar cualquier vulnerabilidad de seguridad existente.

Pon a prueba a quienes realizan las pruebas. Según Corey, una forma práctica de validar las competencias y herramientas de pruebas consiste en practicar con aplicaciones vulnerables de forma intencionada. Se trata de objetivos seguros y diseñados específicamente para que quienes realizan las pruebas puedan experimentar, reproducir y comprender tipos habituales de problemas de seguridad de las API. «Por ejemplo, el Proyecto de Seguridad de API de OWASP ofrece crAPI, una herramienta de formación que contiene deliberadamente vulnerabilidades de API y que se ha creado para enseñar, aprender y practicar la seguridad de las API. Puedes dirigir tu escáner directamente a crAPI y ver qué resultados obtienes». Si solo se detectan vulnerabilidades superficiales, como la ausencia de cabeceras HSTS o una configuración incorrecta de las protecciones contra el secuestro de clics, es posible que tu herramienta de pruebas esté pasando por alto vulnerabilidades de API más graves, como las incluidas en el Top 10 de riesgos de seguridad de API de OWASP. «Esto demostraría que tus herramientas de pruebas quizá no sean tan eficaces como crees», afirmó Corey.

Consejo 2: Los WAF y las puertas de enlace de API no bastan para proteger las API

Corey y yo también comentamos que las herramientas clásicas de gestión de vulnerabilidades empresariales y los programas de gestión no funcionan con las API, ya que estas son vulnerables a tipos de ataques distintos de los dirigidos contra las aplicaciones web tradicionales. Por ejemplo, la autorización de objetos a nivel de objeto rota (BOLA) y la autorización de propiedades de objetos a nivel de propiedad rota (BOPLA) son fallos de seguridad de las API vinculados a su lógica de negocio principal. Le pregunté a Corey qué le falta a una empresa para proteger sus API si ya ha implementado un WAF y una puerta de enlace de API.

Los WAF y las puertas de enlace de API son fundamentales para la seguridad de las aplicaciones y la autenticación de los usuarios, afirmó, pero por sí solos no bastan para proteger las API. El mayor reto a la hora de proteger las API es la autorización, es decir, garantizar que los usuarios solo puedan acceder a sus propios datos, verlos, modificarlos o eliminarlos. «Hay que asegurarse de que el usuario A solo pueda interactuar con los recursos del usuario A. No puede modificar, leer, actualizar ni eliminar los recursos del usuario B», explicó. «La autorización en las API es, sin duda, complicada. La solicitud de un atacante para acceder a los recursos de otra persona se parecerá mucho a una solicitud válida, a menos que se hayan establecido reglas de autorización detalladas».

Los controles de autorización deben formar parte de un enfoque de seguridad de las API basado en varias capas, que combine múltiples controles complementarios para que, si una capa falla, las demás sigan ofreciendo protección.

Consejo 3: Proteger la IA generativa exige medidas de protección adicionales

A medida que las organizaciones invierten cada vez más en IA generativa y aplicaciones basadas en IA, deben comprender que estas tecnologías amplían la superficie de ataque de las API. Esto se debe a que las aplicaciones de IA generativa son API «de principio a fin». En otras palabras, un mundo de IA es un mundo de API: la estructura subyacente de las aplicaciones de IA generativa depende en gran medida de las API y casi todos los componentes del sistema de IA quedan expuestos a través de estas interfaces.

Pero, como comentamos Corey y yo, las API son solo una parte del reto que supone proteger las aplicaciones y arquitecturas de IA: los motores de IA y los grandes modelos de lenguaje (LLM) también presentan otras vulnerabilidades que pueden ser objeto de ataques. Por ejemplo, el Protocolo de Contexto de 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 ofrecen muchas ventajas para integrar la IA en las aplicaciones, también plantean importantes retos de seguridad. «Cuando analizas lo que ocurre entre bastidores en la IA generativa», afirmó Corey, «ves que ya se trata de un conjunto de API, y después introduces los MCP, que suelen ser vulnerables debido a unos controles de autenticación y autorización deficientes, aunque las medidas de seguridad se están poniendo al día».

Otro aspecto de seguridad que debe tenerse en cuenta en relación con los MCP son los ataques de inyección de instrucciones y la manipulación mediante lenguaje natural. «Estos pueden generar riesgos empresariales cuando hay agentes de IA y chatbots que representan a la empresa. Los atacantes pueden manipular los agentes de IA para que digan algo inapropiado que perjudique la imagen de la empresa, o convencer a los chatbots para que ofrezcan descuentos no autorizados». Las organizaciones también deben comprender que los chatbots pueden considerarse representantes legales de la empresa y que esta puede ser considerada legalmente responsable de sus declaraciones y acciones. Las empresas deben actuar con cautela: no quieren perder las oportunidades de negocio que ofrecen las aplicaciones de IA, pero también deben aplicar la diligencia debida para garantizar que las aplicaciones de IA y los chatbots se entrenen con datos precisos y estén protegidos frente a las inyecciones de instrucciones.

Siempre es un placer ponerme al día con Corey, y me gustaría darle las gracias por acompañarme para hablar de lo que los defensores pueden aprender al analizar la seguridad desde la perspectiva del atacante. Como defensores, nuestra defensa debe basarse en el conocimiento de las tácticas ofensivas, por lo que todos debemos comprender cómo funcionan y qué buscan estos operadores, a fin de poder destinar de forma inteligente nuestros limitados recursos a una defensa por capas que tenga sentido para su empresa, ministerio u organismo.

Tu fuente de referencia para anticiparte a las amenazas

Puedes ver mi conversación completa con Corey Ball aquí.

Suscríbete ahora para escuchar todos los episodios de The Global CISO: Para defensores, por defensores en tu plataforma de pódcast preferida y compartirlos con tu equipo, tus compañeros y tus contactos.

Y, como siempre, si hay algún tema que te gustaría que tratáramos, escríbeme o contacta conmigo en LinkedIn.

Compartir

Artículos relacionados del blog

El imperativo empresarial de la IA en un mundo de nube híbrida y multinube
F5 ADSP | 30/04/2026

El imperativo empresarial de la IA en un mundo de nube híbrida y multinube

Cómo la IA redefine los patrones de tráfico, el riesgo de las API y el cumplimiento normativo, y por qué el paquete Distributed Cloud Services Enterprise ofrece la profundidad necesaria en entornos híbridos multicloud.

STIG de F5 NGINX: un plan de seguridad para el sector público y los entornos regulados
F5 ADSP | 30/01/2026

STIG de F5 NGINX: un plan de seguridad para el sector público y los entornos regulados

Descubra cómo las STIG de F5 NGINX proporcionan un modelo de seguridad para el Departamento de Defensa de EE. UU. y los entornos regulados, ayudándole a cumplir la normativa mientras crea una infraestructura sólida de confianza cero con mayor visibilidad y resiliencia.

Cómo el marco AEGIS de Forrester valida un enfoque centrado en la inferencia
F5 ADSP | 11/08/2025

Cómo el marco AEGIS de Forrester valida un enfoque centrado en la inferencia

El auge de la IA agéntica está transformando el panorama de la seguridad empresarial. Estos agentes de IA autodirigidos funcionan de forma autónoma, toman decisiones en tiempo real y pueden interactuar entre distintos sistemas de maneras para las que las arquitecturas tradicionales de ciberseguridad no fueron diseñadas. Aunque esto abre nuevas posibilidades, también introduce riesgos sistémicos: fallos en cascada, secuestro de objetivos y superficies de ataque hasta ahora invisibles. El reciente […] de Forrester

La nueva superficie de riesgo de la IA: invisible, autónoma y ya está dentro
F5 ADSP | 10/07/2025

La nueva superficie de riesgo de la IA: invisible, autónoma y ya está dentro

James White, vicepresidente de Ingeniería de F5 A mediados de 2025, es un buen momento para hacer balance de la adopción de la IA en las empresas y del estado de la seguridad de la IA. El uso de la IA generativa ya es habitual en las empresas En general, las empresas cuentan al menos con unos conocimientos básicos sobre la IA generativa. Entienden qué es y dónde puede […]

Protegiendo el futuro: cómo CalypsoAI se alinea con el Top 10 de OWASP para los LLM
F5 ADSP | 17/04/2025

Protegiendo el futuro: cómo CalypsoAI se alinea con el Top 10 de OWASP para los LLM

Cuando OWASP publicó su Top 10 de 2025 para grandes modelos de lenguaje (LLM), proporcionó al sector un referente de seguridad muy necesario. Pero los referentes no sirven de nada si no se actúa. CalypsoAI aborda el 80 % del Top 10 de OWASP, dando prioridad a los riesgos reales más urgentes. La plataforma combina protección en tiempo real durante la ejecución y pruebas adversariales exhaustivas, ofreciendo una cobertura inigualable frente a las […]

Implementación de LLM en la empresa: mediante una API local
F5 ADSP | 08/09/2023

Implementación de LLM en la empresa: mediante una API local

Por sí solos, sin medidas de protección ni protocolos adicionales de seguridad para la IA, el despliegue de modelos de IA generativa —en particular, modelos de lenguaje de gran tamaño (LLM)— en toda la empresa supone una oportunidad de alto riesgo y grandes beneficios para cualquier organización. Sin embargo, determinar exactamente cómo debe dar su organización este gran paso hacia el ámbito de la IA generativa requiere una planificación minuciosa. Quizá […]