Menu

MCP07:2025 - Insufficient Authentication & Authorization

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
1 min de lecture

Beaucoup de serveurs MCP sont déployés avec l’authentification désactivée “pour tester” et finissent en prod comme ça. Dans un système multi-agents, c’est une porte d’entrée béante pour n’importe qui sur le réseau.

Partie de la série OWASP MCP Top 10

Description du risque

L’insuffisance d’authentification et d’autorisation dans les serveurs MCP expose des chemins d’attaque critiques. Quand un serveur MCP ne vérifie pas qui l’appelle, n’importe quel agent — ou n’importe quel attaquant — peut invoquer ses outils.

Le problème est exacerbé par la manière dont MCP est souvent déployé : en local sans auth, puis poussé en production sans sécuriser. Dans un réseau d’entreprise, “sans auth” + “port ouvert” = compromission garantie.

Prenons le schéma suivant : un serveur MCP en localhost:8080 sans authentification, conteneurisé et déployé sur Kubernetes. Le port est accessible depuis tout le cluster. Zéro JWT, zéro mTLS. Tous les outils MCP ouverts au premier pod compromis.

“Sans auth” + “port ouvert” = compromission garantie. C’est la règle la plus simple et la plus violée de la sécurité MCP.

🔒 La suite est réservée aux abonnés payants sur Substack
Retrouvez l'analyse complète, avec les vecteurs d'attaque, l'analyse STRIDE, les impacts et les recommandations de mitigation.

À retenir

À retenir 📌

  • ✓Pas d'auth = pas de sécurité : un serveur MCP sans authentification est un serveur compromis en attente
  • ✓Le spoofing inter-agents est trivial : sans vérification cryptographique
  • ✓JWT RS256 + RBAC granulaire : le minimum vital pour tout déploiement MCP
LinkedIn Reddit Substack