Seguridad en APIs: el punto ciego detrás de cada integración

7 Min. de lectura

El frontend está endurecido, el login es sólido, el firewall está en su sitio. Y entonces una app móvil llama a una API que entrega cada pedido de cada cliente con solo incrementar en uno el número de la solicitud. Ni herramientas de explotación, ni zero-days, solo una comprobación que falta. Justo ahí, en las APIs detrás de las apps visibles, se ha desplazado la superficie de ataque en los últimos años. Y a menudo está peor protegida que lo que hay delante.

Lo más importante en resumen

La superficie de ataque se ha trasladado. En lugar de una sola página web, hoy son docenas de interfaces detrás de apps, integraciones y conexiones con socios, cada una con su propio acceso a los datos.
BOLA encabeza la lista de OWASP. Falta de autorización a nivel de objeto: basta con incrementar una ID ajena. Es uno de los errores más comunes en APIs y rara vez está en el código escrito a propósito.
Solo se protege lo que se conoce. Las APIs sombra y zombi de versiones antiguas son el problema silencioso. Un inventario de APIs es el paso uno, no el paso cinco.
Los antídotos son discretos. Autorización por objeto, limitación de tasa, validación de esquemas en la pasarela. Se basa en configuración y disciplina, no en un costoso dispositivo.

Relacionado:El kernel compartido como brecha: cómo se producen los escapes de contenedores / 14 paquetes npm maliciosos en 4 horas: la estática ya no basta

Por qué la superficie de ataque se ha desplazado detrás de la app

Hace diez años, la página web era la puerta de entrada. Hoy, la página web es solo la fachada; detrás trabajan las interfaces. La app móvil se comunica con una API, el portal de socios extrae datos a través de una API, el ERP se sincroniza mediante una API, y el asistente de IA que alguien acaba de integrar también llama a una API. Cada una de estas conexiones es una puerta por la que entran y salen datos.

Primer plano de código de programación resaltado en color en una pantalla. — Las APIs suelen crearse rápidamente en el código para servir a una app. La revisión de seguridad suele posponerse. Foto: Godfrey Atima / Pexels

Lo incómodo es que estas puertas son más invisibles que la página de inicio. Un pentest analiza la aplicación web, pero un endpoint de API que solo usa una app puede pasar desapercibido. Justo aquí no me fío de la sensación de tenerlo todo controlado. Más veces de las que me gustaría, he encontrado una API de la que el equipo juraba que ya no existía.

BOLA y la lista OWASP: dónde falla en concreto

¿Qué es la seguridad de APIs? La seguridad de APIs abarca las medidas que protegen una interfaz de programación frente a usos indebidos: autenticación correcta, autorización a nivel de objeto y función, limitación de la carga y validación de los datos transmitidos. Se diferencia de la seguridad web clásica porque, en una API, cada llamada impacta directamente en la lógica de negocio, sin una capa de protección intermedia.

El Top 10 de Seguridad de APIs de OWASP es el mapa más útil para identificar las vulnerabilidades que realmente aparecen en la práctica. En primer lugar está BOLA, *Broken Object Level Authorization* (Autorización rota a nivel de objeto). El servidor verifica si alguien está autenticado, pero no si el objeto solicitado le pertenece. Una llamada a /api/orders/1043 devuelve el propio pedido, mientras que /api/orders/1044 muestra el de un tercero. No se necesita ninguna herramienta, basta con un contador.

Justo al lado se encuentran la autenticación rota, donde los tokens tienen una vida demasiado larga o se validan de forma laxa, y el consumo ilimitado de recursos, en el que un único cliente puede saturar la interfaz con peticiones descontroladas. Ninguna de estas brechas es exótica. Surgen porque una API se construye rápido para dar servicio a una app, y las cuestiones de seguridad se posponen para «más tarde». En la práctica, ese «más tarde» rara vez llega.

Visión clásica del perímetro	Realidad de las APIs
Protege la aplicación web visible	Docenas de endpoints, muchos de ellos sin documentar
Ataque a través de campos de entrada y sesiones	Ataque mediante IDs incrementales, debilidades en tokens y carga
Un WAF cubre gran parte	La autorización debe implementarse por objeto en la aplicación

APIs en la sombra: solo se protege lo que se conoce

El mayor problema rara vez es la interfaz de la que todos hablan, sino aquella que nadie recuerda. Las *shadow APIs* surgen cuando un equipo crea rápidamente un endpoint y nunca lo incluye en la documentación oficial. Las *zombie APIs* son versiones antiguas que siguen activas tras un lanzamiento porque «no molestan a nadie». Ambas circulan sin parches, sin revisiones y, a menudo, sin reglas de acceso actualizadas.

