Volver al blog
29 de abril de 2026

Cómo proteger tus endpoints de API contra ataques BOLA

Ha construido una API elegante. Es rápida, escalable e impulsa una excelente experiencia de usuario. Probablemente ha cumplido con los requisitos básicos: tiene HTTPS habilitado, está utilizando JWTs o claves de API para la autenticación, y quizás incluso ha ejecutado un escáner de vulnerabilidades. Se siente seguro. Pero existe un asesino silencioso en el mundo de la seguridad de API que los escáneres tradicionales a menudo pasan por alto, y no requiere un exploit complejo ni una carga útil sofisticada para funcionar.

Se llama BOLA—Broken Object Level Authorization.

Si no está familiarizado con el término, BOLA es esencialmente el truco de "intercambio de ID". Imagine que un usuario inicia sesión en su aplicación y ve su perfil en api.example.com/user/12345. Nota el número al final. Por capricho, cambia 12345 a 12346. Si su servidor devuelve alegremente los datos privados del usuario 12346 sin verificar si el solicitante realmente tiene permiso para verlos, tiene una vulnerabilidad BOLA.

Suena simple, casi demasiado simple. Pero esta simplicidad es la razón por la que BOLA se clasifica constantemente como la amenaza número 1 en el OWASP API Security Top 10. ¿Por qué? Porque no es un fallo de autenticación (saber quién es el usuario), sino un fallo de autorización (saber qué se le permite hacer al usuario).

Proteger sus puntos finales de API contra ataques BOLA no se trata de añadir un firewall más grande; se trata de cambiar la forma en que su aplicación maneja la propiedad de los datos. En esta guía, desglosaremos exactamente cómo funciona BOLA, por qué ocurre y los pasos concretos que puede seguir para asegurar sus puntos finales de forma definitiva.

¿Qué es exactamente BOLA y por qué es tan peligrosa?

Para entender BOLA, tenemos que distinguir entre autenticación y autorización. Estos dos términos se usan indistintamente, pero en el contexto de la seguridad de API, son mundos aparte.

Autenticación es el proceso de verificar la identidad de un usuario. "¿Es usted quien dice ser?" Cuando un usuario proporciona una contraseña o un token y su sistema dice "Sí", está autenticado.

Autorización es el proceso de verificar permisos. "Ahora que sé quién es usted, ¿tiene permiso para acceder a esta pieza específica de datos?"

BOLA ocurre cuando una aplicación proporciona acceso a un objeto (un registro de base de datos, un archivo, una cuenta de usuario) basándose en la entrada proporcionada por el usuario, pero no verifica que el usuario autenticado realmente posea o tenga permiso para acceder a ese objeto.

La anatomía de un ataque BOLA

Un ataque BOLA típico sigue un patrón muy predecible:

  1. Observación: El atacante crea una cuenta legítima en su plataforma. Comienza a usar la aplicación y nota que las solicitudes de API utilizan identificadores predecibles (como números enteros) en la URL.
  2. Manipulación: El atacante utiliza una herramienta de proxy (como Burp Suite o Postman) para interceptar una solicitud. Ve una solicitud como GET /api/v1/orders/9876.
  3. Iteración: El atacante cambia 9876 a 9875, 9874, y así sucesivamente.
  4. Exfiltración: Si el servidor no verifica la propiedad del pedido 9875, devuelve los datos. El atacante luego escribe un script simple para recorrer miles de ID, extrayendo toda su base de datos en minutos.

Por qué las herramientas de seguridad tradicionales no detectan BOLA

Si está utilizando un Web Application Firewall (WAF) estándar o un escáner de vulnerabilidades básico, quizás se pregunte por qué no le advirtieron sobre esto.

El problema es que los ataques BOLA parecen tráfico perfectamente legal. Para un WAF, una solicitud para /api/v1/orders/9875 parece idéntica a una solicitud para /api/v1/orders/9876. Ambas son solicitudes HTTP GET válidas. Ambas tienen un token de autenticación válido. El "ataque" ocurre en la lógica de negocio de su código, no en el formato de la solicitud.

