Sécurisez votre système MCP : 11 risques courants et comment s’en protéger

Les risques liés au MCP se répartissent globalement en trois catégories : la manipulation des LLM, la sécurité des données et des accès, et les vulnérabilités de l’infrastructure.

Comme les serveurs MCP donnent souvent accès à un large éventail de systèmes internes, le risque de sécurité potentiel est élevé. Sa probabilité dépend toutefois fortement de la configuration.

Les particuliers comme les entreprises peuvent prendre de nombreuses mesures pour protéger leurs systèmes, et les protocoles doivent toujours être proportionnés aux capacités et aux données que les serveurs MCP connectés sont susceptibles d’exposer.

Qu’est-ce que le MCP et la sécurité MCP ?

Le Model Context Protocol (MCP) est un standard ouvert créé par Anthropic pour connecter des applications basées sur des LLM (ou hôtes) à des systèmes externes.

Un système MCP repose sur trois composants principaux : l’hôte, le client et le serveur. L’hôte, souvent un assistant IA, se connecte à un serveur MCP externe par l’intermédiaire d’un client. Il peut alors envoyer des requêtes pour exécuter des fonctionnalités externes (outils), ou récupérer des données (ressources) ou des prompts à ajouter à la fenêtre de contexte du LLM.

Agrandir

La sécurité MCP désigne les protocoles qui protègent les connexions et les composants d’un système MCP. Plusieurs défis majeurs sont propres au MCP, notamment le fait que les applications d’IA disposent souvent de capacités agentiques et que des instructions malveillantes peuvent être intégrées dans les messages.

Des problèmes bien connus qui ne sont pas propres au MCP, comme l’injection de prompt, une authentification faible et des intégrations tierces non sécurisées, posent également problème. Comme tout système informatique, le MCP s’appuie, pour sa protection, sur un ensemble de protocoles procéduraux, comme le fait de n’utiliser que des serveurs de confiance, et de contrôles techniques, comme les passerelles d’API.

Quelle est la gravité des menaces liées au MCP ?

Le MCP est rapidement devenu une technologie LLM populaire, utilisée par de nombreuses organisations et applications grand public. Comme les serveurs MCP sont des programmes écrits en code, ils présentent des vulnérabilités comme n’importe quelle autre application.

Cependant, lorsque les organisations utilisent le MCP dans des déploiements maîtrisés, il est généralement sûr. Il existe un écart considérable entre la création d’un système reposant sur des serveurs de confiance et des permissions vérifiées, et le branchement d’un agent autonome à une dizaine de serveurs non contrôlés.

Menace n° 1 : injection de prompt indirecte

Un attaquant peut placer des instructions destinées au LLM dans un document, une page web ou une sortie d’outil renvoyée par un serveur MCP. Si l’hôte ajoute ce contenu à la fenêtre de contexte, il est possible que le LLM le prenne pour de véritables instructions.

De plus, ces instructions peuvent sembler appropriées à première vue. Par exemple, un ticket d’assistance récupéré pourrait demander au LLM d’exporter des dossiers clients sensibles avant de générer une réponse.

Comment se protéger contre l’injection de prompt indirecte

Les injections de prompt doivent généralement être traitées au niveau de l’hôte. Le contenu externe doit être signalé comme non fiable, et les demandes portant sur des informations sensibles doivent nécessiter l’approbation éclairée d’un humain dans la boucle. Des tests de sécurité consistant à faire appel à des documents ou à des données malveillants pour observer la réaction de l’hôte et du LLM peuvent également être utiles.

Menace n° 2 : empoisonnement d’outils et rug pulls

Dans une attaque par empoisonnement d’outil, du code malveillant est ajouté à la description ou au schéma d’un outil MCP. Cela peut influencer le LLM lors de la phase de découverte, lorsque le MCP expose pour la première fois les outils disponibles.

Agrandir

Un rug pull est un type particulier d’empoisonnement d’outil dans lequel des métadonnées déjà approuvées sont modifiées. Cette forme d’empoisonnement peut changer la manière dont un modèle utilise des outils de confiance, plutôt que d’invoquer directement un outil malveillant.

Comment se protéger contre l’empoisonnement d’outils et les rug pulls

L’hôte doit examiner la définition complète de chaque outil avant de l’utiliser et la comparer à une liste d’outils de confiance approuvés, afin de détecter toute modification. Des vérifications des paramètres peuvent aider à repérer des capacités potentiellement dangereuses et à les signaler.

Menace n° 3 : permissions excessives