Por eso la seguridad de APIs no empieza con una herramienta, sino con una lista. Quien no conoce sus endpoints no puede protegerlos, monitorizarlos ni desactivarlos. Esto suena obvio, pero es el paso que la mayoría omite porque parece un trabajo tedioso. Sin este esfuerzo previo, el resto no es más que cosmética.

Cinco pasos que soportan la mayor carga

La buena noticia para las pymes: la seguridad de las API rara vez requiere un nuevo appliance caro. Exige hacer unas pocas cosas de manera consistente. Estos cinco pasos soportan la mayor parte de la carga.

Llevar un inventario. Registrar cada endpoint, incluidos los antiguos y los no oficiales. Un gateway o un escaneo sencillo hacen visible lo que realmente es accesible.
Verificar la autorización por objeto. En cada llamada, no solo preguntar si alguien está autenticado, sino si le pertenece el objeto solicitado. Esta es la respuesta directa a BOLA.
Centralizar la autenticación en el gateway. Aplicar de forma centralizada la verificación de tokens, tiempos de expiración y scopes, en lugar de implementarlos de nuevo y con posibles errores en cada aplicación.
Establecer rate-limiting. Un límite superior por cliente dificulta el rápido ensayo de IDs y evita la sobrecarga por un único solicitante. La solución real contra BOLA sigue siendo la autorización por objeto del paso dos.
Validar las entradas según el esquema. Lo que no se ajusta a la estructura esperada se rechaza antes de llegar a la lógica de negocio.

Nada de esto es nuevo, y precisamente ese es el punto. Las brechas en las API no surgen porque falte conocimiento, sino porque la interfaz se construyó bajo presión de tiempo y la protección se pospuso. Configurar estos ajustes una vez como estándar es más económico que el primer incidente en el que alguien haya extraído los pedidos de toda la clientela.

El primer paso sin equipo de seguridad

Quien no tenga un equipo de seguridad no empieza con la herramienta más cara, sino con la pregunta más incómoda: ¿qué interfaces tenemos realmente y quién puede acceder a qué datos a través de ellas? La respuesta a esto suele revelar más que cualquier escáner comprado. Un API Gateway, que muchos proveedores cloud incluyen de serie, centraliza la autenticación, el rate-limiting y el logging en un solo lugar y convierte puertas dispersas en una entrada controlada.

El resto es cuestión de actitud. Una interfaz no está terminada hasta que alguien haya decidido quién puede invocarla y qué ocurre si alguien lo hace con demasiada frecuencia. Mientras falte esta decisión, la API no es un producto, sino una ventana abierta que aún no ha encontrado nadie.

Preguntas frecuentes

¿Qué diferencia la seguridad de API de la seguridad web clásica?

La seguridad web clásica protege una interfaz tras la que se encuentra la lógica. Una API no tiene interfaz; cada llamada impacta directamente en la lógica. Por eso no basta con un WAF: el control real, especialmente la autorización por objeto, debe residir en la propia aplicación.

¿Qué es BOLA y por qué es tan común?

BOLA significa Broken Object Level Authorization (Autorización rota a nivel de objeto). El servidor verifica si un usuario está autenticado, pero no si le pertenece el objeto solicitado. Quien incremente una ID en la petición puede ver datos ajenos. Es común porque esta verificación se olvida fácilmente cuando una API se desarrolla rápido para una app.

¿Necesito una herramienta cara de seguridad para API?

Al principio, no. Un inventario de API, autorización por objeto, un gateway para autenticación y rate-limiting, además de la validación de esquemas, cubren la mayor parte. Las herramientas especializadas ayudan a escalar y a detectar Shadow-APIs, pero no sustituyen los fundamentos.

¿Qué son las Shadow-APIs y las Zombie-APIs?

Las Shadow-APIs son endpoints creados pero nunca documentados. Las Zombie-APIs son versiones antiguas que siguen activas tras un lanzamiento. Ambas escapan al control y suelen tener reglas de acceso obsoletas. Son una de las principales razones por las que un inventario completo es el primer paso.

¿Por dónde debería empezar una pyme sin equipo de seguridad?

Con un inventario: ¿qué interfaces existen y quién puede acceder a qué datos a través de ellas? Después, utilizar un API Gateway, que muchos proveedores cloud incluyen, para centralizar la autenticación, el rate-limiting y el logging. Es más económico y efectivo que un escáner comprado sin haber sentado las bases.