Ein Hacker-Team gegen deine App

Was es ist und warum es zählt

Bevor du eine mit KI gebaute App startest, stellt sich immer dieselbe Frage: Gibt es ein Loch, das ich nicht sehe? Du nutzt die App von innen, mit deinem eigenen Konto, und sie funktioniert. Wer sie knacken will, schaut von außen drauf.

Claude Security ist ein offizielles Plugin für Claude Code, und es ist keine einzelne Prüfung, sondern ein Team von Agenten. Einer zeichnet die Karte deiner Architektur, einer baut das Bedrohungsmodell, also wer deine App angreifen würde, von wo aus und um was zu holen, andere suchen Schwachstellen. Jede gefundene Lücke analysieren unabhängige Prüf-Agenten, bevor sie in den Bericht kommt, deshalb bleibt der Bericht kurz und ohne Fehlalarme. Am Ende bereitet es dir die Korrekturen als Patches vor, und du spielst sie selbst ein.

Die Hacker sind im guten Sinn unecht: Das Plugin liest deinen Code in deiner Sitzung und greift weder die Live-App noch die echte Datenbank an. Es ist für alle, die bald eine App mit Daten von Menschen starten.

Der Stand, geprüft in der offiziellen Dokumentation von Claude Code am 22. Oktober 2026: Die Seite des Plugins kennzeichnet es nicht als Vorschau oder Beta, und es wird aus dem offiziellen Marketplace von Anthropic installiert. Verwechsle es nicht mit dem verwalteten Dienst gleichen Namens, der Repositorys laufend überwacht: Das ist ein eigenes Produkt, für den Enterprise-Plan.

1. Was du brauchst

• Ein bezahlter Claude-Plan, die API von Anthropic oder ein Anbieter wie Amazon Bedrock, Google Cloud oder Microsoft Foundry. Der Scan nutzt die dynamischen Workflows von Claude Code, ein Skript, das viele Agenten gleichzeitig koordiniert. Im Pro-Plan schaltest du sie über /config ein, in der Zeile Dynamic workflows.
• Python 3, aufrufbar als python3 (teste mit python3 --version). Das Plugin nutzt nur die Standardbibliothek, installiert nichts, und wenn deine Version zu alt ist, sagt es dir sein Menü.
• Git, um nur deine Änderungen zu scannen und für die Patches. Der vollständige Scan geht auch ohne. Mac, Linux oder Windows, alles passt.

Einen eigenen Schlüssel gibt es nicht: Das Plugin ruft keine Modelle selbst auf, es nutzt deine Sitzung, und die Agenten laufen auf dem Modell, das du mit /model gewählt hast. Jeder Scan zählt zu deinem Verbrauch, kann viele Tokens brauchen und verlangt, dass Claude Code bis zum Ende offen bleibt.

2. Installiere das Plugin

Starte im Projektordner Claude Code mit claude und gib ein:

/plugin install claude-security@claude-plugins-official

Es öffnet sich die Seite des Plugins, auf der du wählst, für wen du es installierst: für dich in allen Projekten, für alle im Repository oder nur für dich in diesem Repository. Steht in der Zusammenfassung „Run /reload-plugins to apply.“, gib /reload-plugins ein. Heißt es dagegen, das Plugin sei nicht im Marketplace, aktualisiere den Katalog mit /plugin marketplace update claude-plugins-official und versuche es erneut.

3. Starte den Scan

1. Gib /claude-security ein und wähle Scan codebase.
2. Das Plugin liest das Repository und bietet dir alles oder einen Teil an, zum Beispiel die API oder den Login, mit der Zahl der Dateien und den relativen Kosten jeder Option. Wenn du es nicht weißt, antworte „I don't know“, und es wählt selbst.
3. Bestätige: Vorher läuft nichts. Dann lass Claude Code offen. Die Details, Agent für Agent und mit den Tokens von jedem, siehst du unter /workflows, und dort kannst du auch alles stoppen.