Aquí es donde se hace evidente la brecha entre el "escaneo" y las "pruebas". Un escáner busca firmas conocidas (como cadenas de SQL Injection); un Penetration Test busca fallos de lógica. Por eso, los equipos se están moviendo hacia Continuous Threat Exposure Management (CTEM) y utilizando plataformas como Penetrify. Necesita un sistema que entienda el contexto de sus llamadas API, no solo si la solicitud está "bien formada".

Escenarios Comunes Donde BOLA se Infiltra

BOLA no se limita a un solo tipo de endpoint. Tiende a aparecer dondequiera que se utilice un ID único para obtener datos. Aquí están algunos de los lugares más comunes donde se esconde.

Perfiles de Usuario y Configuración de Cuenta

Este es el ejemplo clásico. Endpoints como /api/users/{userId}/settings o /api/me/profile son objetivos principales. Si el backend simplemente toma el {userId} de la URL y consulta la base de datos sin verificar si current_user.id == requested_userId, cualquier usuario autenticado puede ver o editar la configuración de cualquier otro usuario.

Comercio Electrónico e Historial de Pedidos

Piense en una página de "Mis Pedidos". La API podría llamar a /api/orders/{orderId}. Un atacante puede simplemente incrementar el orderId para ver las compras, direcciones y números de teléfono de otras personas. Esto es una mina de oro para los ladrones de identidad.

Aislamiento de Inquilinos SaaS

Para empresas que desarrollan aplicaciones SaaS multi-inquilino, BOLA puede ser catastrófico. Si tiene una estructura como /api/tenant/{tenantId}/projects, y un usuario del Inquilino A puede acceder a proyectos del Inquilino B simplemente cambiando el tenantId, tiene una fuga de datos masiva. Esto no es solo un bug; es un fallo fundamental del aislamiento de inquilinos.

Carga y Descarga de Archivos

Muchas aplicaciones almacenan archivos (facturas, identificaciones, fotos) y los sirven a través de endpoints como /api/files/download?fileId=5542. Si el sistema no verifica si el usuario tiene permiso para acceder a fileId 5542, un atacante puede extraer cada documento subido a su plataforma.

Guía Paso a Paso para Implementar Defensas BOLA

Entonces, ¿cómo se detiene esto realmente? Requiere un enfoque por capas. No puede depender de una única solución "bala de plata". En su lugar, necesita integrar la autorización en la propia estructura de su diseño de API.

1. Implementar Verificaciones Estrictas de Autorización a Nivel de Objeto

La forma más directa de detener BOLA es verificar la propiedad en cada solicitud que accede a un recurso.

La forma incorrecta (Pseudo-código):

app.get('/api/orders/:orderId', async (req, res) => {
  const order = await db.Orders.findOne({ id: req.params.orderId });
  res.json(order); 
  // PELIGRO: ¡No se verifica si el pedido pertenece al usuario!
});

La forma correcta (Pseudo-código):

app.get('/api/orders/:orderId', async (req, res) => {
  const userId = req.user.id; // Obtener ID del JWT autenticado
  const orderId = req.params.orderId;

  const order = await db.Orders.findOne({
    where: {
      id: orderId,
      userId: userId // DEBE filtrar por el ID del propietario
    }
  });

  if (!order) {
    return res.status(404).send('Pedido no encontrado');
    // Usar 404 en lugar de 403 para evitar filtrar que el ID existe
  }
  res.json(order);
});

Al incluir el userId en la propia consulta de la base de datos, te aseguras de que la base de datos solo devuelva el registro si pertenece a la persona que lo solicita. Si el ID existe pero no pertenece al usuario, la consulta devuelve null y envías un 404.

2. Reemplazar IDs Predecibles con UUIDs

Usar enteros secuenciales (1, 2, 3...) para tus claves primarias es un regalo para los atacantes. Hace que el "ID walking" o la "enumeración" sea trivial.

