Principales riesgos de seguridad de las API

¿Cuáles son los principales riesgos de seguridad de las API?

Los principales riesgos de seguridad de las API son las debilidades que los atacantes explotan con más frecuencia para leer datos ajenos, tomar cuentas o tumbar un servicio. La lista de referencia es el OWASP API Security Top 10, publicado por última vez para 2023. Nombra diez categorías, casi todas relacionadas con comprobaciones que faltan en el servidor: quién puede ver qué objeto, qué campo y qué función, y cuánto puede consumir. Cada riesgo tiene abajo una explicación breve y la solución habitual.

El OWASP API Security Top 10 (2023)

API1:2023 Broken Object Level Authorization

La API toma un ID de objeto del cliente (por ejemplo /orders/1043) y devuelve el registro sin comprobar que quien llama puede verlo. Solución: comprobar la propiedad en cada acceso a un objeto, en el servidor, y usar IDs impredecibles como capa adicional, no como sustituto.

API2:2023 Broken Authentication

El inicio de sesión o la gestión de tokens y claves es débil: sin límite de intentos, tokens que nunca caducan, secretos en URLs o tokens sin firma aceptados. Solución: tokens de vida corta, verificación estricta de firma y caducidad, límites a los intentos de credenciales.

API3:2023 Broken Object Property Level Authorization

El llamante puede ver o modificar un objeto pero no todos sus campos: las respuestas exponen demasiado (excessive data exposure) o la API deja escribir campos como role o price (mass assignment). Solución: listas explícitas de campos permitidos al devolver y al aceptar datos.

API4:2023 Unrestricted Resource Consumption

Las peticiones consumen CPU, memoria, ancho de banda o llamadas de pago a terceros sin límite, de modo que un cliente puede degradar el servicio o disparar la factura. Solución: límites de tasa, topes de tamaño de carga y de página, timeouts y cuotas por cliente. Es también el riesgo que revela una prueba de carga.

API5:2023 Broken Function Level Authorization

Usuarios normales pueden llamar a funciones administrativas o privilegiadas, por ejemplo cambiando GET por DELETE o adivinando una ruta /admin. Solución: denegar por defecto y comprobar el rol del llamante en cada función, no solo en la interfaz.

API6:2023 Unrestricted Access to Sensitive Business Flows

Un flujo legítimo, como comprar existencias limitadas, publicar comentarios o canjear un cupón, puede automatizarse a una escala que perjudica al negocio. Solución: detectar la automatización, añadir fricción en los flujos sensibles y limitar por dispositivo, cuenta y regla de negocio. Consulta abuso de API.

API7:2023 Server Side Request Forgery

La API recupera una URL suministrada por el cliente, de modo que un atacante puede hacer que el servidor llame a servicios internos o a endpoints de metadatos de la nube. Solución: lista de destinos permitidos, bloquear rangos de direcciones privadas y no devolver nunca respuestas recuperadas sin filtrar.

API8:2023 Security Misconfiguration

Valores por defecto y deriva de configuración: mensajes de error detallados, falta de TLS, CORS permisivo, métodos HTTP innecesarios, componentes sin parchear. Solución: una base reforzada y repetible, revisada en el código, y una comprobación de que producción la cumple.

API9:2023 Improper Inventory Management

Versiones antiguas, hosts de prueba y endpoints sin documentar siguen accesibles y sin parchear. Solución: mantener un inventario actualizado de hosts, versiones y responsables, y retirar lo que no tiene dueño. Consulta API sprawl.

API10:2023 Unsafe Consumption of APIs

Tu servicio confía más en los datos de APIs de terceros que en los de los usuarios, así que un socio comprometido o con errores puede inyectar datos erróneos o redirigir tráfico. Solución: validar y limitar lo que pueden hacer las respuestas de terceros, exigir TLS y timeouts y tratarlas como entrada no fiable.

Cómo usar la lista

Empieza por API1, API2 y API5: los fallos de autorización y autenticación causan las fugas más graves, y un escáner los detecta mal porque cada petición parece válida. Pruébalos con dos cuentas: inicia sesión como el usuario A y pide objetos del usuario B, y repite sin token. Después, relaciona el resto con tu stack. La disciplina en conjunto se explica en seguridad de API, y las técnicas de los atacantes en ataques a API.

Errores comunes

• Comprobar la autorización solo en la interfaz. La API se llama directamente, así que toda comprobación debe estar en el servidor.
• Tratar la lista como un checklist de una sola vez. Los endpoints y versiones nuevos traen los mismos riesgos de vuelta.
• Tomar los identificadores por secretos. Un ID difícil de adivinar no es autorización.
• Filtrar credenciales. Los tokens en URLs y registros acaban en malas manos. Consulta bearer token.
• Ignorar los límites. Sin límite de tasa, tope de tamaño de página ni timeout, API4 está abierto.

Dónde ayudan la monitorización y las pruebas

LoadFocus no es un escáner de vulnerabilidades y no encuentra fallos de inyección ni de autorización. Aun así, puede apoyar algunos de estos controles. La monitorización de APIs envía comprobaciones HTTP programadas y verifica el código de estado, las cabeceras y el cuerpo de la respuesta, de modo que puedes alertar si un endpoint que debería responder 401 o 403 sin token empieza a devolver 200, o si reaparece una versión antigua que habías retirado. Las pruebas de carga muestran cómo se comporta un endpoint con muchas peticiones simultáneas, es decir, si los límites detrás de API4 se cumplen de verdad. Para elegir herramientas, lee nuestra guía de herramientas de monitorización de APIs (en inglés). Para pruebas de penetración y escaneos de vulnerabilidades, usa un probador de seguridad especializado.

Preguntas frecuentes

¿Cuál es el riesgo de seguridad de API número uno?

En el OWASP API Security Top 10 de 2023, la primera entrada es Broken Object Level Authorization (BOLA). Ocurre cuando una API devuelve un objeto por su ID sin comprobar que quien llama puede acceder a él.

¿En qué se diferencia el Top 10 de API del de aplicaciones web?

La lista de aplicaciones web cubre problemas del lado del navegador como la inyección y el cross-site scripting. La de API se centra en cómo las API exponen directamente objetos, propiedades y flujos de negocio, por lo que la autorización y los límites de recursos ocupan puestos mucho más altos.

¿Cada cuánto se actualiza el OWASP API Security Top 10?

La edición actual es de 2023 y la anterior de 2019. Consulta la web de OWASP para ver la versión más reciente antes de basar una revisión en ella.

¿Puede una prueba de carga encontrar problemas de seguridad en una API?

No directamente. Una prueba de carga muestra cómo se comporta una API con mucho tráfico, lo que ayuda a confirmar límites de tasa y topes de recursos. No detecta fallos de autorización ni de inyección, así que sigues necesitando pruebas de seguridad.