Chaque MCP server sur HostedMCP comporte une courte note en bas de page : les serveurs listés s'exécutent avec les permissions que vous leur accordez, examinez donc le code source avant l'installation. Nous avons ajouté cette mention car le problème de sécurité MCP le plus courant n'est pas une faille sophistiquée. Il s'agit simplement de quelqu'un qui colle une URL de base de données avec des droits d'écriture complets dans un serveur trouvé cinq minutes plus tôt.
Ce guide couvre les deux types de risques. Les risques ordinaires, comme des identifiants trop permissifs, sont à l'origine de la plupart des incidents. Les risques au niveau du protocole, tels que le transfert de jetons (token passthrough) et les problèmes de « confused deputy », sont cruciaux si vous développez ou hébergez des serveurs. Nous avons basé chaque point sur les bonnes pratiques de sécurité officielles du MCP pour la révision du 2026-07-28, ainsi que sur nos propres observations au sein du catalogue.
Points clés
- La plupart des incidents MCP proviennent d'erreurs ordinaires : des identifiants trop permissifs et des serveurs qui n'ont pas été vérifiés.
- Le modèle lit du texte non fiable ; par conséquent, n'importe quel outil à sa disposition peut être détourné par une page web, un ticket ou un e-mail.
- Les serveurs locaux s'exécutent avec vos permissions ; les serveurs distants doivent respecter OAuth 2.1 et ne jamais transmettre de jetons.
- Le principe du moindre privilège, l'approbation pour toute opération d'écriture, le verrouillage des versions et la limitation du nombre de serveurs par agent permettent de prévenir la plupart des problèmes.
| Risque | Qui est affecté | Défense principale |
|---|---|---|
| Prompt injection via le contenu | Toute personne dont l'agent lit des pages web, des tickets ou des e-mails | Approbation avant l'écriture ; aucun outil irréversible à proximité d'une entrée non fiable |
| Un serveur local s'exécute avec vos droits | Toute personne installant des serveurs stdio | Éditeurs de confiance, secrets limités au périmètre nécessaire, versions verrouillées |
| Erreurs OAuth dans les serveurs distants | Développeurs et hébergeurs de serveurs | Respecter la spécification d'autorisation du MCP ; pas de transfert de jetons |
| Trop d'outils au même endroit | Agents disposant de nombreux serveurs | Ne donner à chaque agent que les serveurs nécessaires à sa tâche |
Pourquoi le MCP change la donne en matière de sécurité
Une intégration traditionnelle repose sur du code écrit par un développeur, appelant une API selon des modalités définies à l'avance. Avec le MCP, c'est le modèle qui décide, au moment de l'exécution, quel outil appeler et avec quels arguments, en se basant sur l'ensemble de son contexte. Une partie de ce contexte est constituée de texte que personne dans votre équipe n'a écrit : une page web récupérée par le modèle, un issue GitHub, un e-mail ou le résultat d'un autre outil.
C'est là tout le problème, résumé en une phrase. Le modèle est un décideur qui lit des entrées non fiables. La plupart des risques liés au MCP sont des variantes de "du texte non fiable a piloté un appel d'outil" ou "un outil disposait de plus d'accès que nécessaire lors de cet événement".
Risque 1 : injection de prompt via le contenu
Supposons que vous ayez connecté un MCP server GitHub avec l'autorisation de commenter et de fermer des issues, et que vous demandiez à votre agent de trier les nouvelles issues. Une issue contient, dissimulée dans un long log, une ligne ordonnant à l'assistant de fermer toutes les issues ouvertes en tant que doublons. Un modèle capable de suivre des instructions présentes dans les données peut précisément faire cela.
Rien dans le protocole n'empêche cela, car le raisonnement du modèle n'est pas une chose qu'un protocole peut valider. Ce qui aide, c'est la superposition des couches de sécurité. Les bons hosts demandent une approbation avant l'exécution d'outils qui modifient des données et vous affichent les arguments utilisés. Les bons servers marquent les outils qui écrivent ou suppriment, afin que les hosts puissent les traiter différemment. Enfin, vous pouvez limiter l'accès de l'agent au strict nécessaire pour sa mission : le tri nécessite de lire et d'ajouter des labels, pas de fermer ou de supprimer.
Attention
Un agent qui lit du contenu non fiable ne doit pas posséder d'outils capables d'effectuer des actions irréversibles sans la confirmation d'une personne. C'est la règle que nous appliquons nous-mêmes.
Risque 2 : un serveur local s'exécute avec vos privilèges
Un serveur local est un programme sur votre ordinateur, lancé par votre application IA, avec vos propres permissions utilisateur. Il peut lire les fichiers que vous pouvez lire et accéder au réseau auquel vous avez accès. Les bonnes pratiques de sécurité MCP considèrent cela comme un risque à part entière : un serveur local malveillant ou compromis peut exécuter des commandes arbitraires avec les privilèges du client, c'est pourquoi les flux d'installation en un clic doivent obtenir un consentement explicite et afficher la commande exacte.
Les serveurs locaux représentent une part importante de notre catalogue, en particulier parmi les outils de développement, et beaucoup d'entre eux nécessitent des secrets. Le 11 novembre 2026, 11 660 serveurs ont déclaré des variables d'environnement, et 12 757 de ces variables étaient marquées comme des secrets : clés API, tokens et mots de passe stockés dans le fichier de configuration de votre client.
Voici comment les serveurs de notre catalogue déclarent s'authentifier, d'après les README que notre modèle d'enrichissement a analysés (mesuré November 14, 2026) :
| Authentification | Servers | Partager |
|---|---|---|
| Aucune | 18 608 | 46% |
| Clé API ou OAuth | 10 521 | 26% |
| Clé API ou token | 9 252 | 23% |
| OAuth | 2 391 | 6% |
La marche à suivre relève principalement du bon sens, appliqué de manière cohérente.
Privilégiez les serveurs provenant de l'éditeur du produit, ou d'un éditeur dont vous pouvez consulter les autres travaux. Nos pages de serveurs indiquent l'éditeur et marquent les serveurs officiels.
Vérifiez que la source est publique et active. Un package sans dépôt lié, ou un dépôt dont la dernière modification remonte à un an, est un pari plus risqué. Chaque page HostedMCP affiche la date du dernier commit et de la dernière version.
Lisez la liste des outils avant l'installation. Si un serveur "weather" possède un outil qui exécute des commandes shell, arrêtez-vous.
Limitez la portée du secret. Donnez un utilisateur en lecture seule à un serveur de base de données. Donnez un token à granularité fine pour un seul dépôt à un serveur GitHub. Orientez un serveur de système de fichiers vers un seul dossier de projet, jamais vers votre répertoire personnel.
Astuce
Fixez les versions pour tout ce qui est important.
npx -y some-server@latestexécute ce qui a été publié le plus récemment à chaque démarrage ;npx -y some-server@1.4.2exécute la version que vous avez vérifiée.
La spécification mentionne un autre risque local important si vous utilisez des proxys : dans une configuration où une page web peut atteindre un proxy MCP local, une faille de type cross-site scripting sur cette page peut dégénérer en exécution de commandes via le serveur stdio du proxy. Si vous exécutez une passerelle ou un proxy MCP sur localhost, traitez-le comme n'importe quel autre service local présentant une surface d'attaque.
Risque 3 : serveurs distants et OAuth
Les serveurs distants n'interviennent pas directement sur votre machine, mais ils détiennent des tokens pour de nombreux utilisateurs et communiquent avec d'autres services en leur nom, ce qui engendre un ensemble de problèmes différents. Les bonnes pratiques de sécurité MCP en énumèrent plusieurs explicitement.
| Attaque | Description du problème | Défense |
|---|---|---|
| Token passthrough | Un serveur accepte un token qui ne lui a pas été délivré, ou transmet le token de l'utilisateur vers un service en amont | Acceptez uniquement les tokens émis pour ce serveur ; ne les transmettez jamais |
| Confused deputy | Un proxy possédant un client ID statique accorde un code à un client malveillant sans consentement réel | Consentement par client au sein du proxy |
| Server-side request forgery | La découverte OAuth oriente le client vers des URL internes, comme les métadonnées cloud | Les clients valident les URL de découverte |
| Mix-up attack | Un serveur d'autorisation malveillant envoie un code vers le token endpoint d'un serveur légitime | Validation de iss (RFC 9207), ajoutée le 2026-07-28 |
| Authorization URL abuse | Un serveur renvoie une URL javascript: ou des métacaractères shell |
Les clients valident l'URL avant de l'ouvrir |
| Localhost redirect impersonation | Un autre processus local intercepte un code envoyé vers localhost |
Gestion rigoureuse des redirections dans les clients desktop |
| Over-broad scopes | Un token fuité peut effectuer bien plus que la tâche requise | Demandez le scope le plus restreint possible |
La règle derrière la première ligne est directe : les MCP server ne doivent accepter aucun token qui n'a pas été explicitement émis pour le MCP server.
La révision du 2026-07-28 a également marqué la dépréciation de l'OAuth Dynamic Client Registration au profit des Client ID Metadata Documents, et la conception stateless a remplacé les sessions de protocole ; les anciennes préoccupations liées au détournement de session sont désormais formulées comme un détournement des handles d'état émis par un serveur. Si votre serveur conserve un état, rendez ces handles impossibles à deviner et liez-les à l'utilisateur.
Risque 4 : trop de ressources centralisées
Le risque le plus discret est celui de la concentration. Un agent disposant d'un MCP server GitHub, d'un MCP server Slack, d'un MCP server de base de données et d'un MCP server de navigation peut lire du code, consulter des messages, interroger des clients et visiter n'importe quel site web, le tout dans un même contexte. Une seule instruction injectée dispose alors d'un champ d'action très large, incluant des moyens d'exfiltrer des données.
La segmentation est une solution. Ne fournissez à un agent que les serveurs nécessaires à la tâche en cours plutôt que l'intégralité de votre parc. Éloignez les serveurs qui lisent des données sensibles de ceux qui peuvent publier vers l'extérieur, ou du moins, exigez une approbation pour les serveurs sortants.
Une checklist pour l'installation de serveurs
Avant d'ajouter un serveur, quelques minutes de vérification permettent d'éviter la plupart des problèmes.
- Identifiez l'éditeur. S'agit-il d'un éditeur officiel ou d'un mainteneur que vous pouvez identifier.
- Confirmez que le code est public et qu'il a été maintenu récemment.
- Lisez attentivement le nom et la description de chaque outil. Tout élément qui ne correspond pas à la fonction du serveur est un signal d'alerte.
- Accordez le minimum d'accès nécessaire : utilisateurs en lecture seule, tokens limités à un seul dépôt, un seul dossier.
- Maintenez les actions d'écriture et de suppression sous réserve de votre approbation, et n'autorisez pas ces actions de manière permanente tant que vous n'avez pas une totale confiance.
- Fixez les versions des serveurs dont vous dépendez, et effectuez les mises à jour de manière délibérée.
- Supprimez les serveurs que vous n'utilisez plus. Chaque serveur installé représente une surface d'attaque et une consommation de la fenêtre de contexte.
Chaque page de serveur sur HostedMCP affiche l'éditeur, le dernier commit, les variables d'environnement nécessaires ainsi que la liste complète des outils, ce qui permet de valider les quatre premiers points en une minute.
Une checklist pour les développeurs de serveurs
Si vous maintenez un serveur, vous assumez une plus grande part de responsabilité.
- N'exposez que le strict nécessaire d'outils pour accomplir la tâche, en les nommant par fonction.
- Marquez les outils qui écrivent ou suppriment avec l'indice de destruction afin que les hôtes puissent demander une confirmation préalable.
- Validez chaque argument comme s'il provenait d'un attaquant, car c'est une possibilité.
- Journalisez vers stderr, jamais vers stdout, et ne journalisez jamais de secrets.
- Pour les serveurs distants, respectez la spécification d'autorisation MCP : OAuth 2.1, n'acceptez que les tokens émis pour votre serveur, pas de transmission de token (passthrough), et utilisez des scopes restreints.
- Traitez les handles d'état comme des secrets : aléatoires, liés à l'utilisateur et à durée de vie courte.
- Documentez chaque permission et variable d'environnement nécessaire à votre serveur, en utilisant uniquement des valeurs fictives.
Notre guide pour créer un MCP server présente les bases avec les SDK actuels, et MCP vs API explique pourquoi renvoyer moins de données constitue également un avantage en matière de sécurité.
Utiliser MCP en équipe
Dès que plusieurs personnes utilisent MCP au travail, les installations ad hoc ne sont plus viables. Quelques bonnes pratiques permettent d'en assurer la gestion.
| Habitude | Pourquoi c'est utile |
|---|---|
| Une liste de serveurs approuvée et figée dans le dépôt | Tout le monde utilise les mêmes versions révisées |
| Des identités distinctes pour les agents | Les logs d'audit indiquent quelles actions un agent a effectuées ; révoquer son accès n'impacte personne |
| Des serveurs hébergés pour les produits SaaS | Pas de clés API sur les ordinateurs ; l'accès suit les contrôles d'administration du produit |
| La journalisation des appels d'outils | En cas d'imprévu, le log montre quel contenu a orienté le modèle |
| Des mises à jour révisées comme des dépendances | Le nouveau code exécuté avec vos permissions est lu avant son exécution |
Maintenez une liste approuvée. Choisissez les serveurs que votre équipe est susceptible d'utiliser, fixez leurs versions et partagez la configuration via le dépôt plutôt que dans le répertoire personnel de chaque utilisateur. Le fichier .mcp.json de Claude Code (au niveau du projet) et le fichier .vscode/mcp.json de VS Code (au niveau de l'espace de travail) existent précisément pour cela, et nos guides clients indiquent où chaque outil stocke sa configuration de projet.
Attribuez des identités propres aux agents. Un compte de service ou un jeton de bot pour l'agent, distinct des identifiants d'une personne, permet d'identifier clairement dans les logs d'audit les actions effectuées par l'agent et vous permet de révoquer son accès sans bloquer personne.
Privilégiez les serveurs hébergés pour le SaaS. Lorsqu'un fournisseur gère lui-même le MCP server de son produit, vous évitez de distribuer des clés API sur les ordinateurs portables, et l'accès est régi par les mêmes autorisations OAuth et contrôles d'administration que le reste du produit. Notre liste de serveurs distants est un moyen rapide de voir quels fournisseurs en proposent un.
Journalisez les appels d'outils. La plupart des hôtes peuvent enregistrer quels outils ont été exécutés avec quels arguments. Conservez ces logs au même endroit que vos autres logs d'audit et consultez-les après tout événement surprenant ; ils montrent généralement exactement quel élément de contenu a orienté le modèle.
Révisez les mises à jour comme des dépendances. La mise à jour d'un serveur revient à exécuter du nouveau code avec vos permissions. Lisez le changelog des serveurs capables d'écrire dans des systèmes de production, de la même manière que vous le feriez pour une bibliothèque.
Ce que HostedMCP vérifie et ne vérifie pas
Nous sommes un annuaire, pas un auditeur de sécurité, et il est important de bien définir cette limite. Pour chaque fiche, nous lisons le dépôt, les packages et le README, enregistrons l'éditeur, le dernier commit, les releases et les variables d'environnement déclarées, et affichons la liste complète des outils. Les fiches provenant d'éditeurs en masse sont signalées, et les forks ou miroirs sont fusionnés avec l'original.
Nous n'exécutons pas les serveurs et n'auditons pas leur code. Une fiche sur HostedMCP signifie que nous l'avons trouvée et décrite avec précision, pas qu'elle est sûre pour votre environnement. Cette décision vous appartient, et les checklists ci-dessus sont la méthode que nous utiliserions pour l'évaluer.
Si vous débutez, qu'est-ce que le MCP et qu'est-ce qu'un MCP server sont de bons points de départ, et notre liste de serveurs distants est le moyen le plus simple d'essayer des serveurs qui ne touchent jamais votre machine.