El robo de tokens es una de las principales causas de las infracciones de SaaS. Descubra por qué los tokens de OAuth y API a menudo se pasan por alto y cómo los equipos de seguridad pueden fortalecer la higiene de los tokens para prevenir ataques.
En 2025, la mayoría de las empresas dependerán de una amplia gama de aplicaciones de software como servicio (SaaS) para ejecutar sus operaciones. Sin embargo, la seguridad de estas aplicaciones depende de pequeños datos llamados tokens. Los tokens, como los tokens de acceso de OAuth, las claves API y los tokens de sesión, funcionan como claves para estas aplicaciones. Si un ciberdelincuente consigue uno, puede acceder a los sistemas relevantes sin muchos problemas.
Las violaciones de seguridad recientes han demostrado que un solo token robado puede eludir la autenticación multifactor (MFA) y otras medidas de seguridad. En lugar de explotar las vulnerabilidades directamente, los atacantes aprovechan el robo de tokens. Es una preocupación de seguridad que se relaciona con el problema más amplio de la expansión de SaaS y la dificultad de monitorear innumerables integraciones de terceros.
Infracciones recientes que involucran robo de tokens
Muchos eventos del mundo real nos muestran cómo los tokens robados pueden provocar violaciones de seguridad en entornos SaaS:
1. Slack (enero de 2023). Los atacantes robaron varios tokens de empleados de Slack y los usaron para obtener acceso no autorizado a los repositorios de códigos privados de GitHub de Slack. (No se expusieron datos de clientes, pero fue una advertencia clara de que los tokens robados pueden socavar las barreras de seguridad internas).
2. Circleci (enero de 2023). El malware que roba información en la computadora portátil de un ingeniero permitió a los actores de amenazas secuestrar tokens de sesión para los sistemas de CircleCI. Esos tokens dieron a los atacantes el mismo acceso que el usuario, incluso con MFA implementado, lo que les permitió robar secretos de clientes de la plataforma CI.
3. Cloudflare/Okta (noviembre de 2023). A raíz de una violación del proveedor de identidad, Cloudflare rotó alrededor de 5.000 credenciales. Sin embargo, un token API no rotado y algunas credenciales de cuenta de servicio fueron suficientes para que los ciberdelincuentes comprometieran el entorno Atlassian de Cloudflare. Este incidente demostró cómo un solo token olvidado puede socavar una respuesta al incidente que de otro modo sería exhaustiva.
4to Techo de Ventas/Operación (agosto 2025). El chatbot Drift (propiedad de Salesloft) sufrió una violación de la cadena de suministro que permitió a los atacantes recolectar tokens OAuth para integraciones como Salesforce y Google Workspace. Utilizando esos tokens robados, accedieron a los datos SaaS de cientos de organizaciones de clientes. Este abuso del token OAuth permitió a los atacantes acceder lateralmente a correos electrónicos, archivos y registros de soporte entre plataformas.
La expansión de SaaS alimenta los puntos ciegos de los tokens
¿Por qué siguen ocurriendo estas infracciones basadas en tokens?
El problema es más grande que cualquier aplicación individual: es un problema del ecosistema impulsado por el uso generalizado de SaaS y las relaciones de confianza de tokens ocultos entre aplicaciones.
Hoy en día, todos los departamentos aprovechan las herramientas SaaS y las integran en todos los sistemas. Los empleados utilizan múltiples servicios en la nube de terceros y las empresas administran aproximadamente 490 aplicaciones en la nube, muchas de las cuales no están autorizadas o no están protegidas adecuadamente.
Este elevado uso de SaaS (a menudo llamado expansión de SaaS) significa una explosión de tokens OAuth, claves API y conexiones de aplicaciones. Cada integración introduce una identidad no humana (esencialmente una credencial) que generalmente no es visible para TI ni rastreada por las soluciones tradicionales de administración de identidades.
El resultado general de esto es una superficie de ataque ingobernable. Generalmente, algunos factores contribuyen a este punto ciego:
• Falta de visibilidad. Muchas organizaciones no conocen realmente todas las aplicaciones e integraciones SaaS que sus empleados han habilitado, ni quién las autorizó. La TI en la sombra (empleados que agregan aplicaciones sin aprobación) florece y los equipos de seguridad solo pueden descubrir una conexión OAuth después de que haya creado un problema.
• Sin aprobación ni supervisión. Sin un proceso de investigación, los usuarios pueden conectar libremente aplicaciones como complementos de marketing o herramientas de productividad a cuentas SaaS corporativas. Estas aplicaciones de terceros a menudo solicitan permisos amplios y los obtienen, incluso si sólo son necesarios temporalmente. Las aplicaciones no revisadas y con demasiados privilegios pueden permanecer conectadas indefinidamente si nadie las revisa.
• No hay seguimiento regular. Muy pocas empresas imponen configuraciones de seguridad en las integraciones de OAuth o observan estas conexiones en tiempo real. Los tokens rara vez tienen una vida útil corta o un alcance estricto de forma predeterminada, y las organizaciones a menudo no limitan su uso por IP o dispositivo. Es posible que los registros de las integraciones de SaaS tampoco se incluyan en el monitoreo de seguridad.
Por qué Legacy Security no detecta el problema de los tokens
Como tal, las herramientas de seguridad tradicionales no han solucionado completamente este problema.
El inicio de sesión único (SSO) y la autenticación multifactor protegen los inicios de sesión de los usuarios, pero los tokens OAuth eluden estos controles. Otorgan confianza persistente entre aplicaciones sin necesidad de verificación adicional.
Un token actúa en nombre de un usuario o servicio sin necesidad de contraseña, por lo que un atacante que obtenga un token válido puede acceder a los datos de la aplicación conectada como si ya estuviera autenticado. No aparece ninguna ventana emergente para volver a verificar MFA cuando se utiliza un token de OAuth. Como resultado, sin una supervisión especial, los tokens OAuth y API se han convertido en el talón de Aquiles de la seguridad SaaS. Otras soluciones heredadas, como los agentes de seguridad de acceso a la nube, se centran en el tráfico de usuario a aplicación y no monitorean estas conexiones de aplicación a aplicación.
Esta brecha ha llevado a la llegada de plataformas de seguridad SaaS dinámicas que tienen como objetivo descubrir y asegurar integraciones SaaS en medio de la expansión de SaaS. Estas plataformas intentan mapear todas las aplicaciones, tokens y privilegios de terceros en uso, devolviendo visibilidad y control. Ya sea mediante el descubrimiento automatizado (escaneo de aplicaciones conectadas) o la aplicación de políticas sobre el uso de OAuth, el objetivo es cerrar la brecha de seguridad de SaaS creada por tokens no controlados.
Al final del día, cada organización, con o sin nuevas herramientas, puede aplicar mejores prácticas de higiene de tokens. No puedes proteger lo que no puedes ver. El primer paso es saber dónde están sus tokens y sus integraciones SaaS. El siguiente es controlarlos y monitorearlos para que no se conviertan en puertas traseras.
Lista de verificación de higiene de tokens
La siguiente lista de verificación se puede utilizar para reducir el riesgo de comprometer el token:
| Práctica | Acción | Y/N |
|---|---|---|
| Mantener el inventario de aplicaciones OAuth | Descubra y rastree todas las aplicaciones de terceros conectadas a sus cuentas SaaS. Mantenga un inventario actualizado de tokens OAuth, claves API e integraciones. Esto proporciona visibilidad de su huella simbólica. | |
| Hacer cumplir la aprobación de la aplicación | Establecer un proceso de investigación de antecedentes para nuevas integraciones de SaaS. Exija una revisión de seguridad o la aprobación del administrador antes de que los empleados otorguen acceso OAuth a sus cuentas. Esto frena las aplicaciones no examinadas y garantiza que cada token emitido sea necesario y conlleva riesgos conocidos. | |
| Fichas de privilegio mínimo | Limite el alcance y los permisos de los tokens al mínimo requerido. Evite otorgar un acceso demasiado amplio («permitir todo») al autorizar una aplicación. Por ejemplo, si una aplicación solo necesita acceso de lectura, no le otorgue privilegios de administrador de lectura y escritura. El privilegio mínimo reduce el impacto si se roba un token. | |
| Rotar tokens regularmente | Trate los tokens de larga duración como credenciales que caducan. Configure los tokens para que caduquen después de un corto período, si es posible, o revoquelos y vuelva a emitirlos periódicamente. La rotación regular (o una vida útil corta) significa que un token robado rápidamente se volverá inútil, lo que reducirá la ventana de oportunidad del atacante. | |
| Eliminar o alertar sobre tokens no utilizados | Identifique tokens y conexiones de aplicaciones que no se hayan utilizado en semanas o meses. Los tokens no utilizados son amenazas latentes: revocarlos si no son necesarios. Implemente alertas o informes para tokens inactivos para que puedan limpiarse de manera proactiva, evitando que las credenciales olvidadas permanezcan indefinidamente. | |
| Monitorear la actividad del token | Habilite el registro y la supervisión del uso de tokens en sus plataformas SaaS. Esté atento a actividades de tokens inusuales, como una integración que normalmente no se utiliza y que de repente realiza grandes solicitudes de datos o accede desde ubicaciones extrañas. Configure alertas para anomalías en el uso de tokens (por ejemplo, un aumento en las llamadas a la API o el uso de un token de una IP desconocida). | |
| Integrar tokens en la salida | Cuando los empleados se van o cuando se retira una aplicación de terceros, asegúrese de que sus tokens y claves de acceso se revoquen de inmediato. Haga de la revocación de tokens un paso estándar en la baja de usuarios y la gestión del ciclo de vida de las aplicaciones. Esto evita que las credenciales antiguas persistan cuando ya no sean necesarias. |