Pruebas Efectivas de Penetración de APIs en Tailandia

La mayoría de las aplicaciones dejaron de ser simples páginas web hace años. Hoy en día son redes de APIs: microservicios que invocan microservicios, clientes móviles en un extremo y pasarelas de pago en el otro. Sin embargo, muchas auditorías de seguridad tradicionales no se han actualizado: los equipos siguen contratando pruebas de penetración de aplicaciones web que consumen el 80% del esfuerzo en el frontend, mientras que las APIs subyacentes, donde realmente fluyen los datos confidenciales y el dinero, quedan prácticamente sin probar.

Por qué los escáneres automáticos fallan en las APIs #

Los escáneres web automáticos fueron diseñados alrededor del modelo de páginas web tradicionales: rastrear enlaces, encontrar formularios HTML e inyectar payloads genéricos. Las APIs no presentan páginas HTML: exponen rutas, métodos HTTP y esquemas estructurados, y los comportamientos más vulnerables residen en la lógica de negocio entre ellos.

Considera un fallo de autorización a nivel de objeto: un usuario autenticado cambia user_id=1024 por user_id=1025 en una petición y lee los registros confidenciales de otro cliente. Ninguna firma de seguridad se activa. El payload no contiene código malicioso ni inyecciones. El escáner automático ve una petición HTTP 200 normal y continúa. Esta vulnerabilidad es la Autorización Rota a Nivel de Objeto (BOLA), el riesgo número uno en el OWASP API Security Top 10, y resulta completamente invisible para casi todas las herramientas automáticas.

Ese es el argumento central para las pruebas de penetración lideradas por especialistas: las vulnerabilidades más destructivas son defectos de diseño y lógica, y encontrar defectos de diseño requiere un analista técnico que comprenda el contexto del negocio.

Qué cubre una prueba de penetración de APIs rigurosa #

Una evaluación técnica profunda va mucho más allá de ejecutar un escáner contra una especificación OpenAPI:

• Autenticación y autorización: Gestión de tokens JWT, validación de scopes y control de acceso a nivel de objeto en cada límite de roles.
• Lógica de negocio: Pruebas para verificar si un usuario puede aplicar precios negativos, reanudar callbacks de pago o saltarse pasos en un flujo de aprobación llamando directamente al endpoint final.
• Exposición excesiva de datos: Identificación de endpoints que devuelven objetos completos de base de datos en lugar de filtrar solo los campos requeridos por el cliente.
• Límites de tasa y abuso: Protección contra ataques de fuerza bruta, enumeración masiva y credential stuffing que aprovechan un control de tasa deficiente.
• Límites de integración: Webhooks, callbacks de terceros y colas de mensajería donde con frecuencia se asume la confianza sin validación criptográfica.

Por esta razón, las mejores evaluaciones combinan técnicas ofensivas manuales con reconocimiento asistido por IA: la automatización amplía la cobertura mientras que el especialista evalúa la gravedad y el contexto real.

Seguridad continua, no solo una auditoría anual #

Un pentest una vez al año es una foto fija de un sistema que despliega cambios cada semana. Para cuando se entrega el informe, los endpoints ya han cambiado. El enfoque moderno integra las comprobaciones de seguridad de APIs en el pipeline de entrega:

1. Shift-left: Análisis estático de código y validación de esquemas en CI/CD.
2. Revisiones por release: Evaluaciones focalizadas cuando cambia la superficie de la API.
3. Auditoría profunda anual: Evaluación manual exhaustiva para certificar pistas de auditoría y validar la lógica compleja que el pipeline no puede juzgar.

Tanto el Requisito 6 como el Requisito 11.4 de PCI DSS 4.0.1 exigen este nivel de rigor para organizaciones que gestionan datos de tarjetas, al igual que las directrices de seguridad en canales digitales del Banco de Tailandia.

Lo que los escáneres automáticos no pueden ver #

Es fundamental detallar qué pasa por alto la automatización, porque las brechas no son aleatorias: se concentran exactamente donde fluyen las transacciones críticas.

BOLA en la práctica. Un escáner prueba los endpoints descubiertos y los parámetros que comprende. En una API de facturación: GET /invoices/8842 devuelve la factura del propio usuario y el escáner registra un éxito. Pero GET /invoices/8843, la factura de otro cliente, podría devolverse con la misma facilidad sin que el escáner lo detecte, porque entender que 8843 pertenece a otra persona requiere comprender qué significa la propiedad en tu modelo de negocio. Cada identificador de objeto que cruza límites entre clientes es un potencial BOLA que solo un analista detectará al enumerar objetos entre cuentas.

Fallos de lógica de negocio. Los escáneres prueban si las peticiones fallan con errores; los fallos de lógica viven en peticiones que devuelven éxito cuando no deberían. Ejemplos reales de auditorías: aplicar un cupón de descuento dos veces porque la validación ocurre antes del cargo; transferir reservas entre cuentas sin re-autorización; o cancelar un pedido ya enviado porque el endpoint de cancelación nunca verifica el estado logístico. Todas devuelven HTTP 200 y generan pérdidas financieras sin ningún mensaje de error.

Suposiciones de confianza entre microservicios. Dentro de una arquitectura de microservicios, un servicio suele confiar ciegamente en encabezados o tokens internos presentados por el emisor porque en el diagrama original todos eran servicios internos. Cuando un servicio perimetral es comprometido, o cuando un endpoint interno pasa a ser alcanzable desde un segmento de red menos confiable, esa confianza heredada se convierte en una escalera para el atacante: autenticarse en el servicio perimetral débil y utilizar su identidad aguas abajo, hacia los servicios internos de alto valor. Encontrar esto requiere razonar sobre la arquitectura tal como sus diseñadores la concibieron y luego probarla como la atravesaría un atacante.

Ninguno de estos casos aparece en la salida de un escáner. Todos aparecen en informes escritos por analistas que se tomaron el tiempo de entender para qué sirve realmente su API.

Nuestra Revisión de Seguridad de Código y APIs combina análisis de código fuente con pruebas de penetración manuales, y nuestras Pruebas de Penetración cubren el perímetro y la segmentación de red. Si quieres una prueba ajustada a tu arquitectura real, reserva una Engineering & Scoping Session.