Tabla de contenidos

• El problema real: ¿Por qué el Gateway deja pasar el ataque?
• BOLA en el mundo real
• Autenticar no es Autorizar (Y muchos lo confunden)
• El mito del «Guardaespaldas Perimetral»
• Lo que sí hace tu Gateway
• Ceguera de contexto
• Los WAFs tampoco te salvarán
• Riesgos en Fintech: Perder la confianza es perder el negocio
• 1. El voyeur financiero (Open Banking)
• 2. Sabotaje operativo
• El golpe regulatorio
• Anatomía de un Ataque (Paso a Paso)
• La petición legítima
• La explotación
• Cómo arreglarlo: Mejores prácticas
• Checklist para el controlador
• Adiós a los IDs secuenciales
• Rompe tu App antes que ellos
• Tabla: Seguridad Perimetral vs. Lógica Real
• Defensa en profundidad

BOLA (Broken Object Level Authorization) no es un error de código cualquiera; es una falla lógica.* En el ecosistema Fintech, permite que un cliente autenticado espíe saldos o historiales de transacciones ajenos simplemente cambiando un dígito en la URL. Lo alarmante es que tu API Gateway es ciego ante esto. Su trabajo es verificar identidad (Autenticación), no permisos específicos sobre datos (Autorización a nivel de objeto). Pensar que la seguridad perimetral detiene BOLA es como dejar la bóveda del banco abierta solo porque el guardia de la entrada revisó el DNI del visitante.

El problema real: ¿Por qué el Gateway deja pasar el ataque?

Para entender la gravedad, olvídate de los hackers de película rompiendo firewalls con fuerza bruta. BOLA ataca el diseño, no la infraestructura.

BOLA en el mundo real

Técnicamente, BOLA sucede cuando el servidor recibe una petición para un recurso (digamos, /api/wallets/1045) y no valida si el usuario que hace la petición (identificado en el token JWT) es realmente el dueño del recurso 1045.

Es la vulnerabilidad número uno en el OWASP API Security Top 10 por una razón simple: es fácil de explotar y difícil de detectar automáticamente. En una App financiera, donde manejamos cuentas de ahorro, tarjetas y documentos KYC, no verificar la relación Usuario == Dueño del Recurso en cada llamada es una invitación al desastre.

Autenticar no es Autorizar (Y muchos lo confunden)

Aquí es donde fallan innumerables arquitecturas.

La Autenticación (AuthN) pregunta: «¿Quién eres?». El API Gateway es experto en esto. Valida la firma del token, mira la fecha de expiración, confirma que existes.

La Autorización (AuthZ) pregunta: «¿Tienes permiso para ver este documento específico?». El Gateway no tiene ni idea de lo que hay en tu base de datos. No sabe que la factura #99 es de la Empresa A y tú eres de la Empresa B. Solo ve una petición HTTP bien formada. Por eso, el tráfico malicioso entra por la puerta grande.

El mito del «Guardaespaldas Perimetral»

Existe una creencia peligrosa en DevOps: «Si ponemos Kong, Apigee o AWS API Gateway enfrente, estamos cubiertos». Falso. Esas herramientas son recepcionistas eficientes, no seguridad privada.

Lo que sí hace tu Gateway

Tu Gateway protege la disponibilidad y organiza el tráfico. Sus tareas son:

• Rate Limiting: Que nadie tumbe el servidor con 10,000 clics por segundo.
• Terminación SSL: Manejar el cifrado.
• Enrutamiento: Dirigir el tráfico al microservicio correcto.
• Validación de Esquema: Que el JSON tenga el formato correcto.

Ninguna de estas funciones entiende tu negocio.

Ceguera de contexto

Para detectar un ataque BOLA, necesitas contexto. El Gateway opera en la capa de red y aplicación (L7), pero de forma superficial.

Si un usuario pide GET /transfers/500, el Gateway piensa: «Token válido, endpoint existe, adelante». No puede (y no debe) consultar la tabla transfers en tu SQL para ver la columna user_id. Hacer eso en el Gateway acoplaría la infraestructura con la lógica, creando un monolito distribuido imposible de mantener.

Los WAFs tampoco te salvarán