Aunque usar UUIDs (Universally Unique Identifiers) no soluciona el error de autorización subyacente, hace que sea casi imposible para un atacante adivinar un ID válido.

  • ID Secuencial: 1001 $\rightarrow$ el siguiente es 1002.
  • UUID: 550e8400-e29b-41d4-a716-446655440000.

Cambiar a UUIDs aumenta el "costo" del ataque. Un atacante no puede simplemente escribir un bucle for de 1 a 10.000. Tendrían que encontrar un UUID válido primero. Sin embargo, recuerda: los UUIDs son ofuscación, no seguridad. Si un atacante encuentra un UUID en un registro filtrado o en una respuesta de API diferente, aún puede explotar una vulnerabilidad BOLA si tus comprobaciones de autorización faltan.

3. Usar un Middleware de Autorización Centralizado

Escribir la lógica de autorización dentro de cada controlador es una receta para el desastre. Olvidarás uno. Pasarás por alto un caso límite.

En su lugar, mueve tu lógica de autorización a un middleware o a un servicio dedicado. Esto asegura una política consistente en toda la API. Puedes implementar un sistema de control de acceso basado en políticas donde defines quién puede realizar qué acción sobre qué recurso.

Por ejemplo, un middleware podría verificar: canUserAccessResource(user, resourceType, resourceId, action)

Si trabajas en un entorno complejo con múltiples proveedores de nube (AWS, Azure, GCP), gestionar estos permisos puede volverse complicado. Aquí es donde la orquestación de seguridad automatizada se vuelve vital. Herramientas como Penetrify te ayudan a mapear tu superficie de ataque y simular este tipo de ataques de "intercambio de ID" en tus entornos para encontrar las brechas que tus desarrolladores podrían haber pasado por alto.

4. Implementar Limitación de Tasa y Detección de Anomalías

Un ataque BOLA generalmente implica un alto volumen de solicitudes en un corto período de tiempo mientras el atacante intenta extraer datos. Si bien la limitación de tasa no detendrá una única solicitud BOLA dirigida, sí detendrá un intento de exfiltración masiva de datos.

  • Límites de Tasa por Usuario: Limita el número de solicitudes que un único usuario autenticado puede hacer a puntos finales sensibles.
  • Monitoreo de 404: Si un solo usuario activa 500 errores de "Not Found" en un minuto en un punto final como /api/orders/{id}, es casi seguro que está buscando IDs válidos. Activa una alerta o banea temporalmente la IP/cuenta.

BOLA en Diferentes Arquitecturas de API: GraphQL y REST

La forma en que combates BOLA depende ligeramente de cómo está estructurada tu API.

BOLA en APIs REST

En REST, BOLA suele ocurrir en la ruta de la URL (como hemos comentado). La solución es sencilla: siempre valida que el userId extraído de la sesión/token tenga una relación con el resourceId en la URL.

BOLA en GraphQL

GraphQL es un poco más complicado porque utiliza un único endpoint (normalmente /graphql) y un lenguaje de consulta. Los atacantes no cambian la URL; cambian los argumentos dentro de la consulta.

Ejemplo de consulta GraphQL:

query {
  user(id: "12345") {
    email
    phoneNumber
    creditCardLastFour
  }
}

Un atacante simplemente cambia el argumento id. Dado que GraphQL a menudo implica "anidamiento" (obtener un usuario, luego sus pedidos, luego los detalles de envío de esos pedidos), una única vulnerabilidad BOLA en un resolver puede provocar una cascada masiva de fuga de datos.

La solución para GraphQL: La autorización debe ocurrir a nivel de resolver. Cada resolver que obtiene un objeto de la base de datos debe realizar la misma verificación de propiedad que discutimos para las API REST. No asumas que, porque la consulta de nivel superior fue autorizada, los objetos anidados también lo están.

Comparando el Penetration Testing Manual vs. la Detección Automatizada de BOLA

