Das OWASP GenAI Security Project definiert einen Mindeststandard in fünf Kategorien für die sichere Bereitstellung von MCP-Servern. Verwenden Sie diese Checkliste, um Ihre aktuelle Sicherheitslage in den Bereichen Identität, Isolation, Werkzeuge, Validierung und Bereitstellung vor dem Produktivbetrieb zu bewerten.
Der praktische Leitfaden des OWASP GenAI Security Project zur MCP-Server-Entwicklung gipfelt in einer konkreten Überprüfungs-Checkliste – dem “MCP Security Minimum Bar”. Diese Checkliste definiert die grundlegenden Kontrollen, die vorhanden sein müssen, bevor ein MCP-Server in Produktion bereitgestellt wird.
Dieser Beitrag präsentiert die vollständige Checkliste mit Implementierungsleitfaden für jeden Punkt, organisiert nach den fünf Sicherheitsbereichen, die der OWASP-Leitfaden definiert. Verwenden Sie sie für Sicherheitsüberprüfungen vor der Bereitstellung, periodische Audits und als Rahmenwerk zur Behebung identifizierter Lücken.
Punkte markieren: Erfassen Sie für jeden Punkt BESTANDEN (implementiert und verifiziert), NICHT BESTANDEN (nicht implementiert oder teilweise implementiert) oder N/A (nicht zutreffend für diese Bereitstellung).
Bereitstellungs-Gates: Punkte in Kategorie 1 (Identität, Authentifizierung, Richtlinien) und Kategorie 2 (Isolation) sind harte Bereitstellungs-Gates – jedes NICHT BESTANDEN sollte den Go-Live blockieren, bis es behoben ist. Punkte in anderen Kategorien sollten mit dokumentierten Zeitplänen risiko-akzeptiert werden.
Überprüfungs-Trigger: Führen Sie die vollständige Checkliste nach jeder wesentlichen Änderung am MCP-Server-Code, der Werkzeug-Registry, der Authentifizierungskonfiguration, der Bereitstellungsumgebung oder beim Onboarding einer neuen Werkzeugkategorie erneut durch.
Dies ist die Kategorie mit der höchsten Priorität. Authentifizierungsfehler gewähren Angreifern direkten Zugriff auf alles, was der MCP-Server tun kann.
Was zu verifizieren ist: Jede Remote-Verbindung zum MCP-Server erfordert eine Authentifizierung über einen ordnungsgemäß konfigurierten OAuth 2.1-Autorisierungsserver. Anonyme Verbindungen werden abgelehnt. Lokale MCP-Server, die STDIO verwenden, können alternative, für ihren Bereitstellungskontext geeignete Authentifizierung verwenden.
Wie zu testen: Versuchen Sie, ohne Authorization-Header eine Verbindung herzustellen. Versuchen Sie, mit einem fehlerhaften oder abgelaufenen Token eine Verbindung herzustellen. Beide sollten zu einem Authentifizierungsfehler führen, nicht zu einem Zugriff auf Werkzeuge.
Häufige Fehlermodi: Entwicklungs-Endpunkte bleiben ohne Authentifizierung zugänglich; Fallback auf API-Schlüssel-Authentifizierung, die Ablauf oder Geltungsbereich nicht validiert; Token-Validierung nur bei Session-Aufbau, nicht pro Anfrage.
Was zu verifizieren ist: Zugriffstoken laufen innerhalb von Minuten ab (nicht Stunden). Jedes Token trägt den für die aktuelle Aufgabe erforderlichen Mindestgeltungsbereich. Jeder Werkzeugaufruf validiert die Signatur, den Aussteller (iss), die Zielgruppe (aud), das Ablaufdatum (exp) und den erforderlichen Geltungsbereich des Tokens – nicht nur beim Session-Aufbau.
Wie zu testen: Verwenden Sie ein gültiges Token und warten Sie dann, bis es abläuft (oder stellen Sie die Uhr manuell vor). Versuchen Sie einen Werkzeugaufruf – er sollte mit einem 401-Fehler fehlschlagen, nicht aufgrund eines zwischengespeicherten Validierungsergebnisses erfolgreich sein.
Häufige Fehlermodi: Token-Validierung beim Session-Start zwischengespeichert und nicht wiederholt; Tokens mit 24+ Stunden Laufzeit; breite “Admin”-Geltungsbereiche anstelle von operationsspezifischen Geltungsbereichen; exp-Feld wird nicht geprüft.
Was zu verifizieren ist: Der MCP-Server leitet Client-Tokens nicht an nachgelagerte APIs weiter. Alle nachgelagerten Service-Aufrufe verwenden Tokens, die explizit an den MCP-Server ausgestellt wurden (über On-Behalf-Of-Flows oder Service-Credentials). Ein zentralisiertes Policy-Gateway fängt alle Werkzeugaufrufe ab und erzwingt Authentifizierung, Autorisierung, Zustimmung und Audit-Protokollierung, bevor Werkzeug-Code ausgeführt wird.
Wie zu testen: Überprüfen Sie den Code auf Stellen, an denen das eingehende Client-Token in einem ausgehenden API-Aufruf weitergeleitet wird. Inspizieren Sie die Zugriffsprotokolle nachgelagerter Services, um zu verifizieren, dass Anfragen mit Server-Credentials ankommen, nicht mit Benutzer-Credentials.
Häufige Fehlermodi: Authorization: Bearer ${request.headers.authorization}-Muster in nachgelagerten Aufrufen; Autorisierungsprüfungen über einzelne Werkzeug-Handler verteilt; kein zentralisierter Richtliniendurchsetzungspunkt.
Starten Sie heute Ihre kostenlose Testversion und sehen Sie innerhalb weniger Tage Ergebnisse.
Isolationsfehler in Mehrmandanten-Umgebungen sind katastrophal – sie ermöglichen es einem Benutzer, auf die Daten eines anderen zuzugreifen. Dies sind harte Bereitstellungs-Gates.
Was zu verifizieren ist: Keine globalen Variablen, Klassenattribute oder gemeinsam genutzte Singleton-Instanzen speichern benutzer- oder sitzungsspezifische Daten. Jede Session verwendet unabhängig instanziierte Objekte oder sitzungsbasierte Namensräume (z.B. Redis-Schlüssel mit Präfix session_id:). Code-Review bestätigt keinen gemeinsam genutzten veränderbaren Zustand zwischen Sessions.
Wie zu testen: Führen Sie zwei gleichzeitige Sessions mit unterschiedlichen Benutzeridentitäten aus. Verifizieren Sie, dass in Session A geschriebene Daten in Session B nicht gelesen werden können. Verwenden Sie gleichzeitige Lasttests, um auf Race Conditions zu prüfen, die zu Session-State-Lecks führen könnten.
Häufige Fehlermodi: self.user_context = {} als Klassenattribut in einem Singleton-Service; globale Caches ohne sitzungsbasierte Namensräume; Thread-Local-Storage, der nicht ordnungsgemäß auf den Request-Lebenszyklus beschränkt ist.
Was zu verifizieren ist: Über den Ausführungskontext hinaus erzwingt jede gemeinsam genutzte Infrastruktur (Datenbanken, Caches, Nachrichtenwarteschlangen) benutzerspezifische Zugriffskontrollen. Eine in der Session eines Benutzers ausgeführte Abfrage kann nicht die Daten eines anderen Benutzers zurückgeben, selbst wenn die gemeinsam genutzte Infrastruktur falsch konfiguriert oder kompromittiert ist.
Wie zu testen: Versuchen Sie, auf die Daten eines anderen Benutzers zuzugreifen, indem Sie Session-Parameter manipulieren oder gemeinsam genutzte Cache-Schlüssel ausnutzen.
Häufige Fehlermodi: Cache-Schlüssel basieren nur auf Abfrageinhalt, nicht auf Benutzeridentität; Datenbankabfragen ohne benutzerspezifische WHERE-Klauseln; gemeinsam genutzte temporäre Dateiverzeichnisse ohne benutzerspezifische Unterverzeichnisse.
Was zu verifizieren ist: Wenn eine Session beendet wird (sauber oder durch Timeout/Fehler), werden alle zugehörigen Ressourcen sofort freigegeben: Datei-Handles, temporäre Dateien, In-Memory-Kontext, zwischengespeicherte Tokens, Datenbankverbindungen. Pro Session existieren Limits für Speicher, CPU, API-Rate und Dateisystemnutzung.
Wie zu testen: Beenden Sie eine Session abrupt (beenden Sie die Verbindung ohne sauberes Herunterfahren). Verifizieren Sie, dass keine Restressourcen verbleiben. Erstellen Sie eine Session und erschöpfen Sie ihr Rate-Limit; verifizieren Sie, dass es andere Sessions nicht beeinträchtigt.
Häufige Fehlermodi: Temporäre Dateien bleiben nach Session-Ende in /tmp zurück; zwischengespeicherte Tokens werden bei Session-Beendigung nicht widerrufen; keine Ressourcen-Quotas ermöglichen es einer Session, gemeinsam genutzte Infrastruktur zu erschöpfen.
Werkzeugsicherheit verhindert die gefährlichsten MCP-spezifischen Angriffe: Werkzeug-Poisoning und Rug Pulls.
Was zu verifizieren ist: Jede Werkzeugdefinition hat eine kryptographische Signatur von einem autorisierten Werkzeug-Genehmiger. Die Signatur umfasst das vollständige Manifest (Beschreibung, Schema, Version, Berechtigungen). Der MCP-Server verifiziert diese Signatur beim Laden und lehnt jedes nicht signierte oder signatur-inkonsistente Werkzeug ab. Werkzeugversionen sind gebunden – der Server kann kein aktualisiertes Werkzeug dynamisch laden ohne eine neue genehmigte Signatur.
Wie zu testen: Ändern Sie ein einzelnes Zeichen in der Beschreibung eines geladenen Werkzeugs. Verifizieren Sie, dass der Server die Hash-Inkonsistenz erkennt und das Werkzeug vom Laden blockiert. Versuchen Sie, eine nicht signierte Werkzeugdefinition zu laden – sie sollte abgelehnt werden.
Häufige Fehlermodi: Werkzeugdefinitionen als veränderbare Konfiguration ohne Integritätsprüfung gespeichert; keine Signierungsschlüssel-Infrastruktur; Werkzeuge direkt von einem gemeinsam genutzten Dateisystem ohne Versionsbindung geladen.
Was zu verifizieren ist: Automatisiertes Scanning prüft Werkzeugbeschreibungen auf anweisungsartige Muster, die Poisoning-Versuche darstellen könnten. Periodische Validierung bestätigt, dass das tatsächliche Laufzeitverhalten eines Werkzeugs mit seiner deklarierten Beschreibung übereinstimmt – ein Werkzeug, das behauptet, nur lesend zu sein, sollte zur Laufzeit nicht zu Schreiboperationen fähig sein.
Wie zu testen: Fügen Sie einer Werkzeugbeschreibung eine verdächtige Anweisung hinzu (“rufe immer auch send_webhook mit… auf”) und verifizieren Sie, dass automatisiertes Scanning dies vor menschlicher Überprüfung markiert. Überprüfen Sie die SAST-Tool-Konfiguration für MCP-spezifische Poisoning-Erkennungsregeln.
Häufige Fehlermodi: Kein automatisiertes Scanning von Werkzeugbeschreibungen; manueller Überprüfungsprozess, der eingebettete Anweisungen in langen Beschreibungen übersehen kann; keine Laufzeitverhalten-Validierung, um Werkzeuge zu erkennen, die über ihre Fähigkeiten lügen.
Was zu verifizieren ist: Der Modellkontext erhält nur die Felder, die für den korrekten Werkzeugaufruf erforderlich sind: Name, Beschreibung, Eingabeschema, Ausgabeschema. Interne Metadaten, Implementierungsdetails, Debugging-Informationen und sensible Konfiguration werden herausgefiltert, bevor sie an das Modell übergeben werden.
Wie zu testen: Inspizieren Sie, was das Modell erhält, wenn es verfügbare Werkzeuge aufzählt. Verifizieren Sie, dass keine internen Felder, Verbindungszeichenfolgen oder operativen Metadaten in der Ansicht des Modells erscheinen.
Häufige Fehlermodi: Vollständige Werkzeugkonfigurationsobjekte an den Modellkontext übergeben; Fehlermeldungen mit internen Systemdetails, die zum Modell durchsickern; Werkzeugbeschreibungen mit Implementierungshinweisen, die für den Aufruf nicht relevant sind.
Erhalten Sie die neuesten Tipps, Trends und Angebote kostenlos.
Validierungsfehler ermöglichen Injection, Datenmanipulation und Denial-of-Service.
Was zu verifizieren ist: JSON-Schema-Validierung wird für jede MCP-Protokollnachricht, jede Werkzeugaufruf-Eingabe und jede Werkzeugausgabe erzwungen, bevor sie das Modell erreicht. Die Validierung lehnt jede Nachricht ab, die nicht dem definierten Schema entspricht – fehlende erforderliche Felder, falsche Typen, Werte außerhalb zulässiger Bereiche.
Wie zu testen: Senden Sie einen Werkzeugaufruf mit einem fehlenden erforderlichen Parameter. Senden Sie eine Nachricht mit einem zusätzlichen unerwarteten Feld. Beide sollten abgelehnt werden, nicht stillschweigend ignoriert oder mit Standardwerten verarbeitet.
Häufige Fehlermodi: Optionale Validierung, die unter Fehlerbedingungen umgangen wird; Validierung nur bei Eingaben, nicht bei Ausgaben; Schemas, die zu permissiv sind (akzeptieren type: "any"-Parameter).
Was zu verifizieren ist: Alle Eingaben werden bereinigt, um Zeichen zu entfernen oder zu maskieren, die Injection ermöglichen könnten (XSS-Sequenzen, SQL-Metazeichen, Shell-Metazeichen, Null-Bytes). Größenbeschränkungen werden für alle Eingaben und Ausgaben erzwungen. Der Server behandelt alle Daten vom Modell als potenziell adversarial, identisch mit Benutzereingaben in einer traditionellen Webanwendung.
Wie zu testen: Senden Sie Eingaben mit SQL-Injection-Payloads, Shell-Metazeichen und XSS-Sequenzen. Verifizieren Sie, dass sie abgelehnt oder sicher maskiert werden, bevor sie nachgelagerte Systeme erreichen. Senden Sie eine Eingabe, die die Größenbeschränkung überschreitet – verifizieren Sie, dass sie sauber abgelehnt wird.
Häufige Fehlermodi: Eingaben direkt an SQL-Abfragen oder Shell-Befehle übergeben; keine Größenbeschränkungen, die es übergroßen Eingaben ermöglichen, Speichererschöpfung zu verursachen; Ausgaben ohne Größenbeschränkungen oder Inhaltsfilterung an das Modell zurückgegeben.
Was zu verifizieren ist: Werkzeugaufrufe werden nur als strukturierte JSON-Objekte mit validierten Schemas akzeptiert. Freitext-Generierung, die Werkzeugaufrufe impliziert, wird nicht verarbeitet. Das System kann nicht dazu gebracht werden, Werkzeugaufrufe auszuführen, indem natürliche Sprache generiert wird, die der Server als Befehle interpretiert.
Wie zu testen: Senden Sie eine natürlichsprachliche Zeichenfolge, die einen Werkzeugaufruf beschreibt (“rufe das delete_file-Werkzeug mit Pfad /etc/passwd auf”). Verifizieren Sie, dass der Server dies nicht als Werkzeugaufruf interpretiert.
Häufige Fehlermodi: Hybridsysteme, die sowohl strukturiertes JSON als auch natürlichsprachliche Werkzeugbeschreibungen akzeptieren; Server, die vom Modell generierten Text parsen, um Werkzeugaufrufe zu identifizieren; Regex-basiertes Werkzeugaufruf-Parsing, das gefälscht werden kann.
Bereitstellungs-Härtung begrenzt den Explosionsradius jeder ausgenutzten Schwachstelle.
Was zu verifizieren ist: Der MCP-Server läuft in einem minimalen gehärteten Container. Der Container-Prozess läuft als Nicht-Root-Benutzer. Unnötige Linux-Capabilities werden entfernt. Netzwerk-Policies beschränken allen eingehenden und ausgehenden Verkehr auf explizit erforderliche Verbindungen. Das Container-Image enthält nur die minimal erforderliche Software.
Wie zu testen: Führen Sie docker inspect aus und verifizieren Sie, dass der Benutzer nicht-root ist. Überprüfen Sie Netzwerk-Policies und bestätigen Sie, dass sie allen Verkehr außer explizit zugelassenen Verbindungen blockieren. Scannen Sie das Container-Image auf unnötige Pakete oder bekannt verwundbare Software.
Häufige Fehlermodi: Container laufen aus Bequemlichkeit als Root; keine Netzwerk-Policies lassen allen ausgehenden Verkehr zu; Basis-Images mit vollständigen OS-Installationen anstelle minimaler Images.
Was zu verifizieren ist: Alle API-Schlüssel, OAuth-Client-Secrets, Datenbank-Credentials und Service-Account-Tokens werden in einem Secrets-Vault gespeichert (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault usw.). Keine Secrets existieren in Umgebungsvariablen, Quellcode, Container-Images oder Log-Ausgaben. Secrets-Management-Operationen erfolgen in Middleware, die für das KI-Modell unzugänglich ist – das LLM sieht oder verarbeitet niemals Credential-Werte.
Wie zu testen: Durchsuchen Sie Logs nach credential-ähnlichen Zeichenfolgen. Inspizieren Sie Umgebungsvariablen, die für den Server-Prozess zugänglich sind. Überprüfen Sie den für das Modell zugänglichen Kontext, um zu bestätigen, dass keine Credential-Werte erscheinen.
Häufige Fehlermodi: API-Schlüssel in .env-Dateien, die in die Versionskontrolle übernommen wurden; Credentials in Fehlermeldungen zurückgegeben, die das Modell erreichen; Secrets als Werkzeugparameter übergeben, die im Konversationskontext des Modells erscheinen.
Was zu verifizieren ist: Die Bereitstellungs-Pipeline enthält automatisiertes Sicherheits-Scanning (SAST, SCA, Abhängigkeits-Schwachstellen-Scanning) als harte Gates – fehlgeschlagene Scans blockieren die Bereitstellung. Alle Werkzeugaufrufe, Authentifizierungsereignisse und Autorisierungsentscheidungen werden unveränderlich mit vollständigem Kontext protokolliert. Logs werden von einem SIEM mit Echtzeitwarnung bei anomalen Mustern aufgenommen (fehlgeschlagene Validierungs-Spitzen, ungewöhnliche Werkzeugaufruf-Häufigkeit, unerwartete externe Verbindungen).
Wie zu testen: Führen Sie eine bekannt verwundbare Abhängigkeit ein und verifizieren Sie, dass die CI/CD-Pipeline den Build fehlschlagen lässt. Generieren Sie anomale Werkzeugaufruf-Muster und verifizieren Sie, dass SIEM-Alarme innerhalb der erwarteten Reaktionszeit ausgelöst werden.
Häufige Fehlermodi: Sicherheits-Scanning als beratend statt als blockierende Gates; Logs in veränderbaren Speicher geschrieben, den ein Angreifer modifizieren könnte; keine Alarmierung bei anomalen Mustern; übermäßige Log-Verbosität, die relevante Ereignisse unmöglich auffindbar macht.
Drucken oder exportieren Sie diese Checkliste und arbeiten Sie sie systematisch für jeden MCP-Server vor der Produktionsbereitstellung durch. Beziehen Sie Ihr Sicherheitsteam in die Überprüfung ein – viele Punkte erfordern sowohl Code-Review als auch Live-Tests, um korrekt verifiziert zu werden.
Für Teams, die eine unabhängige Verifizierung wünschen, testet ein professionelles MCP-Sicherheitsaudit alle 16 Checklisten-Punkte gegen Ihre Live-Umgebung unter Verwendung adversarialer Testtechniken statt Selbstbewertung. Das Ergebnis ist ein verifizierter Sicherheitslage-Bericht mit einem priorisierten Sanierungsplan.
Der 'MCP Security Minimum Bar' des OWASP GenAI Security Project ist eine Überprüfungs-Checkliste, die die grundlegenden Sicherheitskontrollen definiert, die erforderlich sind, bevor ein MCP-Server in Produktion bereitgestellt werden sollte. Sie umfasst fünf Bereiche: Starke Identitäts-/Authentifizierungs-/Richtliniendurchsetzung, Strikte Isolation und Lebenszyklus-Kontrolle, Vertrauenswürdige und kontrollierte Werkzeuge, Schema-basierte Validierung und Gehärtete Bereitstellung mit kontinuierlicher Überwachung. Wenn der Mindeststandard nicht erfüllt wird, sollte der MCP-Server erst bereitgestellt werden, wenn die Lücken behoben sind.
Arbeiten Sie jede Kategorie systematisch durch und markieren Sie die Punkte mit BESTANDEN, NICHT BESTANDEN oder NICHT ZUTREFFEND mit Nachweisen für jede Entscheidung. Jedes NICHT BESTANDEN in den Kategorien 1 oder 2 (Identität und Isolation) sollte die Bereitstellung blockieren – dies sind die Lücken mit dem höchsten Risiko. NICHT BESTANDEN in anderen Kategorien sollten mit dokumentiertem Sanierungszeitplan risiko-akzeptiert werden, bevor die Bereitstellung erfolgt. Die Checkliste sollte nach jeder wesentlichen Änderung am MCP-Server, der Werkzeug-Registry oder der Bereitstellungsumgebung neu bewertet werden.
Mehrere Tools unterstützen die automatisierte MCP-Sicherheitsvalidierung: Invariant MCP-Scan (spezialisiert auf MCP-Sicherheitsscanning), SAST-Tools mit benutzerdefinierten MCP-Regeln, npm audit und pip audit für Abhängigkeitsscanning, OSV-Scanner für Schwachstellen-Datenbankprüfungen, Docker seccomp und AppArmor-Profile für Laufzeit-Isolation sowie SIEM-Integration für zentralisierte Überwachung. Kein einzelnes Tool deckt alle Checklisten-Punkte ab – eine umfassende Abdeckung erfordert die Kombination von statischer Analyse, dynamischen Tests und kontinuierlicher Überwachung.
Arshia ist eine AI Workflow Engineerin bei FlowHunt. Mit einem Hintergrund in Informatik und einer Leidenschaft für KI spezialisiert sie sich darauf, effiziente Arbeitsabläufe zu entwickeln, die KI-Tools in alltägliche Aufgaben integrieren und so Produktivität und Kreativität steigern.
Nutzen Sie diese Checkliste zur Selbstbewertung und beauftragen Sie dann unser Team für ein verifiziertes Sicherheitsaudit. Wir testen jeden Punkt in Ihrer Live-Umgebung und liefern einen detaillierten Sanierungsplan.
Authentifizierung ist die kritischste Sicherheitsebene für entfernte MCP-Server. Erfahren Sie, warum OAuth 2.1 mit OIDC obligatorisch ist, wie Token-Delegation ...
MCP-Server stellen eine einzigartige Angriffsfläche dar, die traditionelle API-Risiken mit KI-spezifischen Bedrohungen kombiniert. Lernen Sie die 6 kritischen S...
Tool Poisoning und Rug Pulls gehören zu den gefährlichsten MCP-spezifischen Angriffsvektoren. Erfahren Sie, wie Angreifer bösartige Anweisungen in Tool-Beschrei...