Am besten läuft es im Auto-Modus, in dem ein zweites Modell die Aktionen an deiner Stelle prüft und die Agenten nicht bei jedem Schritt um Erlaubnis fragen. Bei einem großen Projekt geh Bereich für Bereich vor: Login, Zahlungen, API.

Nur die Änderungen, vor dem Mergen

Wenn du auf einem Branch arbeitest, bietet dir das Menü an, nur das zu scannen, was sich gegenüber der Basis geändert hat; du kannst auch einen einzelnen Commit oder einen deiner offenen Pull Requests verlangen. Es zählt nur, was schon committet ist. Du kannst es auch in normalen Worten verlangen:

/claude-security scanne nur die Änderungen auf meinem Branch

4. Lies den Bericht

Jeder Scan schreibt einen Ordner CLAUDE-SECURITY-<Zeitstempel> ins Repository. Das ist das Einzige, was sich am Projekt ändert, und er hat seine eigene .gitignore, damit er nicht aus Versehen in einem Commit landet. Darin:

• CLAUDE-SECURITY-RESULTS.md, der Bericht zum Lesen: Jede Lücke hat eine Kennung (F1, F2 …), die Auswirkung, ein Angriffsszenario, den Schweregrad, wie sicher der Befund ist und was zu tun ist.
• Dieselben Lücken als .jsonl für Programme und als .sarif, das Standardformat, das GitHub Code Scanning und andere Sicherheitswerkzeuge lesen, mit der CWE-Kategorie jeder Lücke.
• Ein Stempel, CLAUDE-SECURITY-REVISION-<commit>.json, der festhält, welcher Commit mit welchem Aufwand gescannt wurde, damit jeder Bericht an den Code gebunden bleibt, den er beschreibt.

Fang mit den schwersten Lücken mit hoher Sicherheit an, und lass dir vor dem Korrigieren das Szenario erklären:

Öffne den Bericht von Claude Security und erkläre mir die Lücke F1, als wüsste ich nichts über Sicherheit: wer sie ausnutzen kann, was er bekommt, über welchen Bildschirm oder welche Adresse der App es läuft und wie wahrscheinlich es ist. Sag mir, ob Daten echter Nutzer betroffen sind. Ändere nichts.

5. Die Korrekturen spielst du selbst ein

Gib erneut /claude-security ein, wähle Suggest patches und dann die Lücken. Jeder Patch entsteht in einer separaten Kopie des Repositorys und wird von einem anderen Agenten geprüft, der die Tests ausführt, falls es welche gibt. Er kommt nur, wenn er diese Lücke schließt, keine neuen öffnet und sonst nichts ändert; wenn nicht, bekommst du eine Notiz mit der Begründung.

Die Patches landen in patches/ im Bericht, einer pro Lücke (F1.patch, F2.patch …), und werden nie automatisch eingespielt. Einen spielst du im Terminal so ein:

git apply CLAUDE-SECURITY-<timestamp>/patches/F1.patch

Ein Patch pro Pull Request, damit jeder für sich geprüft und getestet wird. Oder lass es Claude machen:

Spiel den Patch F1 aus dem Bericht von Claude Security auf einem neuen Branch ein, führe die Tests aus und öffne einen Pull Request nur mit dieser Änderung. Schreib in die Beschreibung die Lücke, die Korrektur und wie du sie getestet hast.

Wenn der betroffene Code keine Tests hat, steht das in der Notiz zum Patch: Prüf ihn vor dem Mergen von Hand. Und hat sich dieser Code inzwischen geändert, wird die Lücke übersprungen, und das Plugin schlägt dir einen neuen Scan vor.

6. Die vier typischen Lücken in mit KI gebauten Apps

