Les 8 failles qu'on retrouve dans presque tous les serveurs MCP en prod
Huit failles qu'on retrouve dans presque tous les serveurs MCP en production, tirées d'audits réels, avec la correction et l'ordre de priorité.
En auditant des serveurs MCP, on retrouve toujours à peu près les mêmes trous. Ce ne sont pas des failles exotiques. Ce sont des conséquences prévisibles du fait qu'un serveur MCP a été écrit comme une API, alors qu'il est appelé par un agent.
Voici les huit, dans l'ordre où je les rencontre.
1. Un token qui ouvre tous les outils
Le défaut le plus répandu. L'utilisateur s'authentifie, il obtient un token, et ce token permet d'appeler les douze outils, y compris celui qui supprime.
Avec une API, ce n'était déjà pas idéal. Avec un agent, c'est pire : ce n'est plus un humain qui décide quel appel partir, c'est un modèle, sur la base d'un contexte qui peut contenir du contenu tiers.
La correction n'est pas forcément un système de permissions complet. Un premier pas utile est de séparer lecture et écriture, et d'exiger une confirmation explicite sur les outils destructeurs.
2. Aucun rate limit par outil
Un rate limit global traite l'appel qui liste les outils et celui qui exporte toute la base de la même manière. C'est-à-dire mal.
Depuis la 2026-07-28, il n'y a plus d'excuse : les en-têtes Mcp-Method et Mcp-Name permettent de limiter par outil au niveau HTTP, sans ouvrir le corps de la requête. Dix appels par minute sur l'export, mille sur la recherche.
3. Aucune trace des écritures
La question qu'un client pose après le premier incident est toujours la même : qu'est-ce qui a été modifié, par qui, et quand. Sur la majorité des serveurs MCP, la réponse n'existe pas.
Un journal des appels d'écriture, avec l'outil, l'appelant, l'horodatage et le résultat, coûte une table et une ligne par outil. C'est aussi un argument commercial : c'est souvent la première chose qu'un acheteur regarde.
4. Des handles qui ne vérifient pas leur propriétaire
Depuis que le protocole est stateless, l'état circule sous forme de handles passés en argument. Le réflexe est de résoudre le handle et de travailler.
Il manque une étape : vérifier que l'appelant courant est bien celui à qui le handle a été émis. Un handle traîne dans un historique de conversation, dans un log, dans un partage d'écran. S'il suffit à accéder aux données, tu as construit une URL secrète.
Ajoute aussi une expiration. Un handle sans TTL est un handle éternel.
5. Faire confiance à un en-tête déclaratif
Les en-têtes Mcp-Method et Mcp-Name sont fournis par le client. Rien ne garantit qu'ils correspondent au corps de la requête.
Si ta passerelle autorise sur la base de l'en-tête, une requête peut annoncer un outil en lecture seule et appeler un outil restreint. La périphérie route et mesure, le serveur autorise sur le corps, et toute incohérence est rejetée et comptée.
6. Des secrets dans les descriptions et les erreurs
Deux endroits qu'on oublie parce qu'ils ne ressemblent pas à des réponses.
Les descriptions d'outils sont lues par le modèle et souvent visibles de l'utilisateur. On y trouve des noms d'hôtes internes, des identifiants de tenants, des chemins d'infrastructure.
Les messages d'erreur sont pires, parce qu'on les écrit en développement et qu'on ne les relit jamais. Une erreur de base de données renvoyée telle quelle donne le schéma, parfois la requête.
7. Pas d'annotations sur les outils
Le protocole permet d'annoter un outil comme en lecture seule ou comme destructeur. Beaucoup de serveurs ne le font pas.
Ce n'est pas un mécanisme de sécurité en soi, le serveur reste responsable de ses vérifications. Mais c'est ce qui permet au client de demander une confirmation avant une action irréversible. Sans annotation, tous tes outils se ressemblent, et l'agent traite la suppression comme la lecture.
8. Aucune révocation par client
Un utilisateur a connecté ton serveur à quatre clients différents sur deux ans. Il veut en couper un. Sur la plupart des serveurs, la seule option est de tout révoquer, ou rien.
Une liste des connexions actives, avec la date, le client et un bouton de révocation, règle le problème. C'est aussi ce qu'un dossier de soumission à un annuaire de connecteurs regarde.
Deux garde-fous qui manquent presque toujours
La limite de taille de payload. Sans elle, un seul appel peut saturer ta mémoire.
Le comportement en cas de dépassement de quota. Beaucoup de serveurs renvoient une erreur brute que l'agent interprète comme un échec temporaire, et il réessaie en boucle. Une erreur claire, non retryable, évite de transformer un quota en incident.
Par où commencer
Si tu ne dois en traiter que trois : la portée des tokens, le rate limit par outil, et le journal des écritures. Ce sont les trois qui changent quelque chose le jour où il y a un incident, et les trois que tes acheteurs regardent.
Faire passer ton serveur au crible
L'audit couvre ces huit points plus la chaîne OAuth et la conformité protocole. Envoie ton dépôt, tu reçois sous 24 heures ouvrées un rapport classé par risque, avec le chiffrage des corrections.
Prêt à faire le point ? Faire auditer mon serveur MCP →
Lectures liées
Un serveur MCP à faire auditer ?
Cinq minutes pour le décrire. Je réponds sous 24 heures ouvrées avec un premier diagnostic écrit et gratuit.
Faire auditer mon serveur MCP