Cada vez que abres una aplicación, ocurren muchas más cosas de las que se ven en la pantalla. Al consultar el pronóstico del clima, tu teléfono nunca mide la temperatura exterior; pide la lectura más reciente a un servicio meteorológico. Al iniciar sesión en un sitio nuevo con tu cuenta de Google, ese sitio nunca ve tu contraseña; pide a Google que responda por ti. Cada uno de estos intercambios viaja a través de una interfaz de programación de aplicaciones (API), y un solo clic puede desencadenar docenas de ellos en segundo plano.
Las APIs son el tejido conectivo del software moderno y se han convertido silenciosamente en una de las partes más grandes y menos comprendidas de la superficie de ataque de una organización. Antes de abordar por qué atraen a los atacantes y cómo defenderlas, conviene saber qué es realmente una API.
¿Qué es una API?
Una API es un conjunto de reglas que permite a una pieza de software solicitar datos o una acción a otra, en un formato que ambas partes acuerdan de antemano. Define qué peticiones están permitidas, cómo debe redactarse cada una, qué información transporta y qué forma debe tener la respuesta.
Imagina un intercambio único. El programa que realiza la petición es el cliente, y el que responde es el servidor. El cliente envía una petición a una dirección específica expuesta por la API, llamada endpoint, y el servidor realiza el trabajo detrás de ese endpoint y devuelve una respuesta, normalmente un bloque de datos estructurados. El cliente nunca necesita saber cómo funciona el servidor por dentro; solo necesita saber cómo preguntar y cómo leer la respuesta.
Esa separación es la razón por la que las APIs están en todas partes. Un equipo que crea un producto no tiene que escribir su propio motor de mapas, procesador de pagos o sistema de inicio de sesión; puede invocar un servicio que ya realiza esas tareas y utilizar sus resultados. Una aplicación típica se compone de muchas llamadas de este tipo, algunas a servicios de la propia organización y otras a terceros. Ese alcance también es la razón por la que protegerlas es una disciplina propia: la seguridad de una aplicación depende ahora de cada puerta que abra al exterior.
Los principales tipos de API
Las APIs vienen en varios estilos arquitectónicos y las diferencias determinan cómo se mueven los datos y hacia dónde se dirige la atención en materia de seguridad. Cuatro tipos abarcan la mayoría de los que encontrarás.
REST (transferencia de estado representacional) está detrás de la mayoría de las APIs web actuales. Utiliza métodos HTTP ordinarios para actuar sobre recursos nombrados por una URL: a grandes rasgos, GET para leer, POST para crear, PUT para actualizar y DELETE para eliminar. No tiene estado, lo que significa que cada petición lleva todo lo que el servidor necesita, y suele enviar datos en formato JSON, un formato de texto ligero. REST no tiene seguridad propia; la protección se añade mediante la forma en que se diseña e implementa la API.
SOAP (protocolo simple de acceso a objetos) es más antiguo y estricto. Envuelve los mensajes en XML y lleva extensiones de seguridad estandarizadas, conocidas como WS-Security, que pueden firmar y cifrar mensajes individuales. Sigue siendo habitual en la banca y en los pagos, donde las exigencias de cumplimiento son elevadas. Conviene ser precisos en este punto, ya que algunas descripciones dan a entender que SOAP es seguro por defecto: los estándares existen, pero deben implementarse correctamente para ofrecer protección.
GraphQL expone un único endpoint y permite al cliente solicitar exactamente los campos que desea. Esa flexibilidad reduce el desperdicio de datos, pero traslada el trabajo al servidor, que debe gestionar consultas cuyo costo no puede preverse del todo. Una consulta profundamente anidada o por lotes puede exigir mucho más de lo que sugiere su simple apariencia, por lo que las APIs GraphQL se apoyan en límites de profundidad de consulta y tiempos de espera.
Los estilos RPC (llamada a procedimiento remoto), incluido el moderno gRPC, permiten a un cliente invocar una función en un servidor remoto como si se ejecutara localmente. Se adaptan a servicios internos estrechamente vinculados en los que la velocidad y un contrato fijo importan más que la compatibilidad general.
¿Qué es la seguridad de las APIs?
Si las APIs son las puertas entre los sistemas de software, la seguridad de las APIs es la práctica de garantizar que solo las personas adecuadas pasan a través de ellas, llevan solo lo que se les permite llevar y de que nadie puede dejar una puerta abierta o colarse por otra que haya quedado abierta. Dicho con mayor precisión, la seguridad de las APIs es el conjunto de prácticas y controles que protegen a las APIs del acceso no autorizado, la exposición de datos, el abuso y la interrupción a lo largo de todo su ciclo de vida, desde el diseño hasta el retiro.
Muchas definiciones dan vueltas sobre sí mismas, describiendo el campo como "seguridad para sus API". La sustancia está en lo que se protege: la confidencialidad, la integridad y la disponibilidad de los datos y servicios que expone una API.
Una API no se protege a sí misma simplemente porque la aplicación que está detrás de ella tenga una pantalla de inicio de sesión o esté detrás de un firewall. Las APIs exponen directamente la lógica de la aplicación y los datos, a menudo a clientes que la organización no controla, y tienden a aceptar cualquier petición que llegue correctamente formateada y autenticada, incluso la diseñada para acceder a algo a lo que nunca debería tener acceso. Proteger una API significa examinar cada petición en sus propios términos: quién la realiza, si puede realizar esa acción sobre esos datos y si la petición intenta hacer algo para lo que la API nunca fue concebida.
¿En qué se diferencia la seguridad de las APIs de la seguridad de las aplicaciones?
La seguridad de las APIs forma parte de la seguridad de las aplicaciones, pero las APIs se crean y se atacan de forma lo suficientemente diferente como para que tratarlas como páginas web comunes deje vacíos. Tres diferencias destacan:
La primera es el tamaño y la forma de la superficie de ataque. Una aplicación web tradicional se crea principalmente para un tipo de visitante, una persona frente a un navegador, y gran parte de su defensa se centra en cómo se gestiona en pantalla la entrada (input) de esa persona. Una API sirve a muchos clientes a la vez: aplicaciones móviles, frontends web, sistemas de socios, servicios internos y otras API. Cada endpoint es otra vía de entrada (las API exponen muchos de ellos) y los equipos añaden y cambian endpoints constantemente, por lo que la superficie es más amplia y cambiante.
La segunda es cómo se establece la identidad. Las aplicaciones web se apoyan en sesiones y cookies, a menudo respaldadas por una solicitud de doble factor que un humano puede responder. Las APIs suelen autenticarse mediante tokens o claves que se transmiten en cada petición, como tokens OAuth o JSON Web Tokens. Un token de API suele ser el único factor que separa a un atacante de una cuenta, sin que haya un humano presente para responder a un segundo desafío, lo que hace que los tokens robados o falsificados sean especialmente valiosos y que el abuso automatizado sea más difícil de distinguir del tráfico legítimo.
La tercera diferencia es la que más importa. Los ataques web clásicos solían ser de "un solo intento": una única petición con una carga útil (payload) conocida dirigida a una debilidad conocida. Esto sigue ocurriendo, pero los ataques a API más costosos son diferentes. Dado que cada API codifica su propia lógica de negocio, los ataques más graves son abusos lentos y pacientes de esa lógica, más que exploits genéricos. Un atacante pasa días, semanas o incluso meses aprendiendo cómo se comporta una API, cómo se relacionan sus endpoints, qué secuencia de llamadas de apariencia corriente produce un resultado extraordinario, y luego automatiza el abuso. En un sentido estricto, cada uno de estos ataques es personalizado, razón por la cual las herramientas que funcionan comparando el tráfico con firmas de ataques conocidos tienden a pasarlos por alto por completo. La secuencia maliciosa está compuesta por peticiones individualmente válidas.
¿Por qué es importante la seguridad de las APIs?
Para finales de 2025, la mitad del tráfico web dinámico observado por Cloudflare estaba relacionado con APIs, y esa proporción continúa en aumento. La mayor parte es automatizado, software que habla con software, que es exactamente el tipo de tráfico que oculta bien el abuso. Cada llamada es una petición para hacer algo o entregar algo, y cada una es un objetivo potencial.
La industria lo vio venir. En un informe de 2017, Gartner predijo que para 2022 el abuso de APIs se convertiría en el vector de ataque más frecuente detrás de las brechas de datos en las aplicaciones web empresariales. Esto fue una previsión más que un hecho contrastado, pero los años transcurridos desde entonces lo han confirmado. Cuando una API se ve comprometida, los atacantes pueden acceder directamente a los datos y las funcionalidades que hay detrás de ella, robando registros, vaciando cuentas o interrumpiendo el servicio. Las consecuencias incluyen sanciones regulatorias en virtud de marcos normativos como el GDPR y la CCPA, así como la pérdida de la confianza de los clientes.
Dos brechas de seguridad recientes muestran lo comunes que suelen ser los errores subyacentes. En enero de 2023, T-Mobile reveló que un atacante había usado una sola API para extraer datos de unos 37 millones de cuentas. La extracción pasó desapercibida desde finales de noviembre de 2022 hasta principios de enero de 2023, unas seis semanas de peticiones con apariencia válida drenando registros antes de que alguien se diera cuenta.
El caso de Optus es más alarmante por lo básico que fue. En septiembre de 2022, la operadora australiana expuso datos de cerca de 10 millones de clientes. El regulador del país describió más tarde el ataque en una demanda judicial como un simple proceso de ensayo y error. Un endpoint se encontraba en un dominio de cara a Internet sin requerir autenticación, y ese único descuido abrió la puerta a todo lo demás. Los tipos de debilidad que subyacen a ambas brechas tienen un nombre en la lista estándar de riesgos de las APIs de la industria.
El OWASP API Security Top 10
La referencia habitual sobre lo que falla en las APIs es el OWASP API Security Top 10, mantenido por la organización sin ánimo de lucro Open Worldwide Application Security Project. La edición actual se publicó en 2023 y sustituyó a la lista original de 2019. Algunas entradas se renombraron, dos antiguas (exposición excesiva de datos y asignación masiva) se fusionaron en una sola categoría y se agregaron preocupaciones nuevas, como el consumo inseguro de APIs de terceros. Una idea recorre casi toda la lista: el cliente controla la petición y el servidor nunca debe asumir que la petición es honesta.
API1. Autorización rota a nivel de objeto. Este es el riesgo de API más común y perjudicial. Ocurre cuando una API comprueba que iniciaste sesión, pero no verifica que el elemento específico que solicitas realmente te pertenezca. Las APIs identifican constantemente las cosas mediante un ID en la petición, un número de pedido, un ID de usuario o una referencia de cuenta. Si el servidor no confirma que tienes permiso para tocar ese objeto en particular, puedes cambiar el ID y acceder a los datos de otra persona. Considera una API que devuelve una factura:
La solicitud está correctamente autenticada, por lo que un servidor descuidado devuelve la factura 4517. Nada impide al usuario pedir a continuación la 4518 y la 4519, y así sucesivamente, recopilando facturas que pertenecen a otros. Identificadores secuenciales como estos son los que permitieron al atacante de Optus recorrer toda una base de datos de clientes.
API2. Autenticación rota. La autenticación es la forma en que una API verifica que eres quien dices ser, y los endpoints que la gestionan (inicio de sesión, restablecimiento de contraseña, emisión de tokens) están expuestos a todo el mundo, lo que los convierte en objetivos principales. Una API es vulnerable cuando permite contraseñas débiles, facilita intentos ilimitados de adivinar contraseñas o no valida los tokens que acepta. Una debilidad frecuente y subestimada de GraphQL es que un cliente puede agrupar múltiples operaciones en una sola petición. Si una API limita los intentos de inicio de sesión a unos pocos por minuto pero no tiene en cuenta el procesamiento por lotes, un atacante puede burlar ese límite enviando docenas de intentos dentro de una sola llamada:
Para el limitador de tasa de peticiones, esto parece una única solicitud, pero en realidad contiene múltiples intentos de contraseña.
API3. Autorización rota a nivel de propiedad de objeto. Mientras que el primer riesgo se refiere al acceso a un objeto entero, este se refiere a los campos individuales dentro de él. Una API puede devolver campos que debería ocultar o aceptar campos que debería ignorar. La segunda forma, conocida desde hace tiempo como asignación masiva, es fácil de imaginar. Supongamos que una plataforma de vídeo permite a los usuarios editar la descripción de un vídeo mediante esta petición:
Un usuario cuyo vídeo fue bloqueado repite la petición y añade un campo que la interfaz nunca le ofreció:
Si el servidor mapea ciegamente los campos entrantes sobre el objeto almacenado, el usuario acaba de desbloquear su propio contenido adivinando el nombre de una propiedad. El mismo truco puede cambiar un precio, otorgar un rol o alterar cualquier indicador interno que el desarrollador supuso que solo el sistema controlaba.
API4. Consumo de recursos sin restricciones. Cada solicitud cuesta algo: ancho de banda, memoria, tiempo de procesamiento y, a veces, dinero, como cuando una llamada envía un mensaje de texto a través de un proveedor de pago. Sin límites en cuanto a la frecuencia o la intensidad con la que se puede llamar, una API puede quedar fuera de servicio o acumular una factura enorme. Un flujo de restablecimiento de contraseña que envía un SMS de pago en cada intento, disparado decenas de miles de veces por un script, cuesta dinero significativo en cuestión de minutos.
API5. Autorización rota a nivel de función. El primo del primer riesgo: en lugar de acceder a los datos de otro usuario, el atacante accede a las acciones de otro rol. Aparece cuando una API no aplica el control para que solo determinados usuarios puedan realizar operaciones específicas, especialmente administrativas. La señal reveladora es si un usuario común y corriente puede hacer algo privilegiado simplemente adivinando el endpoint correcto o cambiando el método de la petición, por ejemplo, llamando a un endpoint exclusivo para administradores que crea una cuenta con rol de administrador.
API6. Acceso sin restricciones a flujos de negocio sensibles. Algunos ataques explotan una funcionalidad que opera exactamente como fue diseñada, a una escala para la que nunca fue pensada. Un caso común es la reventa de entradas o artículos (scalping): un minorista lanza un producto escaso y de gran demanda, y un atacante programa, mediante scripts, el flujo de compra para adquirir todo el inventario en el momento del lanzamiento, para luego revenderlo a un precio superior. Ningún endpoint está roto; no se filtran datos; simplemente el flujo de compra no estaba protegido contra la automatización masiva.
API7. Falsificación de peticiones del lado del servidor. Esto ocurre cuando una API obtiene un recurso de una dirección web suministrada por el cliente sin comprobar adónde apunta. Dado que la petición procede del servidor, puede llegar a sistemas internos a los que un agente externo no tiene acceso. Por ejemplo, una función que carga una imagen de perfil desde una URL puede apuntar a una dirección interna de metadatos en la nube que devuelva las propias claves de acceso del servidor, es decir, el tipo de exposición de credenciales que abordamos en el escaneo de secretos.
API8. Configuración incorrecta de la seguridad. Una categoría amplia de ajustes y endurecimiento que se pasan por alto: parches ausentes, funciones innecesarias que se dejan activadas, falta de cifrado, reglas de origen cruzado (CORS) permisivas y mensajes de error que filtran detalles internos. Un ejemplo memorable es un tipo de ataque en el que un componente de registro vulnerable interpreta y ejecuta en el servidor un valor manipulado en un encabezado de solicitud, convirtiendo una entrada de registro ordinaria en una ejecución remota de código.
API9. Gestión inadecuada del inventario de activos. No se puede proteger lo que no se sabe que se tiene. Este riesgo consiste en perder el control de las APIs y de los datos que tocan: versiones antiguas que se dejan en funcionamiento, endpoints no documentados u olvidados, hosts de prueba y de preproducción expuestos a Internet y registros poco claros sobre qué terceros reciben tus datos. El endpoint de Optus que filtró casi 10 millones de registros vivía en un dominio olvidado que permaneció en línea después de que la corrección llegara únicamente al dominio principal. Un control de seguridad colocado frente a la API actual no sirve de nada si aún se puede acceder a una versión más antigua de la API en otro sitio.
API10. Consumo inseguro de APIs. El último riesgo cambia la perspectiva hacia las APIs que consumes, en lugar de las que expones. Los desarrolladores tienden a confiar en los datos de un servicio de terceros, especialmente uno conocido, más de lo que confían en la entrada directa de un usuario de su propio sistema. Si ese servicio se ve comprometido o simplemente se comporta de forma inesperada, los datos que devuelve pueden introducir un ataque en tu sistema. Por ejemplo, un servicio que sigue ciegamente una redirección de un tercero puede verse inducido a reenviar datos confidenciales de un usuario a una dirección controlada por el atacante.
Anatomía de un ataque a una API
Los diez riesgos raramente aparecen de a uno. Una brecha grave en una API suele encadenar varios de ellos, cada paso ordinario por sí mismo, hasta un resultado que es de todo menos común. Recorrer un ejemplo inventado pero realista muestra cómo encajan las piezas y por qué una defensa que vigila firmas de ataques conocidos tiende a no ver el panorama completo.
Imagina una tienda en línea cuya aplicación móvil se comunica con un backend mediante una API. Un atacante empieza por el reconocimiento, la primera fase de cualquier intrusión real. Al inspeccionar el tráfico de la aplicación, mapea los endpoints a los que llama y detecta un patrón de nomenclatura. Probando variaciones, encuentra un endpoint anterior, api.store.com/v1/, que sigue respondiendo a las solicitudes mucho después de que la aplicación pasó a la versión v2. Nadie lo vigila porque nadie recuerda que existe. Eso es una gestión inadecuada de inventario (API9) y constituye el punto de apoyo inicial.
El atacante sondea el endpoint olvidado y descubre que nunca le pregunta quién es. La autenticación que protege la versión actual solo se añadió delante de la v2; la copia antigua quedó abierta. La autenticación rota (API2) significa que ahora puede llamarla libremente, como cualquier usuario anónimo.
A continuación, estudia lo que devuelve el endpoint. Una petición de /v1/orders/10231 entrega el pedido de otro cliente, con nombre, dirección y los últimos dígitos de una tarjeta. El endpoint no comprueba nada sobre a quién pertenece el pedido 10231. Eso es autorización rota a nivel de objeto (API1) y los números de pedido son secuenciales, por lo que cada registro se encuentra a un dígito de distancia del anterior.
El último paso es la automatización. Al no haber limitación de tasa de peticiones — consumo ilimitado de recursos (API4) — el atacante escribe un pequeño script que recorre en orden ascendente los números de pedido y extrae un registro en cada vuelta. Cada petición es válida de forma individual, está correctamente estructurada y es indistinguible de una llamada legítima. No hay una carga útil maliciosa que detectar ni un patrón de exploit conocido que señalar. A lo largo de horas o días, el script drena silenciosamente la base de datos.
Ningún paso aquí fue sofisticado. El daño vino de cuatro pequeños descuidos que se alinearon, con la misma forma que la filtración de Optus, y por la misma razón por la que las herramientas basadas en firmas tienen dificultades: nada en la secuencia parece un ataque hasta que das un paso atrás y lo ves todo en conjunto.
Mejores prácticas de seguridad para API
Proteger las APIs no es una solución de un solo producto, sino un conjunto de prácticas aplicadas de forma continua, desde el primer boceto de diseño hasta el día en que se retira una API. Las siguientes prácticas abordan los riesgos anteriores sin tratar ninguno de ellos de forma aislada.
Conoce lo que tienes, porque no puedes defender un endpoint que has olvidado. Mantén un inventario actualizado de cada API, host y versión; descubre de forma activa las APIs en la sombra, obsoletas y de terceros; retira las versiones antiguas de manera deliberada; y mantén los datos reales de los clientes fuera de los entornos de prueba y preproducción.
Exige autenticación y autorización en cada solicitud. Confirma quién está llamando y, por separado, comprueba qué puede hacer, verificando el permiso para el objeto específico y la función específica antes de actuar. Deniega el acceso por defecto, otorga el menor privilegio necesario, valida cada token, agrega autenticación multifactor donde puedas y apóyate en estándares probados en lugar de esquemas "caseros".
Valida la entrada y limita el consumo. Trata cada solicitud como no confiable, acepta solo los campos y formatos que esperas, y rechaza el resto. Aplica límites de tasa y cuotas, restringe el tamaño y la cantidad de operaciones por solicitud, y configura alertas de gasto para cualquier servicio de terceros de pago que una llamada pueda activar.
Cifra los datos en tránsito. Envía todo el tráfico de la API a través de TLS, el protocolo que sustenta HTTPS, tanto para las llamadas internas como para las públicas, de modo que el tráfico interceptado no revele información.
Desconfía de las API que consumes. Valida y sanea los datos de los servicios de terceros con el mismo rigor que las entradas de un usuario, restringe a dónde puede enviar solicitudes tu API, y nunca sigas redirecciones hacia destinos no verificados.
Integra la seguridad desde el principio y realiza pruebas continuas. Lleva la seguridad a las revisiones de diseño, incluida la lógica de negocio que los atacantes sondean, y aplica los parches de seguridad en cuanto se divulguen. Combina el escaneo automatizado y el fuzzing, que detectan con rapidez fallos conocidos y casos límite, con pruebas de penetración manuales que revelan las deficiencias de lógica y del control de acceso que las herramientas automáticas no logran detectar. Registra y supervisa la actividad de forma proactiva para reducir el tiempo en que el abuso pasa desapercibido, y vuelve a realizar pruebas tras cada corrección para confirmar que es efectiva.
Fluid Attacks te ayuda a proteger tus API
En Fluid Attacks protegemos APIs y microservicios como parte de un enfoque continuo y exhaustivo de la seguridad de las aplicaciones a lo largo de todo el ciclo de vida del desarrollo. Combinamos el escaneo automatizado con el trabajo manual de pentesters certificados, incluyendo pruebas de penetración, revisión de código seguro e ingeniería inversa, para detectar las fallas de lógica de negocio que las herramientas por sí solas pasan por alto, todo en una única plataforma con tasas mínimas de falsos positivos y orientación clara para la remediación. Inicia una prueba gratuita para poner a prueba tus APIs hoy mismo.