• Die offene Datenbank. Supabase will Row Level Security für jede freigegebene Tabelle: Ohne sie kann der öffentliche Schlüssel in der App zum Lesen und Schreiben reichen. Bei Firebase such nach allow read, write: if true, das laut Dokumentation nie in Produktion gehört. Der Live-Test: Guide PORTA (strikt.fit/porta).
• Der geheime Schlüssel im Code der App. Der von Supabase (secret oder service_role) nie im Browser, in einer veröffentlichten App oder auf GitHub. Und Variablen mit VITE_, NEXT_PUBLIC_ und EXPO_PUBLIC_ landen im Code, der im Browser oder in der App ankommt: Dort keine Schlüssel. Guide CHIAVI (strikt.fit/chiavi).
• Der Endpunkt, der nicht prüft, wer fragt. Ein Endpunkt ist eine Adresse auf dem Server, etwa /api/orders/123. Der klassische Fall: Er prüft den Login, aber nicht, dass Bestellung 123 dir gehört, also änderst du die Zahl und liest die eines anderen. Das ist das erste Risiko der OWASP API Security Top 10 von 2023. Die Prüfung gehört auf den Server, nicht in einen versteckten Button.
• Kein Limit für Anfragen. Wenn ein Endpunkt eine KI aufruft oder E-Mails oder SMS verschickt, ruft ihn jeder tausendmal auf, und die Rechnung landet bei dir: das vierte Risiko derselben Liste. Guide LIMITE (strikt.fit/limite).

Für einen ersten schnellen Blick, vor dem richtigen Scan:

Prüfe den Code dieser App auf die vier klassischen Lücken von mit KI gebauten Apps und nenne mir für jede Datei, Zeile und Schweregrad: 1) Datenbanktabellen ohne Zugriffsregeln (Row Level Security bei Supabase, Sicherheitsregeln bei Firebase) oder mit Regeln, die jeden Eingeloggten alles lesen lassen; 2) geheime Schlüssel in Code, der im Browser oder in der App landet, einschließlich der Variablen NEXT_PUBLIC_, VITE_ und EXPO_PUBLIC_; 3) Endpunkte, die nicht prüfen, wer die Anfrage stellt und ob das angefragte Objekt ihm gehört; 4) Endpunkte ohne Anfragelimit, vor allem die, die Geld kosten (KI, E-Mail, SMS). Ändere nichts und gib nie den Wert eines Schlüssels aus.

Das ist ein einziger Durchgang, ohne die Prüfer des Plugins. Und Datenbankregeln, die im Dashboard statt im Code angelegt wurden, sehen weder diese Prüfung noch das Plugin: Dafür brauchst du den Live-Test.

Häufige Fehler

• Gleich mit einem ganzen großen Repository anfangen. Wähl beim ersten Mal einen Bereich, etwa Login oder API, und schau in /workflows, wie viel er verbraucht.
• Einen Scan der Änderungen verlangen, während die Arbeit noch nicht committet ist. Er schaut nur auf Commits.
• Alle Patches auf einmal einspielen. Einer pro Pull Request, jeder geprüft und getestet.
• Einen sauberen Scan für eine sichere App halten. Scans unterscheiden sich von Lauf zu Lauf und lesen den Code, nicht die Live-Einstellungen: Wiederhole sie und mach auch die Live-Tests.
• Einen gefundenen geheimen Schlüssel aus dem Code löschen und es dabei belassen. Er muss widerrufen und ersetzt werden, weil er in der Historie bleibt.

Checkliste

• Bezahlter Plan oder API, dynamische Workflows an (bei Pro über /config).
• python3 und git funktionieren, Plugin installiert.
• Erster Scan in einem Bereich mit Daten von Menschen: Login, Zahlungen, API.
• Bericht gelesen, angefangen bei den schwersten Lücken.
• Patches einzeln pro Pull Request eingespielt, die ohne Tests von Hand geprüft.
• Die vier typischen Lücken auch an der laufenden App geprüft.
• Scan vor jedem wichtigen Launch wiederholt.

Häufige Fragen