Si BOLA es tan peligrosa, ¿por qué no contratar una firma de Penetration Testing una vez al año? Aquí está la realidad del modelo "una vez al año".

Característica Penetration Testing Manual Tradicional Pruebas Automatizadas Continuas (ej., Penetrify)
Frecuencia Anual o Semestral Bajo Demanda / Continuo
Costo Alto (Tarifas de firmas boutique) Basado en Suscripción / Escalable
Cobertura Profunda pero una instantánea en el tiempo Amplia y evoluciona con los cambios de código
Ciclo de Retroalimentación Semanas después de la prueba En tiempo real o casi en tiempo real
Integración CI/CD Ninguna (Entrega manual) Integrado con DevSecOps

Los testers manuales son excelentes para encontrar fallos lógicos complejos, pero no pueden estar presentes cada vez que tus desarrolladores suben un nuevo commit a producción. Si un desarrollador añade un nuevo endpoint /api/v1/user-preferences un martes, y tu último Penetration Test fue en enero, ese endpoint es una puerta abierta para BOLA hasta el próximo enero.

Por eso abogamos por el Penetration Testing as a Service (PTaaS). Al automatizar las fases de reconocimiento y escaneo, puedes avanzar hacia la Gestión Continua de la Exposición a Amenazas (CTEM). No solo estás escaneando en busca de "bugs"; estás simulando el comportamiento de un atacante que intenta manipular IDs de objetos.

Estrategias Avanzadas para Entornos de Alta Seguridad

Para aquellos que manejan datos altamente sensibles (registros médicos, transacciones financieras, datos gubernamentales), "suficientemente bueno" no es suficiente. Necesitas una estrategia de defensa en profundidad.

1. Utiliza Referencias de Objetos Indirectas (Basadas en Mapas)

Si no puedes confiar en absoluto en el cliente con ninguna versión de un ID de base de datos, utiliza un mapa específico de la sesión.

En lugar de exponer order_id: 9876 al usuario, tu servidor genera una clave temporal aleatoria para esa sesión:

  • TemporaryKey_A $\rightarrow$ order_id: 9876
  • TemporaryKey_B $\rightarrow$ order_id: 9877

El cliente solo ve TemporaryKey_A. Si intenta adivinar TemporaryKey_C, no existe en su mapa de sesión y la solicitud falla. Esto elimina por completo la previsibilidad del ID.

2. Control de Acceso Basado en Atributos (ABAC)

A medida que su organización crece, el Control de Acceso Basado en Roles (RBAC), como "Admin" o "User", se vuelve demasiado impreciso. Necesita ABAC.

ABAC le permite definir políticas basadas en atributos:

  • Atributo de Usuario: ClearanceLevel: Level 2
  • Atributo de Recurso: Sensitivity: Level 2
  • Atributo de Entorno: AccessTime: 9am-5pm

Una verificación BOLA en un sistema ABAC se vería así: "¿Puede este usuario acceder a este objeto si el departamento del usuario coincide con el departamento del objeto Y el objeto no está marcado como 'Private'?" Esto proporciona un nivel de seguridad mucho más granular.

3. Firmas Digitales para IDs

Algunas APIs de alta seguridad firman sus IDs. Cuando el servidor envía un ID al cliente, adjunta una firma criptográfica (un HMAC). Cuando el cliente devuelve el ID, el servidor verifica la firma. Si el usuario cambia 123 a 124, la firma se vuelve inválida y el servidor rechaza la solicitud inmediatamente, incluso antes de que llegue a la base de datos.

Errores Comunes al Intentar Corregir BOLA

Incluso los desarrolladores experimentados cometen estos errores. Si está auditando su código, preste atención a estos patrones.

Error 1: Confiar en el Frontend para Ocultar Botones

"El usuario no puede acceder a la página 'Edit' porque oculté el botón en la interfaz de usuario de React." Esto es seguridad por oscuridad. Un atacante no usa su interfaz de usuario; usa una terminal o un proxy. Siempre asuma que el atacante conoce cada uno de los endpoints de API que tiene.