Il est courant que les utilisateurs accordent aux serveurs MCP et aux LLM connectés (via l’hôte) plus de permissions que nécessaire pour une tâche : par exemple, des permissions d’écriture alors qu’un accès en lecture seule suffirait, ou un accès complet à un système de fichiers interne (comme Google Drive).

Cette dérive importante des permissions peut accroître le rayon d’impact d’autres vulnérabilités, comme les appels d’outils malveillants. Il est courant que les permissions « s’accumulent » à mesure que les utilisateurs accordent des privilèges dans le cadre de leur travail quotidien avec des outils d’IA en entreprise (accumulation de privilèges).

Comment se protéger contre les permissions excessives

Le moyen le plus direct de se prémunir contre ce problème est de restreindre les permissions et les portées OAuth (lecture, écriture, accès complet, etc.). Les approbations des utilisateurs, en particulier pour les opérations sensibles, en sont un élément important, mais les permissions doivent aussi être contrôlées au niveau du système (système d’exploitation, hôte MCP et serveur).

Menace n° 4 : authentification et autorisation faibles

L’authentification vérifie l’identité des utilisateurs ou des applications qui se connectent à un serveur MCP. L’autorisation détermine les outils et les ressources auxquels ils peuvent accéder.

Des serveurs MCP mal configurés peuvent accepter des requêtes ou des jetons sans authentifier correctement les utilisateurs ni appliquer les restrictions d’accès. En outre, des identifiants volés peuvent permettre à des acteurs malveillants d’obtenir un accès si la validation est faible.

Comment se protéger contre une authentification et une autorisation faibles

L’authentification basée sur OAuth pour les serveurs MCP distants, les jetons à courte durée de vie et le contrôle d’accès basé sur les rôles (RBAS) sont autant de mesures qui contribuent à atténuer les faiblesses d’autorisation. L’accès basé sur les rôles est utile, car il empêche les utilisateurs d’accéder à des données et à des outils au-delà de leurs permissions, même si le serveur lui-même y a accès.

Menace n° 5 : fuite et utilisation abusive d’identifiants

Les serveurs MCP utilisent couramment des identifiants comme des clés API et des jetons d’accès OAuth pour se connecter à des services externes. Si ceux-ci sont exposés ou utilisés de manière abusive, des attaquants peuvent accéder à des données et à des fonctionnalités sensibles.

La transmission directe de jetons (token passthrough) en est un exemple : un serveur MCP transmet un jeton d’accès à un autre service sans vérifier qu’il est bien destiné au service destinataire. Cela peut à son tour entraîner une fuite si le service destinataire ne dispose pas de protections suffisantes.

Comment se protéger contre les fuites et l’utilisation abusive d’identifiants

Les jetons à courte durée de vie et à portée limitée, ainsi que la rotation des identifiants, permettent de limiter efficacement l’usage que des acteurs malveillants peuvent faire des données divulguées. Les clés API et les identifiants doivent toujours être stockés de manière sécurisée à l’aide d’un gestionnaire de secrets.

Menace n° 6 : attaques du député confus

Une attaque du député confus (confused deputy) se produit lorsqu’un attaquant amène une application de confiance à utiliser ses permissions pour effectuer une action qui n’est pas autorisée par un utilisateur légitime. Dans ce cas, le serveur MCP joue le rôle du député.

Agrandir

L’attaquant exploite une vulnérabilité du serveur MCP (comme des vérifications OAuth insuffisantes) pour exécuter un processus malveillant, tel qu’un appel d’outil ou une récupération de données.

Comment se protéger contre les attaques du député confus

La validation des autorisations, qui consiste à vérifier que chaque appel d’outil appartient bien à un utilisateur précis, contribue à limiter les attaques du député confus. En outre, les actions sensibles, comme les exportations de données, doivent nécessiter une autorisation explicite.

Menace n° 7 : serveurs malveillants et dépendances compromises

Les serveurs MCP peuvent contenir du code malveillant (ce sont essentiellement des programmes externes) ou reposer sur des dépendances compromises, comme des bibliothèques tierces. Il s’agit d’un problème de chaîne d’approvisionnement logicielle, plutôt que d’un problème propre au MCP.

L’un des scénarios les plus simples consiste pour un attaquant à distribuer une intégration d’apparence légitime. Une fois configurée, celle-ci peut voler et réutiliser des identifiants, accéder à des données sensibles et exécuter des opérations non autorisées.

Comment se protéger contre les serveurs malveillants et les dépendances compromises

N’installez des serveurs MCP qu’à partir de sources fiables et vérifiées. Si possible, examinez leur code et vérifiez systématiquement toutes les dépendances externes. Veillez à ce que les serveurs soient régulièrement mis à jour et corrigés.

