Pentest de caja gris (grey box): guía para SaaS y fintech

El pentest de caja gris — o grey box (también escrito gray box) — es la modalidad en la que el investigador de seguridad recibe credenciales y documentación básica del sistema antes de empezar. Normalmente: dos cuentas de prueba en tenants distintos (esenciales para las pruebas cross-tenant), una descripción de alto nivel de la arquitectura, la documentación de la API (Swagger/OpenAPI/esquema GraphQL, si existe) y la lista de flujos críticos del producto.

Es el punto de equilibrio entre las tres modalidades: ni el tiempo perdido en reconocimiento que caracteriza a la caja negra (black box), ni la carga de revisión de código y preparación del entorno de la caja blanca (white box). Por eso ocupa ~60% del mercado en una distribución típica y es la opción por defecto de la mayoría de los pentests serios en SaaS B2B y fintech.

Esta guía explica a fondo qué es la caja gris en 2026, cómo funciona en la práctica, cuándo contratarla, cuándo NO, y cómo se compara con la caja negra y la caja blanca.

Qué es un pentest de caja gris, en una definición

El pentest de caja gris es la simulación controlada de un ataque por parte de alguien que tiene algún nivel legítimo de acceso al sistema: un cliente regular, un exempleado con credenciales todavía válidas o un atacante externo que consiguió una credencial filtrada o comprada. El investigador recibe cuentas de prueba y la documentación del alcance y, a partir de ahí, simula lo que ese perfil de atacante puede hacer con el privilegio que tiene.

Como la caja gris parte desde dentro del perímetro autenticado, cubre exactamente lo que la caja negra no ve: todo lo que está detrás del login. En un SaaS B2B típico, eso representa el 80–90% de la complejidad técnica y de la superficie de riesgo real — porque la mayoría de los bugs costosos (BOLA cross-tenant, BFLA, race conditions en transacciones, lógica de negocio rota) solo aparecen con varias cuentas autenticadas probando en paralelo.

Diferencias rápidas: grey box vs. black box vs. white box

Para ubicar dónde encaja la caja gris dentro del espectro de las tres modalidades:

Para profundizar en la caja negra, consulta Pentest de caja negra (black box): guía 2026 para SaaS y fintech. Para la visión comparativa completa, que también cubre la caja blanca, consulta Pentest de caja negra, gris o blanca: cuál elegir en 2026.

Cómo funciona la caja gris en la práctica: metodología

La gran diferencia frente a la caja negra es estructural: el investigador no pierde tiempo descubriendo qué existe — recibe el mapa. Eso libera casi todo el presupuesto de horas para la explotación activa. Las 4 fases:

Fase 1 — Configuración con credenciales y mapeo (5–10% del proyecto)

El investigador recibe las credenciales (idealmente dos cuentas en tenants distintos, más una cuenta admin del tenant principal para probar la escalada de privilegios), la documentación del alcance, el OpenAPI/Swagger y el diagrama de arquitectura. Configura el entorno de prueba, valida que las credenciales funcionen y mapea el universo de endpoints autenticados que va a cubrir.

• Validación de las cuentas: confirma el alcance (roles, permisos, tenants asignados)
• Mapeo de la API autenticada: enumeración vía Swagger + descubrimiento de endpoints no documentados mediante crawling + análisis del tráfico de la app
• Configuración de la captura del tráfico HTTP: Burp Suite, Caido o ZAP funcionando como proxy para una captura sistemática
• Preparación de las cuentas en paralelo: la prueba cross-tenant exige que las dos identidades tengan la sesión iniciada al mismo tiempo, en sesiones distintas

En la caja negra, esta fase consumiría el 40–60% del proyecto. En la caja gris, el 5–10%. Esa diferencia no se desperdicia: se va a una explotación más profunda.

Fase 2 — Validación de la autorización y del aislamiento entre tenants (30–40%)

Esta es la fase en la que brilla la caja gris. El investigador, con dos cuentas en tenants distintos, prueba sistemáticamente la autorización de cada endpoint:

