Vulnerabilidades más comunes en aplicaciones SaaS y cómo detectarlas
Por el equipo de QuantumSec
Las aplicaciones SaaS tienen una superficie de ataque diferente a la de una aplicación web tradicional. Sirven a múltiples clientes sobre la misma infraestructura, exponen APIs complejas, gestionan suscripciones y permisos, e integran decenas de servicios externos. Estas características generan vulnerabilidades específicas que los scanners automáticos raramente detectan y que requieren pentesters que entiendan el modelo de negocio del producto.
IDOR y fallos de aislamiento multi-tenant
El Insecure Direct Object Reference (IDOR) es la vulnerabilidad más frecuente en SaaS. Ocurre cuando un endpoint acepta un identificador sin verificar que el usuario autenticado tiene permiso para acceder a ese recurso concreto. En un SaaS multi-tenant, un IDOR puede dar acceso a los datos de otro cliente: documentos, registros de actividad, información de facturación o configuración interna. Ejemplo: GET /api/invoices/12345 devuelve la factura del cliente 12345 aunque el token pertenece al cliente 67890. Este fallo puede explotarse de forma masiva mediante enumeración de IDs.
Tokens JWT débiles o mal configurados
Los tokens JWT son el mecanismo de autenticación estándar en SaaS, pero su implementación incorrecta genera vulnerabilidades críticas. Los fallos más frecuentes: uso del algoritmo "none" (token sin firma verificada), secretos débiles o predecibles en HS256, ausencia de validación del campo "exp" (tokens que no caducan), falta de validación de "aud" que permite reutilizar tokens entre microservicios, y tokens con claims excesivos que revelan información interna. Un JWT con algoritmo débil puede ser falsificado para impersonar a cualquier usuario, incluyendo administradores.
Mass assignment en APIs REST
El mass assignment ocurre cuando la API acepta campos adicionales no esperados en el body de una petición y los aplica directamente al modelo de datos. Si el endpoint PATCH /api/users/{id} acepta un campo "role": "admin" no previsto, un atacante puede escalar sus privilegios simplemente incluyendo ese campo en la petición. Este fallo es especialmente frecuente en SaaS construidos con frameworks como Rails, Django REST Framework o NestJS donde la serialización automática puede exponer campos no permitidos.
Broken function-level authorization
En SaaS con múltiples planes de precios, algunas funciones deberían estar restringidas a ciertos planes. El broken function-level authorization ocurre cuando la interfaz oculta estas funciones para usuarios del plan básico, pero los endpoints de API no validan el plan del tenant. Un usuario del plan Starter puede llamar directamente a endpoints de funcionalidades del plan Enterprise si el control de acceso está solo en el frontend. También afecta a rutas de administración que asumen que solo el admin las conoce pero no implementan verificación de rol en el backend.
Webhooks sin validación de firma
Los webhooks son un vector de ataque frecuentemente ignorado en SaaS. Sin validar la firma HMAC del payload, un atacante puede enviar eventos falsificados para desencadenar acciones (marcar un pago como completado), interceptar webhooks y extraer datos sensibles entre clientes, o saturar el sistema con webhooks falsos. Stripe, GitHub y la mayoría de plataformas maduras firman sus webhooks. Tu SaaS también debería validar la firma antes de procesar cualquier evento entrante.
Exposición de datos en APIs GraphQL
GraphQL introduce riesgos específicos que REST no tiene. Los más críticos en SaaS: introspección habilitada en producción (expone todo el schema), queries sin límite de profundidad o complejidad (ataques de denegación de servicio), field-level authorization ausente (un campo privado en la UI es accesible via query directa), y batching de queries que permite ejecutar miles de operaciones en una sola petición. El IDOR también aplica en GraphQL: si el resolver no verifica la propiedad del nodo consultado, un usuario puede acceder a datos de otros tenants.
Secretos y credenciales expuestos
Es frecuente encontrar en SaaS: claves de API de terceros en respuestas de endpoints (Stripe keys, SendGrid API keys, AWS credentials), secretos hardcodeados en el frontend (en archivos JS del bundle), tokens internos en mensajes de error o logs accesibles, y URLs firmadas de S3 con TTL excesivamente largo. Estos fallos son especialmente graves porque suelen dar acceso a toda la infraestructura de la empresa, no solo a los datos de un tenant.
Lógica de billing y suscripciones manipulable
La lógica de negocio del billing es un área crítica y específica del SaaS. Vulnerabilidades típicas: race conditions en la actualización de planes (downgradear mientras se consume un recurso premium), bypass de límites de uso por manipulación de contadores, acceso a funcionalidades del plan superior durante el período de gracia tras una cancelación, y validación de descuentos o cupones manipulable para obtener suscripciones gratuitas. Estas vulnerabilidades tienen impacto económico directo y son difíciles de detectar con herramientas automáticas.
FAQ
¿Cómo sé si mi SaaS tiene vulnerabilidades de aislamiento multi-tenant?
La forma más fiable es contratar un pentesting especializado en SaaS donde el equipo simule ser dos clientes diferentes e intente acceder a los datos de uno desde la cuenta del otro. Como medida previa, puedes revisar manualmente que todos tus endpoints validan que el recurso solicitado pertenece al tenant autenticado, no solo que el usuario está autenticado.
¿Los scanners automáticos detectan estas vulnerabilidades?
La mayoría no. Los scanners DAST detectan bien vulnerabilidades de inyección (SQLi, XSS) y configuraciones inseguras. Pero los fallos de lógica de negocio, el IDOR entre tenants, la manipulación de billing y los problemas de autorización a nivel de función requieren un pentester que entienda el producto y pruebe manualmente flujos específicos del negocio.
¿Con qué frecuencia debería hacer un pentesting en mi SaaS?
El estándar del sector para SaaS es al menos una vez al año, y adicionalmente ante cambios mayores en la arquitectura, autenticación o billing. Si estás en proceso de certificación SOC 2 Tipo II o ISO 27001, el pentesting anual suele ser un requisito explícito.