Los Web Application Firewalls (WAF) buscan patrones conocidos: inyección SQL (' OR 1=1), scripts maliciosos (

Un ataque BOLA es, estructuralmente, una petición perfecta. No hay caracteres raros ni código inyectado. Es solo un ID diferente. Para un WAF, cambiar id=100 a id=101 es navegación normal. La seguridad perimetral es inútil aquí.

Riesgos en Fintech: Perder la confianza es perder el negocio

Las consecuencias aquí no son solo técnicas. Si un banco digital filtra datos, muere.

1. El voyeur financiero (Open Banking)

Imagina una App de finanzas personales.

1. El atacante entra con su cuenta real.
2. Ve su llamada API: GET /api/v1/accounts/88120/transactions.
3. Escribe un script básico para probar números cercanos: 88121, 88122.
4. El servidor responde con JSONs de salarios, gastos y ubicaciones de compras de desconocidos.

2. Sabotaje operativo

Este es más agresivo. Supongamos un endpoint para cancelar transferencias: DELETE /api/transfers/{transferId}. Sin validación, un competidor o actor malicioso podría barrer miles de IDs secuenciales y cancelar operaciones de todo el ecosistema en segundos. Caos total.

El golpe regulatorio

En Europa, la PSD2 exige autenticación fuerte. BOLA se la salta porque el usuario ya está autenticado. Bajo GDPR o leyes locales, exponer datos financieros por un error de diseño es negligencia grave. Las multas del 4% de la facturación global no son una amenaza vacía; son el estándar.

Anatomía de un Ataque (Paso a Paso)

Vamos al código. Así se ve la vulnerabilidad en vivo.

La petición legítima

El usuario A (ID: 10) consulta su préstamo.

GET /api/loans/5500 HTTP/1.1
Host: api.neobank.com
Authorization: Bearer eyJhbGciOi... (Token del Usuario A)

• Respuesta del Servidor:*

{
  "id": 5500,
  "user_id": 10,
  "amount": 5000.00,
  "status": "APPROVED"
}

La explotación

El atacante cambia el ID en la URL, buscando el préstamo 5501.

• Petición Maliciosa:*

GET /api/loans/5501 HTTP/1.1
Host: api.neobank.com
Authorization: Bearer eyJhbGciOi... (Token del Usuario A)

• Respuesta Vulnerable (Backend ciego):*

{
  "id": 5501,
  "user_id": 12,  <-- ¡DATOS DEL USUARIO B!
  "amount": 250000.00,
  "status": "PENDING"
}

El código del backend probablemente hizo un Loan.findById(5501) y devolvió el resultado. Faltó la cláusula crítica: WHERE userid = currentuser.

Cómo arreglarlo: Mejores prácticas

La solución no es comprar más hardware. Es escribir mejor código.

Checklist para el controlador

Cada endpoint que acepte un ID debe pasar por este filtro, sin excepciones:

1. Extraer el usuario del token.
2. Buscar el recurso solicitado.
3. Comparar: ¿El resource.ownerId coincide con currentUser.id?
4. Si no, devuelve 403 Forbidden o 404 Not Found (el 404 es mejor para evitar que mapeen tus datos).

Usa middleware o decoradores en tu framework (Spring Boot, NestJS, Django) para estandarizar esto. No confíes en la memoria de los desarrolladores.

Adiós a los IDs secuenciales

Deja de usar auto-incrementales (1, 2, 3) para recursos públicos. Le haces el trabajo demasiado fácil al atacante.

Implementa UUIDs (Universally Unique Identifiers) versión 4.

• Malo: /api/cards/500
• Bueno: /api/cards/a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11

Los UUIDs no solucionan BOLA (si adivino el UUID, entro), pero hacen que la adivinación sea estadísticamente imposible. Es una capa extra de ofuscación necesaria.

Rompe tu App antes que ellos

No esperes al pentesting anual. Integra pruebas de seguridad en el CI/CD. Crea tests automatizados donde el «Usuario A» intente deliberadamente acceder a los recursos del «Usuario B». Si el test obtiene datos, el build debe fallar. Herramientas como Schemathesis ayudan, pero los tests de integración personalizados son clave.

Tabla: Seguridad Perimetral vs. Lógica Real

Defensa en profundidad

El API Gateway es esencial, pero insuficiente. Creer que protege tus datos sensibles es un error de cálculo que ninguna Fintech puede permitirse. La defensa contra BOLA vive exclusivamente en la lógica de la aplicación.

Los desarrolladores son la primera y última línea de defensa. Valida la propiedad en cada acceso, oscurece tus IDs y asume siempre que el usuario autenticado puede tener malas intenciones. La seguridad real se construye capa por capa, desde el perímetro hasta la consulta SQL más pequeña.