🔒 SaaS Breaches Start with Tokens – la bombe invisible des identités API

Les RSSI parlent encore de mots de passe et de MFA. Pendant ce temps, les attaquants se baladent dans les clouds d’entreprise avec des tokens volés, valides, et parfaitement “légitimes”. Bienvenue dans la nouvelle ère du token hijacking.

🧩 Le problème : les clés qui n’expirent jamais

Les entreprises adorent le SaaS. En 2025, on ne compte plus les solutions cloud dans les SI : Salesforce pour le CRM, Slack pour les échanges, GitHub pour le code, Microsoft 365 pour tout le reste.
Mais cette belle mécanique repose sur une chose fragile : des tokens d’accès.

Ces tokens OAuth ou API sont censés simplifier la vie des applications : pas de mot de passe, pas de réauthentification permanente, juste un joli jeton signé qui prouve “qui tu es”.
Sauf qu’un token, c’est un passe permanent tant qu’il n’est pas révoqué. Et la plupart du temps… il ne l’est jamais.

🧠 Petit rappel : un token OAuth, c’est comme un badge d’accès d’entreprise que personne ne désactive, même quand le salarié a quitté la boîte depuis six mois.

Salesforce vient justement d’en faire les frais : ☁️ Salesforce face aux Scattered LAPSUS$ Hunters : le cloud n’a pas flanché, mais les connexions oui

💥 Pourquoi les tokens font sauter les verrous

Les attaques modernes ne passent plus forcément par le mot de passe : elles passent par l’identité machine, les intégrations SaaS et les pipelines CI/CD.
Les tokens, eux, sont devenus la porte d’entrée royale pour une raison simple : ils ne déclenchent aucune alerte.

Quand un attaquant vole un token :

• Il peut l’utiliser depuis n’importe quel appareil sans déclencher de MFA.
• Il accède directement à l’API avec le niveau d’autorisation accordé (souvent “admin”).
• Et les journaux de connexion ne montrent rien d’anormal : tout semble “authentifié”.

⚙️ Les causes typiques :

• Tokens codés en dur dans des scripts Python, fichiers .env ou pipelines GitHub Actions.
• Tokens affichés dans les logs d’erreur (“parce que debug, c’est pratique”).
• URLs contenant des tokens dans la chaîne de requête (oui, ça existe encore).
• Permissions OAuth trop larges (“scope=full_access” parce que flemme).

Le résultat ? Une compromission silencieuse, persistante, et indétectée.

🕵️‍♂️ Quelques perles du best-of “Token Leak of Shame”

Le florilège est savoureux :

• Slack (2024) : des tokens OAuth d’apps internes exposés dans des dépôts GitHub publics, donnant accès aux canaux privés d’entreprises.
• GitHub Actions (2023–2024) : des workflows CI/CD contenant des secrets mal protégés ; vol de tokens et réutilisation pour pousser du code malveillant dans les repos internes.
• Salesforce (2024) : un partenaire intégrateur stockait des tokens d’accès dans un tableur partagé sur OneDrive. Des accès clients “full admin” ont été découverts par un pentester chanceux.
• Atlassian (2025) : fuite de tokens personnels via un bot Slack mal codé ; le bot affichait par erreur le token d’un compte Jira admin dans une conversation d’équipe.

💬 Moralité : le maillon faible n’est plus le mot de passe… c’est le développeur fatigué un vendredi soir.

🧠 Anatomie d’une attaque par vol de token

Prenons un exemple concret : une entreprise utilise GitHub Actions pour déployer automatiquement son application SaaS.
Dans le pipeline YAML, un token d’accès AWS est injecté pour déployer sur le cloud.
Un développeur un peu distrait pousse le fichier .env contenant le token sur GitHub.

🎯 Étapes de l’exploitation :

1. Un attaquant scrute GitHub avec un script qui cherche les patterns “aws_access_key_id=” ou “Bearer”.
2. Il trouve le token exposé.
3. Il l’utilise pour lister les buckets S3, récupérer le code source, ou injecter un backdoor dans l’application.
4. Le tout sans jamais casser un mot de passe, sans jamais faire un “login”.

Et quand le RSSI arrive enfin à enquêter ?
➡️ Les logs AWS indiquent “Accès légitime avec token valide”.
Pas de MFA, pas d’alerte, pas de soupçon. Juste un sourire narquois côté attaquant.

🔍 Pourquoi les tokens ne sont jamais surveillés

La plupart des solutions de sécurité se concentrent encore sur :

• les connexions interactives,
• les logs de sessions utilisateur,
• les authentifications MFA,
• et la détection d’anomalies de login.

Mais les appels API authentifiés via token passent sous le radar.
Les outils SIEM traditionnels n’agrègent pas (ou mal) les logs des API SaaS.
Résultat : un attaquant peut siphonner un compte Microsoft 365, GitHub, ou Slack sans générer un seul événement “suspect”.

🧩 Et cerise sur le gâteau : même après rotation de mot de passe, le token reste valide jusqu’à sa date d’expiration.
Certaines API laissent vivre ces tokens pendant 90 jours, voire indéfiniment.

🧼 La “token hygiene” : mission impossible ?

Pas tant que ça — mais ça demande rigueur, automatisation, et une vraie politique de gouvernance.
Voici les bonnes pratiques à marteler :

