Sécurité et confidentialité

Principes

Les outils d’un plugin peuvent accéder aux données des utilisateurs, appeler des API tierces et effectuer des opérations d’écriture. Traitez chaque serveur MCP et chaque composant d’interface comme un logiciel de production.

• Moindre privilège : Demandez uniquement les portées d’autorisation, les droits d’accès au stockage et les autorisations réseau dont vous avez besoin.
• Consentement explicite de l’utilisateur : Veillez à ce que les utilisateurs comprennent quand ils associent des comptes ou accordent un accès en écriture. Pour les actions destructrices, utilisez les demandes de confirmation de l’hôte.
• Défense en profondeur : Partez du principe que votre serveur sera exposé à des attaques par injection de prompt et recevra des entrées malveillantes. Vérifiez chaque entrée et conservez des journaux d’audit.

Traitement des données

• Contenu structuré : Incluez uniquement les données nécessaires au prompt en cours. Évitez d’inclure des secrets ou des jetons dans les props des composants.
• Stockage : Définissez la durée de conservation des données des utilisateurs et publiez une politique de conservation. Respectez les demandes de suppression.
• Journalisation : Masquez les informations permettant d’identifier une personne avant de les consigner dans les journaux. Conservez les identifiants de corrélation pour le débogage, mais évitez de stocker le texte brut des prompts, sauf si nécessaire.

Attaques par injection de prompt et opérations d’écriture

Les serveurs MCP personnalisés donnent accès à toutes les fonctionnalités de MCP, y compris aux outils d’écriture. Pour limiter les risques, prenez les mesures suivantes.

• Relisez régulièrement les descriptions des outils pour décourager les usages inappropriés (« N’utilisez pas cet outil pour supprimer des enregistrements »).
• Validez toutes les entrées côté serveur, même si le modèle les a fournies.
• Exigez une confirmation humaine pour les opérations irréversibles.

Partagez avec votre équipe d’assurance qualité les prompts les plus efficaces pour tester la résistance aux attaques par injection de prompt. L’équipe pourra ainsi repérer les points faibles au plus tôt.

Accès réseau

Les widgets s’exécutent dans une iframe isolée soumise à une politique de sécurité du contenu (CSP) stricte. Ils ne peuvent pas accéder aux API privilégiées du navigateur telles que window.alert, window.prompt, window.confirm ou navigator.clipboard. La CSP contrôle les requêtes fetch standard. Les cadres imbriqués sont désactivés par défaut. Pour les activer, autorisez des origines précises dans les métadonnées CSP de la ressource, par exemple dans _meta.ui.csp.frameDomains. Les plugins peuvent intégrer des pages du domaine enregistrable de leur propre serveur MCP, y compris des éditeurs et des interfaces d’administration existants. Consultez la politique relative aux iframes pour connaître les conditions de propriété du domaine, les justifications à fournir et les exigences de revue.

La CSP du widget détermine quelles destinations peuvent être chargées dans une iframe. Une page intégrée applique sa propre CSP. Les listes d’autorisation connectDomains et resourceDomains du widget ne limitent pas les requêtes réseau émises depuis cette page. Autorisez uniquement des origines précises pour les iframes et incluez les fonctionnalités intégrées dans votre revue de sécurité.

Côté serveur, seules les restrictions réseau imposées par votre environnement d’hébergement s’appliquent. Suivez les bonnes pratiques habituelles pour les appels sortants (vérification TLS, nouvelles tentatives, délais d’expiration).

Authentification et autorisation

• Pour intégrer des comptes externes, utilisez les flux OAuth 2.1 avec code d’autorisation. Privilégiez les documents de métadonnées d’identifiant client (CIMD) si votre serveur d’autorisation les prend en charge et que le développeur du plugin choisit cette méthode. Utilisez none pour l’échange de jetons avec un client public ou private_key_jwt si votre serveur d’autorisation exige l’authentification du client. Prenez en charge l’enregistrement dynamique des clients (DCR) si le développeur du plugin choisit cette méthode ou si CIMD est indisponible.
• À chaque appel d’outil, vérifiez les portées d’autorisation et faites respecter les limites qu’elles imposent. Renvoyez une réponse 401 si le jeton a expiré ou si son format est incorrect.
• Si vous utilisez le mécanisme d’identité intégré, évitez de stocker des secrets à longue durée de vie. Utilisez le contexte d’authentification fourni.

Préparation à la mise en production

• Effectuez des revues de sécurité avant le lancement, en particulier si vous traitez des données soumises à une réglementation.
• Surveillez le trafic pour détecter les anomalies et configurez des alertes en cas d’erreurs répétées ou de tentatives d’authentification infructueuses.
• Appliquez les correctifs aux dépendances tierces, aux bibliothèques et aux outils de build pour limiter les risques liés à la chaîne d’approvisionnement logicielle.

La confiance des utilisateurs repose sur la sécurité et la confidentialité. Prenez-les en compte dès la planification, puis tout au long de la mise en œuvre et du déploiement.