• BOLA cross-tenant — en cada endpoint que recibe un ID/UUID, intentar acceder a un objeto del otro tenant cambiando el ID. Aparece en ~85% de los SaaS B2B brasileños que auditamos
• BFLA (Broken Function Level Authorization) — intentar llamar endpoints administrativos con el token de un usuario regular, endpoints de otro tenant con privilegios cruzados, flujos de aprobación saltándose pasos
• BOPLA (Broken Object Property Level Authorization) — en endpoints que aceptan actualizaciones parciales, intentar modificar propiedades sensibles (role, plan, tenant_id, is_admin, billing_status)
• Mass assignment — en endpoints de creación/actualización, inyectar en el body campos extra que el cliente no debería poder editar
• Escalada de privilegios vertical — un usuario regular que intenta volverse admin manipulando cookies, JWT o parámetros de URL, o abusando de los flujos de gestión de perfil
• Escalada de privilegios horizontal — un usuario del tenant A que logra leer/editar datos específicos del tenant B (recursos, archivos, contratos, configuraciones)

En conjunto, estos patrones representan los 5 primeros puestos del OWASP API Security Top 10 en 2026 — y ninguno es detectable por un escáner automatizado. Consulta el detalle en BOLA, BOPLA y BFLA: las 3 fallas que dominan las APIs en 2026.

Fase 3 — Explotación de la lógica de negocio interna (35–45%)

Con la autorización y el aislamiento validados, el foco pasa a la lógica de negocio, donde viven los bugs más costosos de las fintechs y los SaaS B2B:

• Race conditions en endpoints financieros (reembolso, retiro, transferencia, anticipo, rescate), cupones de un solo uso, aprobación de transferencias, cambio de plan, bypass de MFA mediante una race en el OTP
• Manipulación de flujos de varios pasos — saltarse etapas del flujo de compra/registro/aprobación, manipular el estado para llegar a las pantallas finales sin pasar por los controles intermedios
• Abuso de la facturación — manipular cupones, descuentos, número de licencias (seats), downgrade después del cobro, race de doble upgrade
• Webhooks y callbacks — SSRF en endpoints donde el cliente configura la URL del webhook (el atacante apunta a la metadata interna, movimiento lateral)
• JWT en uso autenticado — algorithm confusion, kid path traversal, sesión eterna por un exp ignorado, scope escalation, reutilización de tokens entre contextos
• Cache poisoning autenticado — flujos en los que una caché compartida entre tenants o usuarios puede envenenarse para servir datos de otro

Fase 4 — Encadenamiento y demostración del impacto (10–20%)

Con los bugs individuales mapeados, el investigador encadena lo que tenga sentido para demostrar el impacto máximo: BOLA + BFLA juntos se convierten en la toma total de un tenant; una race en reembolsos + BOPLA en el endpoint de saldo se convierte en drenaje de fondos; JWT algorithm confusion + reutilización de scope se convierte en admin maestro. Esta fase es lo que diferencia “encontró un BOLA” de “BOLA + BFLA + lógica de saldo = $X expuestos”: el contexto que se traduce en una priorización correcta en el equipo de ingeniería.

Lo que la caja gris cubre bien

1. Autorización entre tenants (BOLA cross-tenant)

El caso de uso clásico de la caja gris. Con dos cuentas en tenants distintos funcionando en paralelo, el investigador prueba cada endpoint de la API de forma sistemática, intercambiando IDs entre las cuentas. Un escáner no lo hace (necesita varias sesiones coordinadas), la caja negra no lo logra (cubre una sola cuenta) y una auditoría de checklist no lo detecta (no simula el ataque). La caja gris es prácticamente la única forma de validarlo de manera adversarial.

2. Lógica de negocio interna autenticada

Todo el flujo financiero autenticado — reembolso, retiro, anticipo, transferencia, facturación, cupones — entra en la caja gris. Incluso un investigador externo que prueba como cliente real puede encontrar race conditions, manipulación de parámetros y ataques de downgrade. La caja blanca detecta estos bugs leyendo el código, pero la caja gris los detecta ejecutando el sistema como lo ejecuta un atacante real — incluidos los bugs que aparecen en producción pero no son visibles en el código fuente (problemas de infraestructura, configuración, timing).

3. APIs internas y endpoints no documentados

En un SaaS B2B típico, la documentación cubre el 60–70% de los endpoints. El resto: endpoints internos para el frontend, endpoints administrativos olvidados, endpoints v1/v2 en paralelo, endpoints de jobs en segundo plano. La caja gris descubre esos endpoints analizando el tráfico (Burp como proxy del frontend autenticado) y prueba cada uno. La caja negra no llega ahí. La caja blanca los ve en el código, pero puede no evaluar su comportamiento en tiempo de ejecución.