Error 2: Verificar la Autorización Solo en el Punto de Entrada

Los desarrolladores a menudo verifican si un usuario ha iniciado sesión al comienzo de una solicitud y luego asumen que todo dentro de esa solicitud es seguro.

  • Mal: if (!user.isAuthenticated) return 401; $\rightarrow$ proceder a buscar cualquier ID.
  • Bien: if (!user.isAuthenticated) return 401; $\rightarrow$ if (!user.owns(resourceId)) return 404;.

Error 3: Filtrar IDs Válidos en Otros Endpoints

Puede que haya corregido BOLA en su endpoint /api/orders, pero ¿tiene un endpoint /api/search/users que devuelva una lista de todos los IDs de usuario? Si es así, acaba de darle al atacante el mapa que necesita para atacar sus otros endpoints. Minimice siempre la cantidad de datos de ID que expone en las vistas de "lista" o "búsqueda".

Error 4: Usar 403 Forbidden en Lugar de 404 Not Found

Cuando un usuario solicita un objeto que no posee, devolver 403 Forbidden le dice al atacante: "Este objeto existe, pero no tiene permiso para verlo." Al devolver 404 Not Found, le dice al atacante: "No tengo idea de qué está hablando." Esto evita que el atacante confirme si un ID específico es válido o no.

La Lista de Verificación de Auditoría "BOLA" para su Equipo

Si lidera un equipo de DevOps o Seguridad, puede usar esta lista de verificación durante su próxima revisión de sprint o auditoría de seguridad.

  • Inventario: ¿Tenemos una lista completa de todos los endpoints de la API que aceptan un ID como parámetro?
  • Identidad: ¿Estamos extrayendo el ID de usuario de un token seguro del lado del servidor (como un JWT) en lugar de confiar en un ID de usuario enviado en el cuerpo de la solicitud o en la URL?
  • Propiedad: ¿Cada consulta a la base de datos para un recurso específico incluye un filtro para el ID de usuario propietario o el ID de inquilino?
  • Previsibilidad: ¿Estamos utilizando UUIDs u otros identificadores no secuenciales para recursos de cara al público?
  • Consistencia: ¿La autorización se gestiona en un middleware o servicio centralizado en lugar de duplicarse en cada controlador?
  • Manejo de Errores: ¿Estamos devolviendo 404s en lugar de 403s para el acceso no autorizado a objetos?
  • Limitación de Tasa: ¿Tenemos alertas para los usuarios que activan un número inusual de 404s en los endpoints de recursos?
  • Pruebas: ¿Estamos realizando pruebas automatizadas de "intercambio de ID" como parte de nuestro pipeline de CI/CD?

Cómo Penetrify Simplifica la Detección de BOLA

Encontrar vulnerabilidades BOLA manualmente es tedioso. Hay que mapear cada endpoint, crear múltiples cuentas de usuario y probar manualmente cada combinación de IDs. Para un equipo pequeño, es una tarea imposible. Para un equipo grande, es un cuello de botella.

Esta es exactamente la razón por la que se creó Penetrify. En lugar de depender de un escaneo estático que busca "librerías desactualizadas", Penetrify se centra en la superficie de ataque.

Así es como te ayuda a resolver el problema de BOLA:

  1. Mapeo Automatizado de la Superficie de Ataque: Penetrify identifica todos tus endpoints expuestos, incluidos aquellos que tus desarrolladores podrían haber olvidado documentar.
  2. Simulación Inteligente de Lógica: La plataforma no solo envía cadenas aleatorias; analiza cómo están estructurados tus IDs e intenta simular el comportamiento de "ID walking" que utilizan los pentesters manuales.
  3. Monitoreo Continuo: Al ser nativo de la nube, Penetrify puede integrarse en tu flujo de trabajo de DevSecOps. Cada vez que implementas una nueva versión de tu API, reevalúa tu perímetro de seguridad.
  4. Remediación Accionable: No solo recibes un informe que dice "Tienes un error BOLA". Obtienes orientación específica sobre qué endpoint es vulnerable y cómo implementar la verificación de autorización para solucionarlo.

