Cuando se trata de la autorización de objetos vulnerada (BOLA), una de las diez principales vulnerabilidades de seguridad de las API según OWASP, el enfoque «shift left» es una estrategia incompleta. BOLA no es un simple error de programación, como una errata, sino un fallo fundamental en la lógica de negocio.
Confiar en que los desarrolladores comprueben manualmente todas y cada una de las reglas de propiedad en un extenso entorno de microservicios es una apuesta de alto riesgo. En 2026, con las estrictas normas de divulgación de la Comisión de Bolsa y Valores de Estados Unidos (SEC) y la aplicación rigurosa del Reglamento General de Protección de Datos (RGPD), un «fallo lógico» puede convertirse rápidamente en un desastre financiero de importancia significativa.
Anatomía de la brecha de autorización
En la era monolítica, la autorización era implícita. El servidor almacenaba la sesión en su propia memoria, sabía exactamente quién había iniciado sesión y controlaba la consulta a la base de datos mediante un único proceso centralizado.
Las arquitecturas modernas en la nube han hecho añicos este modelo. Hoy en día, separamos la identidad (gestionada por proveedores externos) de los datos (alojados en cientos de servicios independientes). Verificamos quién es el usuario en el punto de entrada, pero a menudo dejamos en manos del desarrollador de backend la comprobación de qué recursos posee o a cuáles puede acceder.
“En 2026, los ataques BOLA son una de las vías más rápidas para sufrir una filtración de datos. El enfoque «shift left» es útil para detectar errores técnicos, pero «mantenerse a la derecha» es la única forma de corregir fallos en la lógica de negocio.”
La «brecha de autorización» es el vacío que existe entre un inicio de sesión correcto y la ausencia de una comprobación de propiedad. Dado que los servicios modernos no mantienen estado, confían de forma inherente en las solicitudes que reciben. Si una solicitud incluye «Pedido 7788» y el código no verifica explícitamente que el pedido pertenece al solicitante, los datos quedan expuestos.
Visualización de la brecha de autorización
Para entender por qué confiar únicamente en un firewall de aplicaciones web (WAF) no basta para protegerse frente a las vulnerabilidades BOLA, debemos analizar la desconexión técnica entre la autenticación y la propiedad de los recursos en las API modernas sin estado. Los WAF buscan sintaxis «maliciosa», como la de una inyección SQL, pero los ataques BOLA utilizan sintaxis «válida» que parece corresponder a una solicitud normal. Para detenerlos, la defensa debe tener en cuenta la identidad y validar que el usuario tenga acceso al objeto específico que solicita.
Pensemos en una aplicación bancaria. Un atacante, el usuario A, inicia sesión en su propia cuenta (ID de usuario: 8899) y recibe un token de sesión válido. Este usuario ya está autenticado, por lo que el atacante puede intentar acceder a los datos de otra persona, el usuario B, enviando una solicitud a /api/v1/accounts/1234/balance.
El WAF comprueba si hay inyecciones SQL o scripts maliciosos. Dado que 1234 es un número entero perfectamente válido y la sintaxis es correcta, el WAF permite que la solicitud continúe.
La puerta de enlace de la API verifica que el token de sesión sea válido y no haya caducado. Dado que el usuario A, el atacante, es un usuario legítimo que ha iniciado sesión, la puerta de enlace marca la solicitud como autenticada y la reenvía a los sistemas internos del backend.
Como resultado, el servicio de backend recibe la solicitud «de confianza» y devuelve el saldo de la cuenta 1234. El atacante ha logrado eludir la seguridad porque la puerta de enlace confirmó quién era, pero nunca comprobó a qué tenía permiso para acceder.
En muchas arquitecturas modernas, la puerta de enlace de API actúa como un «portero» que se limita a comprobar la identificación en la entrada. Una vez que un usuario proporciona un JWT o una cookie de sesión válidos, la puerta de enlace da por hecho que todas las solicitudes posteriores de ese usuario son legítimas.
El usuario A inicia sesión y recibe un token válido. A continuación, envía una solicitud a GET/api/v1/data/1234. El siguiente paso del proceso es comprobar la sintaxis y la sesión: el WAF estándar confirma que la solicitud está limpia (sin inyección SQL) y la puerta de enlace de API confirma que la sesión es válida.
Aquí es donde se produce el fallo de autenticación: ni el WAF ni la puerta de enlace comprueban si el recurso 1234 pertenece realmente al usuario A, y el servicio backend confía ciegamente en la solicitud «verificada» por la puerta de enlace y proporciona al usuario A los datos privados del usuario B. Es en este punto donde se produce la brecha de seguridad.
Sin embargo, con una solución avanzada de seguridad de API, este nuevo guardia no se limita a comprobar la identificación del usuario en la puerta, sino que verifica que esté autorizado para entrar en cada una de las salas a las que intenta acceder.
Estos son los pasos que siguen las soluciones avanzadas de seguridad de API para subsanar la brecha de autenticación y comprobar que el usuario que ha iniciado sesión tiene permiso para realizar la acción solicitada en el objeto solicitado.
En el primer paso, el sistema extrae la identidad (Usuario A) del token y el ID del recurso (1234) de la solicitud. A continuación, mediante un mapa de lógica de negocio aprendido, la plataforma identifica que el recurso 1234 pertenece al Usuario B, no al Usuario A.
En el tercer paso, dado que la asignación entre la identidad y el recurso no supera la comprobación lógica, la solicitud se descarta en el perímetro de la aplicación, antes de que pueda interactuar con los sistemas internos. De este modo, la solicitud no autorizada nunca llega al backend de la aplicación, donde se almacenan los datos, lo que impide la exfiltración de datos antes de que comience.
Por qué el enfoque «shift left» no logra detener BOLA
Adelantar las comprobaciones y pruebas de seguridad a etapas más tempranas del ciclo de vida del desarrollo no basta por sí solo para resolver este problema, ya que las tácticas de «shift left» carecen de contexto. Las herramientas como el análisis estático (SAST) examinan el código, no los datos, por lo que no saben que el Usuario A no está autorizado a ver la factura del Usuario B, dado que esa relación se define en la base de datos y no en el código fuente.
Además, la mayoría de las herramientas de análisis dinámico (DAST) solo realizan análisis en el contexto de un único usuario. Al recibir una respuesta «200 OK», la dan por válida, sin detectar que el usuario está accediendo a los registros privados de otro usuario.
Por el contrario, las pruebas estándar de API no tienen en cuenta el contexto. En esencia, es como hacer pruebas en el vacío. Fallan porque ignoran los datos de tráfico del mundo real. Si las pruebas no pueden ver cómo se vincula la Identidad A con el Recurso B en producción, solo pueden validar la sintaxis, no la lógica. No está poniendo a prueba su negocio.
Aplicación de políticas en el perímetro
Para solucionar este problema, las organizaciones necesitan una estrategia de ejecución de tres capas que conste de:
- Asignación de usuarios a recursos. La solución de seguridad de API extrae la identidad del token y la compara con el ID del recurso incluido en el mensaje de solicitud HTTP (encabezado, cookie, ruta o cuerpo).
- Un sidecar de Open Policy Agent (OPA). En lugar de confiar en que cientos de desarrolladores escriban comprobaciones específicas, utilice OPA para gestionar las reglas de autorización desde un único lugar centralizado. Un sidecar de OPA es un patrón de despliegue que se ejecuta junto a un contenedor de aplicaciones para proporcionar decisiones de autorización locales de baja latencia y alto rendimiento, lo que permite evaluar las políticas en tiempo real para microservicios y la seguridad de las API.
- Monitorización del comportamiento. Para detener los ataques BOLA, la defensa debe extraer la identidad (quién), el contexto (cómo) y el recurso (qué) del tráfico en tiempo real para establecer una referencia de las relaciones normales. Por ejemplo, si un único usuario se desvía de la referencia establecida, como al intentar acceder a 50 identificadores diferentes en un minuto, el sistema detecta esta anomalía. Es una señal clara de que se trata de un scraper, no de una persona, y debe bloquearse de inmediato.
Cómo ayuda F5
F5 Distributed Cloud API Security ofrece una vía clara para pasar de una visibilidad nula a una protección obligatoria en tiempo de ejecución. Como parte de F5 Distributed Cloud Services, proporciona seguridad unificada al combinar la entrega y la seguridad de aplicaciones en una única plataforma. Al correlacionar la inteligencia de componentes como la mitigación de ataques distribuidos de denegación de servicio (DDoS), la protección contra bots, la seguridad de las API y el WAF, aprovecha la automatización para distinguir entre la solicitud de un único cliente y los ataques coordinados de múltiples vectores.
La función de detección de API del producto encuentra automáticamente todas las API, incluidas las «API en la sombra», y analiza continuamente el tráfico de producción para conocer la lógica de negocio real de su aplicación y determinar cómo interactúan los usuarios con objetos de datos específicos. Las pruebas sensibles al contexto utilizan esta información para ejecutar «pruebas matriciales» específicas en entornos de preproducción e identificar puntos débiles en las correspondencias entre identidades y objetos antes de desplegar el código.
Distributed Cloud API Security también ofrece detección de ataques BOLA e identifica diversos escenarios BOLA mediante la correlación de patrones de comportamiento de referencia aprendidos con las solicitudes entrantes para detectar actividades sospechosas, lo que puede servir de base para las protecciones en tiempo de ejecución.
En 2026, los ataques BOLA son una de las vías más rápidas para sufrir una filtración de datos. El enfoque «shift left» resulta útil para detectar errores técnicos, pero «mantenerse a la derecha» es la única forma de corregir una lógica de negocio defectuosa. Traslade la autorización al perímetro y detenga ya la fuga de datos.
Descubra cómo F5 puede ayudar a las organizaciones a proteger sus API, o véalo en acción.
Sobre los autores
Artículos relacionados del blog
IA agéntica en ciberseguridad: promesas y riesgos
Descubre por qué el uso de la IA agéntica en ciberseguridad es esencial para combatir las amenazas impulsadas por IA y por qué los agentes también generan nuevos riesgos empresariales.
Cómo los clientes de F5 del sector financiero abordan la soberanía digital sin frenar la innovación
¿Cómo se materializa la soberanía digital en el mundo real? Dos proyectos recientes de F5 con clientes muestran cómo distintas empresas están afrontando estos retos.
Soberanía operativa: cómo desarrollar resiliencia en un mundo impredecible
Para muchas organizaciones, la cuestión ya no consiste únicamente en controlar los datos, sino en mantener la capacidad de operar, adaptarse y recuperarse a medida que evolucionan las leyes y las circunstancias.
No se puede proteger una conversación con un cortafuegos: cómo el red teaming de IA se volvió esencial
Dado que las implementaciones de IA avanzan a la velocidad de las máquinas, los métodos tradicionales de prueba de software ya no resultan adecuados.
Protege tu canalización de datos de IA sin ralentizarla
Proteger el flujo de datos de la IA no es opcional. Eso está claro. Lo que resulta mucho menos evidente —y mucho más difícil— es cómo protegerlo adecuadamente.
Las extranets no están muertas; solo necesitan una actualización
Modernice su extranet: descubra cómo F5 y Equinix ofrecen una conectividad para partners repetible, segura y escalable, sin la complejidad de las redes tradicionales.