4. Escalada de privilegios horizontal y vertical

Probar si un usuario regular se convierte en admin (vertical) y si un usuario del tenant A accede a recursos del tenant B (horizontal) exige ejecutar flujos autenticados con varias identidades — exactamente lo que configura la caja gris. En este vector, muchos pentests de caja negra se quedan en la superficie y dan la impresión de que todo está “limpio”, mientras que la caja gris revela los problemas reales.

5. Encadenamiento con credenciales

Las cadenas internas — combinar BOLA + BFLA + una race en un flujo financiero para demostrar el impacto encadenado — son naturales en la caja gris, porque el investigador tiene el contexto necesario para armar la secuencia. Es el tipo de hallazgo que genera una priorización correcta en el equipo de ingeniería: cada eslabón por separado es “medio”, pero la cadena completa es crítica.

Lo que la caja gris NO cubre

Reconocimiento externo profundo

Subdominios olvidados, instancias de staging expuestas, paneles administrativos legacy en direcciones no documentadas, filtraciones en GitHub, S3 público: todo eso es territorio de la caja negra, no de la caja gris. El cliente entrega el alcance y el investigador lo respeta. Si algo importante está fuera del alcance documentado, la caja gris no lo va a descubrir.

Bugs que exigen leer el código

Patrones clásicos que solo son detectables con acceso al código fuente: una race condition sutil en una región poco obvia del código, deserialización insegura en parsers internos, PHP Object Injection, gadgets de explotación en librerías cargadas, patrones problemáticos de uso del ORM (queries sin tenant_id), TOCTOU en flujos de aprobación. La caja blanca detecta todo eso. La caja gris solo detecta lo que se manifiesta en un comportamiento observable desde afuera.

Configuraciones de infraestructura

Permisos de IAM excesivos, buckets S3 mal configurados (que no están expuestos públicamente), seguridad de contenedores, segmentación de la red interna, secrets en variables de entorno: todo eso requiere acceso directo a la infraestructura. La caja gris solo ve lo que está detrás de la API autenticada, no la capa que hay debajo.

Cobertura completa para una auditoría formal

Para SOC 2 Type II, ISO 27001, PCI DSS Level 1 o las exigencias del BACEN (Banco Central de Brasil), las auditorías formales suelen exigir una combinación de caja gris + caja blanca en las áreas críticas. La caja gris sola no alcanza. En esta categoría, programa ambas modalidades al menos una vez al año.

Cuándo contratar un pentest de caja gris

1. SaaS B2B consolidado en producción

Es el caso de uso por excelencia. Un SaaS B2B con una base de clientes activa, varios tenants y flujos autenticados ricos: la caja gris es la opción que devuelve más cobertura efectiva por dólar invertido. Si ya estás en producción y todavía no pasaste por una caja gris, ese es el primer pentest que debes contratar.

2. Fintech con flujos financieros internos

Toda la complejidad financiera de una fintech (tarjeta, cuenta digital, transferencias, anticipos, rescates, facturación, cupones, vouchers) es autenticada y vive detrás del login. La caja gris es prácticamente la única forma de validar esos flujos de manera adversarial. Para una fintech, la caja gris es casi obligatoria antes de cada release importante.

3. Auditoría de autorización multi-tenant

Cuando el objetivo específico es validar el aislamiento entre tenants — antes de cerrar un contrato enterprise grande, antes de una auditoría de un cliente, antes de anunciar una funcionalidad multi-organización —, el modelo es una caja gris enfocada en BOLA/BFLA. Puede ser un proyecto específico de 40–60 h, más barato y directo que una caja gris amplia.

4. Antes de una due diligence y en M&A

En procesos de venta de la empresa o de levantamiento de capital de Serie A en adelante, los inversionistas exigen evidencia de un pentest serio. La caja gris genera un informe técnico lo bastante denso para satisfacer la due diligence sin necesidad de abrir el código (algo que muchas empresas prefieren evitar antes de firmar el term sheet).

5. Después de grandes cambios de arquitectura

Migración de un monolito a microservicios, cambio del stack de autenticación (pasar de sesiones a JWT, o al revés), implementación de un RBAC nuevo, cambio del modelo de tenancy: cualquier cambio que altere las fronteras de autorización exige una caja gris enfocada. En esas transiciones aparecen bugs nuevos.

