Sécurité et confidentialité

Principes

Les outils des plugins peuvent accéder aux données utilisateur, aux API tierces et aux actions d’écriture. Traitez chaque serveur MCP et chaque composant d’interface comme un logiciel de production :

• Moindre privilège : Ne demandez que les portées, les accès au stockage et les autorisations réseau dont vous avez besoin.
• Consentement explicite de l’utilisateur : Assurez-vous que les utilisateurs comprennent quand ils associent des comptes ou accordent un accès en écriture. Utilisez les demandes de confirmation de l’hôte pour les actions destructrices.
• Défense en profondeur : Partez du principe que des attaques par injection de prompt et des entrées malveillantes atteindront votre serveur. 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 actuel. Évitez d’intégrer des secrets ou des tokens dans les props des composants.
• Stockage : Définissez la durée de conservation des données utilisateur et publiez une politique de conservation. Respectez les demandes de suppression.
• Journalisation : Masquez les informations personnelles identifiables 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 cela est nécessaire.

Attaques par injection de prompt et actions d’écriture

Le mode développeur permet un accès complet à MCP, y compris aux outils d’écriture. Pour réduire les risques :

• Réexaminez 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 elles proviennent du modèle.
• Exigez une confirmation humaine pour les opérations irréversibles.

Partagez vos meilleurs prompts de test d’injection avec votre équipe d’assurance qualité afin qu’elle puisse détecter les points faibles au plus tôt.

Accès réseau

Les widgets s’exécutent dans une iframe isolée avec 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 indisponibles par défaut ; autorisez des origines précises dans les métadonnées CSP de la ressource, par exemple _meta.ui.csp.frameDomains. Les plugins peuvent intégrer des pages provenant du domaine enregistrable propre à leur serveur MCP, notamment des éditeurs et des interfaces d’administration existants. Consultez la politique relative aux iframes pour connaître les exigences concernant la propriété du domaine, les justifications à fournir et les révisions requises.

La CSP du widget limite les destinations pouvant être chargées dans les iframes. Une page intégrée utilise sa propre CSP ; les listes d’autorisation connectDomains et resourceDomains du widget ne limitent pas les requêtes réseau effectuées depuis cette page. Spécifiez des origines précises pour les iframes et incluez l’expérience intégrée dans votre révision de sécurité.

Le code côté serveur n’est soumis à aucune restriction réseau autre que celles imposées par votre environnement d’hébergement. Suivez les bonnes pratiques habituelles pour les appels sortants (vérification TLS, nouvelles tentatives, délais d’expiration).

Authentification et autorisation

• Utilisez les flux OAuth 2.1 avec code d’autorisation pour intégrer des comptes externes. Privilégiez les Client ID Metadata Documents (CIMD) lorsque votre serveur d’autorisation prend en charge CIMD et que le créateur du plugin choisit cette option. Utilisez none pour l’échange de tokens avec un client public, ou private_key_jwt lorsque votre serveur d’autorisation exige l’authentification du client. Prenez en charge DCR lorsque le créateur du plugin choisit cette option ou que CIMD n’est pas disponible.
• Vérifiez et faites respecter les portées à chaque appel d’outil. Renvoyez une réponse 401 pour les tokens expirés ou mal formés.
• Pour la gestion d’identité intégrée, évitez de stocker des secrets à longue durée de vie ; utilisez plutôt le contexte d’authentification fourni.

Préparation à l’exploitation

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

La sécurité et la confidentialité sont essentielles à la confiance des utilisateurs. Intégrez-les dès le départ à vos workflows de planification, d’implémentation et de déploiement, au lieu de vous en préoccuper après coup.