Menace n° 8 : falsification de requête côté serveur (SSRF)

La falsification de requête côté serveur (SSRF) se produit lorsqu’un attaquant amène un serveur MCP à envoyer des requêtes réseau vers des adresses internes auxquelles l’utilisateur n’avait pas l’intention d’accéder.

Cela peut se produire lorsqu’un serveur MCP expose un outil qui récupère des informations à partir d’une URL. Si un attaquant peut influencer le paramètre d’URL, il peut le remplacer par l’adresse réseau de son choix, comme une API interne ou un service cloud. Des données sensibles peuvent alors être récupérées et potentiellement rendues accessibles

Comment se protéger contre la falsification de requête côté serveur (SSRF)

Les serveurs MCP doivent toujours valider les URL, bloquer l’accès aux adresses réseau internes restreintes et empêcher l’accès réseau sortant. Les redirections doivent également respecter ce protocole.

Menace n° 9 : détournement de session

Le détournement de session consiste pour un attaquant à prendre le contrôle d’une connexion active entre un client MCP et un serveur.

Par exemple, l’attaquant peut voler un identifiant de session dans une application MCP mal sécurisée (comme un hôte ou un serveur). Si le serveur MCP accepte cet identifiant, l’attaquant peut potentiellement appeler des outils avec les permissions légitimes de l’utilisateur.

Comment s’en protéger

Le risque de détournement de session peut être réduit grâce à une vérification stricte de l’identité dans toutes les applications d’un système MCP. Le chiffrement entre les clients MCP et les serveurs distants est également essentiel pour empêcher que les identifiants de session ne soient découverts.

Menace n° 10 : attaques par confusion (mix-up)

Dans une attaque par confusion (mix-up), l’attaquant amène un client MCP à envoyer un code d’autorisation à un serveur d’autorisation malveillant situé entre le client et le serveur MCP. Un serveur d’autorisation est une application qui émet des jetons d’accès OAuth après avoir vérifié que l’accès demandé est autorisé.

Agrandir

Si un hôte MCP se connecte à plusieurs services utilisant chacun un serveur d’autorisation différent, un attaquant peut potentiellement en contrôler un (par exemple en enregistrant un service malveillant) et amener le client à envoyer au serveur malveillant un code d’autorisation émis par un serveur légitime. Cette confusion peut permettre à l’attaquant d’usurper l’identité de l’application autorisée et d’accéder à des services protégés.

Comment se protéger contre les attaques par confusion

Les clients MCP doivent vérifier l’identité du serveur d’autorisation tout au long du processus OAuth. Plus précisément, ils doivent comparer l’identifiant d’émetteur (iss) du serveur à l’identité attendue et rejeter toute non-concordance.

Menace n° 11 : compromission d’un serveur MCP local

De nombreux serveurs MCP s’exécutent sur la machine locale de l’utilisateur. Celui-ci peut installer le serveur à partir d’un tiers ou le créer lui-même. Si un attaquant parvient à compromettre ce serveur MCP local, il peut potentiellement accéder à une grande partie du système local.

Un attaquant peut obtenir un accès de diverses manières. Il peut distribuer un serveur malveillant déguisé en intégration légitime, modifier la configuration d’un hôte MCP afin qu’il émette une commande malveillante, ou accéder à un serveur MCP exécuté dans un environnement dont les contrôles de sécurité sont insuffisants, par exemple via le DNS rebinding, qui amène un navigateur à envoyer des requêtes à un service localhost.

Comment se protéger contre la compromission d’un serveur MCP local

L’exécution en bac à sable et des protocoles de consentement stricts sont importants lorsque vous utilisez des serveurs MCP locaux. Les serveurs MCP ne doivent jamais être installés qu’à partir de fournisseurs de confiance, et les permissions du système d’exploitation doivent restreindre les répertoires auxquels ils peuvent accéder.

Les vulnérabilités du MCP sont souvent de vieilles menaces sous un nouveau jour

Les vulnérabilités du MCP découlent souvent de nouvelles applications de risques et de méthodes d’attaque bien connus. Le MCP offre aux attaquants de nouveaux moyens d’exploiter ces vulnérabilités à travers les interactions entre les LLM, les serveurs MCP et les services externes.

Bien entendu, il existe des menaces propres au MCP. Il faut toutefois garder à l’esprit que les protocoles de sécurité standard, comme l’application d’une autorisation stricte, le recours à des fournisseurs de confiance et la protection contre les injections de prompt, contribuent largement à protéger toute implémentation du MCP.