Cuándo NO contratar caja gris

1. Cuando el objetivo es validar solo la superficie externa

Reconocimiento profundo, descubrimiento de subdominios olvidados, validación de la exposición externa: la caja negra es estructuralmente mejor para eso. La caja gris parte del alcance documentado y no busca fuera de él.

2. Cuando tienes presupuesto para la máxima profundidad técnica

Si el presupuesto lo permite, la caja blanca devuelve una cobertura del 85–95% por un precio apenas ~40% superior al de la caja gris. En las áreas críticas — módulo de transacciones financieras, núcleo de autenticación, API de facturación —, la caja blanca es matemáticamente más eficiente en hallazgos por dólar invertido, siempre que te sientas cómodo compartiendo el código.

3. Cuando necesitas una certificación formal exigente

SOC 2 Type II, ISO 27001, PCI DSS Level 1, exigencias del BACEN para instituciones de pago: la caja gris sola suele quedar por debajo del umbral de evidencia que pide el auditor. Combínala con caja blanca en las áreas críticas para generar el paquete completo de evidencia.

Cuánto cuesta un pentest de caja gris en 2026

Como referencia, estos son los rangos del mercado brasileño para SaaS B2B y fintechs pyme:

• Caja gris enfocada (40–60 h): R$ 14.000 – R$ 22.000 — alcance específico (p. ej.: solo BOLA cross-tenant, solo el flujo de facturación, solo una API crítica). Adecuada para validaciones puntuales o para el retest después de las correcciones.
• Caja gris estándar (60–80 h): R$ 20.000 – R$ 34.000 — alcance amplio de un SaaS B2B típico, cobertura de autorización + lógica de negocio + flujos financieros + APIs autenticadas, informe técnico + ejecutivo. Es el proyecto estándar de la mayoría de los pentests serios.
• Caja gris extendida (120 h+): R$ 36.000 – R$ 58.000+ — fintech con flujos complejos, SaaS multiproducto, plataformas con varios roles y tenants en capas, o una caja gris anual amplia que cubre toda la aplicación.

Para rangos por tamaño y sector, consulta Cuánto cuesta un pentest en Brasil en 2026 y Cuánto cuesta un pentest según el tamaño del SaaS B2B en 2026.

Cómo combinar la caja gris con la caja negra y la caja blanca

La combinación típica que vemos en SaaS B2B brasileños maduros:

• Anual: caja blanca completa sobre los módulos críticos (núcleo de autenticación, financiero, facturación)
• Trimestral: caja gris amplia enfocada en autorización + lógica de negocio (este es el ritmo estándar de la mayoría)
• Mensual/bimestral: caja negra liviana sobre la superficie externa (para capturar cómo va cambiando la superficie con el tiempo)

Esta cadencia alcanza ~85% de cobertura efectiva a lo largo del año, con un costo total significativamente menor que el de 4 pentests de caja blanca trimestrales. La clave: la caja gris es la columna vertebral del programa de pentest continuo, no un evento único. La caja blanca es la profundización periódica. La caja negra captura los cambios entre ciclos.

Qué hacer ahora

1. Mide qué porcentaje de tu aplicación está detrás de la autenticación. Si es > 60% (lo típico en SaaS B2B/fintech), la caja gris devuelve más ROI que la caja negra.
2. Haz una lista de los roles y tenants que quieres cubrir. Cuanto más variados, más valor genera una caja gris bien hecha (multi-tenant + varios roles = más cadenas por probar).
3. Confirma si tienes un entorno de staging dedicado para el pentest. La caja gris en producción es viable, pero más riesgosa; lo ideal es un entorno equivalente y aislado.
4. Considera la cadencia: una caja gris recurrente es significativamente más valiosa que una sola al año. Trimestral es el ritmo más común en las empresas maduras.

Para entender la hoja de ruta completa de seguridad en SaaS, consulta seguridad para SaaS. Para el alcance técnico específico del pentest, consulta pentest para SaaS. Para fintech, consulta pentest para fintech.

Otras guías de la serie: pentest de caja negra y la comparación de las tres modalidades, que también cubre la caja blanca.

Si ya quieres pasar a la acción: solicita un pentest. NDA bilateral en 24h.