For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Hauptnavigation

Sicherheit und Datenschutz

Hinweise zu Sicherheit und Datenschutz bei Plug-ins.

Grundsätze

Plug-in-Tools können auf Nutzungsdaten und APIs von Drittanbietern zugreifen sowie Schreibaktionen ausführen. Behandle jeden MCP-Server und jede UI-Komponente wie produktiv eingesetzte Software:

  • Prinzip der geringsten Rechte: Fordere nur die Scopes, Speicherzugriffe und Netzwerkberechtigungen an, die du benötigst.
  • Ausdrückliche Zustimmung: Stelle sicher, dass Nutzende verstehen, wann sie Konten verknüpfen oder Schreibzugriff gewähren. Verwende für destruktive Aktionen die Bestätigungsabfragen des Hosts.
  • Mehrstufige Absicherung: Gehe davon aus, dass Prompt Injection und bösartige Eingaben deinen Server erreichen werden. Prüfe jede Eingabe und führe Audit-Protokolle.

Umgang mit Daten

  • Strukturierte Inhalte: Füge nur die Daten ein, die für den aktuellen Prompt erforderlich sind. Vermeide es, Geheimnisse oder Token in Komponenten-Props einzubetten.
  • Speicherung: Lege fest, wie lange du die Daten der Nutzenden aufbewahrst, und veröffentliche eine Aufbewahrungsrichtlinie. Komme Löschanfragen nach.
  • Protokollierung: Entferne personenbezogene Informationen (PII), bevor du Daten in Protokolle schreibst. Speichere Korrelations-IDs zur Fehlerbehebung, aber bewahre den ursprünglichen Prompt-Text nur auf, wenn es notwendig ist.

Prompt Injection und Schreibaktionen

Der Entwicklermodus ermöglicht vollständigen MCP-Zugriff, einschließlich Tools mit Schreibzugriff. So verringerst du das Risiko:

  • Überprüfe Tool-Beschreibungen regelmäßig, um einer missbräuchlichen Nutzung vorzubeugen („Nicht zum Löschen von Datensätzen verwenden“).
  • Validiere alle Eingaben serverseitig, auch wenn sie vom Modell stammen.
  • Verlange für unumkehrbare Vorgänge eine Bestätigung durch einen Menschen.

Teile deine besten Prompts zum Testen von Prompt Injection mit deinem Team für Qualitätssicherung, damit es frühzeitig Schwachstellen aufspüren kann.

Netzwerkzugriff

Widgets werden in einem isolierten iframe mit einer strikten Content Security Policy ausgeführt. Sie können nicht auf privilegierte Browser-APIs wie window.alert, window.prompt, window.confirm oder navigator.clipboard zugreifen. Die CSP regelt gewöhnliche fetch-Anfragen. Verschachtelte Frames sind standardmäßig nicht verfügbar. Gib bestimmte Ursprünge in den CSP-Metadaten der Ressource frei, etwa über _meta.ui.csp.frameDomains. Plug-ins können Seiten von der eigenen registrierbaren Domain ihres MCP-Servers einbetten, darunter auch bestehende Editoren und Verwaltungsoberflächen. Siehe die iframe-Richtlinie für Informationen zu Domaininhaberschaft, erforderlichen Begründungen und Review-Anforderungen.

Die CSP des Widgets beschränkt, welche iframe-Ziele geladen werden können. Eine eingebettete Seite verwendet ihre eigene CSP. Die Freigabelisten connectDomains und resourceDomains des Widgets schränken Netzwerkanfragen innerhalb dieser Seite nicht ein. Gib konkrete iframe-Ursprünge an und beziehe die eingebettete Oberfläche in dein Sicherheits-Review ein.

Für serverseitigen Code gelten nur die Netzwerkbeschränkungen deiner Hosting-Umgebung. Befolge die üblichen bewährten Methoden für ausgehende Aufrufe (TLS-Verifizierung, Wiederholungsversuche, Zeitlimits).

Authentifizierung und Autorisierung

  • Verwende beim Einbinden externer Konten Authorization-Code-Flows nach OAuth 2.1. Bevorzuge Client ID Metadata Documents (CIMD), wenn dein Autorisierungsserver CIMD unterstützt und diese Option bei der Plug-in-Erstellung gewählt wird. Verwende none für den Token-Austausch bei öffentlichen Clients oder private_key_jwt, wenn dein Autorisierungsserver eine Client-Authentifizierung verlangt. Unterstütze DCR, wenn diese Option bei der Plug-in-Erstellung gewählt wird oder CIMD nicht verfügbar ist.
  • Prüfe bei jedem Tool-Aufruf die Scopes und setze sie durch. Gib bei abgelaufenen oder fehlerhaft formatierten Token eine Antwort mit dem Statuscode 401 zurück.
  • Vermeide bei der integrierten Identitätsverwaltung das Speichern langlebiger Geheimnisse. Verwende stattdessen den bereitgestellten Authentifizierungskontext.

Bereitschaft für den Betrieb

  • Führe vor der Veröffentlichung Sicherheits-Reviews durch, insbesondere wenn du Daten verarbeitest, die regulatorischen Vorgaben unterliegen.
  • Achte auf ungewöhnliche Muster im Datenverkehr und richte Warnmeldungen für wiederholte Fehler oder fehlgeschlagene Authentifizierungsversuche ein.
  • Halte Abhängigkeiten von Drittanbietern, Bibliotheken und Build-Tools mit Patches aktuell, um Risiken in der Software-Lieferkette zu verringern.

Sicherheit und Datenschutz bilden die Grundlage für das Vertrauen der Nutzenden. Verankere sie von Anfang an in deinen Abläufen für Planung, Implementierung und Bereitstellung, statt sie erst nachträglich zu berücksichtigen.