✅ 1. Rotation automatique : mettre en place un job régulier (cron, script, CI) pour régénérer les tokens toutes les 24 ou 48 h.

✅ 2. Durée de vie courte : forcer des expirations rapides (TTL = 1 jour max).

✅ 3. Scopes limités : chaque application doit avoir un accès strictement minimal (“read-only”, “restricted”).

✅ 4. Inventaire centralisé : savoir qui a généré quel token, quand et pour quoi faire.

✅ 5. Révocation systématique : quand un employé part, on révoque ses tokens avant même son badge d’entrée.

✅ 6. Journalisation complète : brancher les logs d’API dans le SIEM (Splunk, Sentinel, ELK, etc.).

✅ 7. Chiffrement local : stocker les tokens chiffrés (Vault, AWS Secrets Manager, HashiCorp, etc.).

💣 Le pire ennemi du RSSI : l’automatisation aveugle

Les pipelines DevOps, c’est merveilleux… jusqu’à ce qu’ils automatisent une compromission à la vitesse de la lumière.
Un token codé en dur dans un pipeline CI/CD, c’est une faille reproductible : chaque déploiement propagera la compromission.

Un exemple qui pique :

En 2025, une startup SaaS américaine a vu son code source volé puis modifié dans sa chaîne de déploiement.
L’attaquant avait intercepté un token GitLab stocké dans une variable CI.
Résultat : les conteneurs Docker produits contenaient un malware intégré — signé, validé et déployé par le pipeline lui-même.

Quand la compromission devient un feature, il est temps de se poser des questions.

🧰 Les solutions techniques (et pas que marketing)

• Vault + Rotation + Audit : HashiCorp Vault, AWS Secrets Manager, ou GCP Secret Manager sont vos amis.
• SSO + Consent Review : forcer une revue périodique des apps OAuth connectées au SSO.
• SIEM enrichi : ingestion et corrélation des logs API (ex. Microsoft Graph, Google Workspace, GitHub Audit).
• Token Boundary Enforcement : isoler les tokens par environnement (dev/test/prod).
• MFA contextuel : activer des politiques “step-up auth” sur accès API sensibles.

Et surtout : former les développeurs.
Parce qu’un token dans un repo, c’est rarement une erreur technique — c’est un réflexe culturel.

👉 Dans la majorité des cas (et Salesforce en est l’exemple parfait), ce n’est pas la plateforme elle-même qui est compromise, mais les applications tierces connectées via OAuth ou API.

Salesforce, Microsoft 365, Google Workspace, Slack, GitHub… tous ces géants ont des infrastructures bétonnées : patchs rapides, audits, monitoring avancé, SOC 24/7.
Mais l’écosystème d’applications qui s’y connecte, lui, est un immense gruyère d’autorisations et de tokens.

💣 Ce qui se passe concrètement :

• Une appli tierce demande à se connecter à Salesforce via OAuth (“autorisez X à accéder à vos données CRM”).
• L’utilisateur (ou pire, un admin) clique sur “Accepter”.
• Salesforce délivre un token d’accès longue durée à cette application.
• Si cette app ou son serveur se fait pirater… le token devient un passe d’accès direct à Salesforce.

Et là, c’est terminé :
pas besoin de casser un mot de passe, pas besoin de bypasser le MFA,
➡️ le token est déjà valide, et Salesforce pense parler à une application autorisée.

🧩 Cas typique :

• Une startup de marketing SaaS a une intégration “Salesforce Connector” qui synchronise les leads.
• Leurs serveurs stockent les tokens Salesforce des clients pour exécuter les synchros nocturnes.
• Un attaquant compromet leurs serveurs → il récupère des centaines de tokens Salesforce valides.
• Il accède aux CRM des entreprises clientes, en mode API authenticated.

Résultat : Salesforce n’a pas “été hacké”,
mais des centaines d’instances Salesforce sont exposées parce qu’une appli connectée a été compromise.

⚙️ Pourquoi c’est si dangereux :

• Les tokens OAuth ont souvent des scopes full_read_write.
• Ils ne sont pas liés à un device ou à un IP (→ usage indétectable).
• Et la révocation dépend du tiers (→ lente, manuelle, ou inexistante).

C’est le chaînon faible du modèle SaaS : la sécurité déportée dans des intégrations que personne ne supervise.

💬 En résumé :

Salesforce n’est pas la cible.
Salesforce est le coffre-fort qu’on ouvre avec la clé volée d’un fournisseur tiers.

C’est le même principe qu’un cambriolage dans une banque où l’alarme n’a pas sonné,
parce que le voleur avait un badge d’un sous-traitant “autorisé”.

🧨 Conclusion : les tokens, c’est le nouveau mot de passe

“Ce n’est pas ton compte qui s’est fait pirater, c’est ton application connectée.”
Voilà la phrase qu’on entendra de plus en plus souvent.

En 2025, le vrai front de la cybersécurité ne se trouve plus dans le pare-feu, ni même dans l’authentification utilisateur.
Il est dans les intégrations SaaS : ces passerelles invisibles entre outils, où un simple token compromis ouvre les portes d’un empire.

Alors oui, continuez à parler MFA, DLP et antivirus…
Mais pendant ce temps, vos tokens vivent leur meilleure vie, libres et dangereux.

💬 Moralité : dans le monde du SaaS, la vraie hygiène ne passe plus par les mots de passe, mais par le savon des tokens.🧼🔑

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com