Quand les relations de confiance deviennent un vecteur d’attaque

Pendant longtemps, une cyberattaque commençait par la recherche d’une faille : un mot de passe volé, une vulnérabilité exploitée ou un poste compromis. L’objectif était toujours le même : obtenir un premier accès au système d’information. Ce modèle existe toujours, mais il n’est plus le seul. Aujourd’hui, un nombre croissant d’attaques s’appuie sur des accès déjà autorisés. L’attaquant n’a parfois plus besoin d’exploiter une faille ou de contourner un mécanisme de sécurité. Il lui suffit de récupérer ou détourner une autorisation accordée à une application tierce. OAuth, les tokens d’accès et les intégrations SaaS sont devenus des composants indispensables des environnements cloud modernes. Ils sont aussi devenus une surface d’attaque particulièrement attractive.

L’attaquant ne cible plus seulement vos systèmes

Le changement est subtil mais fondamental. Au lieu d’attaquer directement votre environnement Microsoft 365, Google Workspace, Salesforce ou Slack, l’attaquant s’intéresse désormais aux applications tierces qui y sont connectées. La logique est simple : lorsqu’une application dispose déjà d’un accès légitime à vos données via OAuth, compromettre cette application peut permettre d’accéder aux mêmes ressources sans avoir à franchir les contrôles de sécurité habituels. Plusieurs incidents récents ont illustré ce mode opératoire.

L’affaire impliquant Salesloft et Drift a notamment montré comment la compromission d’une application SaaS pouvait conduire à l’exploitation de tokens OAuth utilisés pour accéder à des environnements clients. Les attaquants n’ont pas eu besoin de cibler directement les plateformes utilisées par les entreprises concernées. Ils ont exploité la relation de confiance déjà établie entre ces plateformes et l’application tierce. Une problématique similaire a également été observée autour de certaines applications connectées à l’écosystème Salesforce. Dans ces scénarios, les accès utilisés étaient parfaitement légitimes du point de vue des systèmes : les requêtes provenaient d’applications autorisées et s’appuyaient sur des permissions valides.

Ces attaques ne contournent pas les mécanismes de sécurité. Elles les évitent. Pour les systèmes de sécurité, l’activité paraît souvent légitime puisque les accès utilisés sont autorisés.

Pourquoi le MFA ne suffit pas

L’authentification multifacteur constitue aujourd’hui un prérequis de sécurité indispensable. Pourtant, elle ne répond pas à tous les scénarios de compromission. Le MFA protège l’utilisateur au moment de l’authentification. Il ne protège pas nécessairement les autorisations déjà déléguées à des applications. Un token OAuth est ce que l’on appelle un bearer credential. En pratique, toute personne ou tout système qui détient ce token peut l’utiliser dans les limites des permissions accordées.

Autrement dit, un attaquant qui récupère un token valide n’a généralement pas besoin du mot de passe de l’utilisateur ni de son second facteur d’authentification. Cette distinction est essentielle. Une organisation peut disposer d’un déploiement MFA exemplaire tout en restant exposée à des centaines d’autorisations OAuth dont personne ne suit réellement le cycle de vie.

Les tokens oubliés : un risque souvent invisible

L’un des principaux problèmes réside dans la durée de vie de ces accès. Une intégration mise en place pour un projet ponctuel, un outil testé quelques semaines ou une automatisation créée par un collaborateur peut continuer à fonctionner pendant des mois, voire des années, sans faire l’objet d’aucune révision. Ces accès échappent souvent aux contrôles classiques de gestion des identités. Lorsqu’un collaborateur quitte l’entreprise, son compte est généralement désactivé et ses droits sont révoqués. En revanche, les applications qu’il a connectées à son environnement professionnel peuvent continuer à disposer d’autorisations actives si aucun processus spécifique n’a été prévu pour les identifier et les supprimer. Chaque accès oublié constitue une opportunité supplémentaire pour un attaquant.

Le phishing OAuth : une attaque sans mot de passe

OAuth peut également être exploité sans qu’aucune application tierce ne soit compromise. Les campagnes dites "d’illicit consent grant" reposent sur une approche particulièrement efficace : l’attaquant crée une application qui semble légitime puis invite des utilisateurs à lui accorder des permissions. L’utilisateur reçoit une demande d’autorisation familière, similaire à celles qu’il rencontre quotidiennement lorsqu’il connecte un nouvel outil à son environnement Microsoft 365 ou Google Workspace. S’il accepte les permissions demandées, l’application obtient un accès direct aux ressources autorisées. Dans ce scénario, aucun mot de passe n’est volé, aucun malware n’est installé et aucune vulnérabilité n’est exploitée. L’utilisateur fournit lui-même l’accès à travers un mécanisme parfaitement légitime. C’est précisément ce qui rend ces attaques difficiles à détecter.

L’effet amplificateur de l’IA

L’adoption rapide des outils d’intelligence artificielle renforce encore cette problématique. Pour être réellement utiles, de nombreux assistants IA doivent accéder aux données de l’entreprise : messagerie, documents, outils collaboratifs, CRM ou plateformes de gestion de projet. Chaque nouvelle connexion génère des permissions supplémentaires, des tokens supplémentaires et de nouvelles relations de confiance entre systèmes. Cette multiplication des accès favorise l’émergence du Shadow AI : des assistants, agents et automatisations déployés sans validation formelle de la DSI ou des équipes sécurité, mais disposant parfois d’un accès direct à des données sensibles.

Le défi n’est plus seulement de gérer les utilisateurs humains. Il consiste également à maîtriser l’ensemble des identités non humaines qui interagissent quotidiennement avec les données de l’entreprise : applications, comptes de service, bots, clés API, agents IA et intégrations SaaS.

Quelles mesures mettre en place ?

L’objectif n’est évidemment pas de renoncer à OAuth ou aux intégrations SaaS. Ces mécanismes sont devenus indispensables au fonctionnement de nos organisations. En revanche, leur gouvernance doit être considérée comme un sujet de sécurité à part entière. Cela commence par une visibilité complète sur les applications connectées, les autorisations accordées et les tokens actifs.

Le principe du moindre privilège doit également être appliqué systématiquement. Une application ne devrait disposer que des droits strictement nécessaires à son fonctionnement. La durée de vie des accès doit être maîtrisée grâce à des mécanismes d’expiration, de rotation et de révocation régulière. Enfin, les procédures d’arrivée et de départ des collaborateurs doivent intégrer explicitement la revue et la suppression des autorisations OAuth associées à leur activité. Dans un environnement SaaS moderne, la gestion des tokens OAuth, des applications connectées et des identités non humaines n’est plus un sujet technique secondaire : elle constitue désormais un élément central de la stratégie de cybersécurité. Aujourd’hui, protéger les identités ne suffit plus. Il faut également maîtriser les autorisations accordées aux applications qui agissent en leur nom.