Al cerrar la brecha entre un simple escáner de vulnerabilidades y una costosa auditoría manual, Penetrify permite a las PYMES y startups SaaS demostrar su madurez de seguridad (para el cumplimiento de SOC2 o HIPAA) sin necesidad de un Red Team interno a gran escala.

Preguntas Frecuentes (FAQ)

P: ¿No puedo simplemente usar un WAF para detener BOLA?

No, no de forma efectiva. Como se mencionó, los ataques BOLA utilizan sintaxis válida y autenticación válida. Un WAF examina la estructura de la solicitud, mientras que BOLA es un fallo de la lógica de negocio. Aunque un WAF puede ayudar con la limitación de tasa para ralentizar a un atacante, no puede determinar si el Usuario A debería tener acceso a la Orden B.

P: ¿El uso de JWTs (JSON Web Tokens) previene BOLA?

No. Los JWTs gestionan la autenticación (demostrar quién es el usuario). No gestionan la autorización (a qué puede acceder el usuario). Un usuario puede tener un JWT perfectamente válido y firmado y aun así usarlo para solicitar un objeto que no le pertenece si tu backend no realiza la verificación de propiedad.

P: Si utilizo una base de datos NoSQL como MongoDB, ¿sigo en riesgo?

Sí. BOLA es independiente del tipo de base de datos. Ya sea que esté utilizando un _id de MongoDB (que son naturalmente más complejos que los enteros) o una secuencia de PostgreSQL, la vulnerabilidad existe si la aplicación permite a un usuario solicitar un registro por un ID sin verificar la propiedad.

P: ¿Es BOLA lo mismo que IDOR?

Esencialmente, sí. IDOR (Insecure Direct Object Reference) es el término más antiguo y amplio. BOLA es la terminología moderna específicamente adaptada a las API. En el contexto de una API, un ataque BOLA es una forma de IDOR.

P: ¿Cómo pruebo BOLA sin comprar una herramienta costosa?

Puede comenzar utilizando un proxy como Burp Suite (Community Edition). Cree dos cuentas de usuario separadas. Inicie sesión como Usuario A, capture una solicitud de un recurso de su propiedad y luego reemplace el ID del recurso con un ID que pertenezca al Usuario B. Si puede ver los datos del Usuario B mientras está conectado como Usuario A, tiene una vulnerabilidad BOLA.

Reflexiones Finales: Más Allá de la Seguridad Puntual

El mayor error que una empresa puede cometer en la seguridad de las API es creer que un único informe de Penetration Test "limpio" significa que están seguros. La seguridad no es un destino; es un estado de mantenimiento constante.

Su código cambia todos los días. Su infraestructura escala. Se añaden nuevos endpoints para satisfacer una solicitud del cliente. Cada uno de estos cambios es una oportunidad para que una vulnerabilidad BOLA se cuele.

La transición de "auditorías una vez al año" a la "Gestión Continua de la Exposición a Amenazas" es la única forma de adelantarse a los atacantes modernos. Al combinar una lógica de autorización estricta, IDs no predecibles y plataformas de pruebas automatizadas como Penetrify, puede dejar de tratar la seguridad como una casilla de verificación y empezar a tratarla como una característica central de su producto.

No espere a una filtración de datos para descubrir que su lógica de autorización está rota. Comience a auditar sus endpoints hoy mismo, implemente las verificaciones de propiedad que hemos discutido y automatice sus pruebas para que pueda concentrarse en construir su producto en lugar de preocuparse por el próximo ataque de "intercambio de ID".

¿Listo para ver si sus API son realmente seguras? Deje de adivinar y empiece a probar. Visite Penetrify para descubrir cómo las pruebas de seguridad automatizadas y bajo demanda pueden proteger sus datos y su reputación.

Volver al blog