7 Claude-Code-Sicherheitsfehler: Ursachen, Wiederherstellung, Prävention

Claude Code ist nicht nur ein Chatfenster, das Code vorschlägt. Es kann Dateien ändern, Tests ausführen, Git-Status lesen und Deployment-Befehle vorschlagen. Diese Stärke spart Zeit, aber ein müder Entwickler kann eine gefährliche Aktion auch schneller bestätigen, als er sie selbst tippen würde.

Dieser Leitfaden macht typische Sicherheitsvorfälle zu konkreten Schutzmaßnahmen. Für Einsteiger: Eine Permission ist die Grenze dessen, was der Agent tun darf, ein Hook ist ein Kontrollpunkt vor oder nach einem Tool-Aufruf, und eine Sandbox ist ein isolierter Arbeitsraum mit kleinerem Schadensradius. Die Beispiele liefern ein settings.json, einen Node.js-Secret-Scanner und einen GitHub-Actions-Workflow.

flowchart TD
  Request["User request"] --> Plan["Claude Code plan"]
  Plan --> Permission["Permission rules"]
  Permission --> Hook["PreToolUse hook"]
  Hook --> Execute["Tool execution"]
  Execute --> Audit["Log, review, recovery"]
  Hook -->|block risky command| Stop["Stop before damage"]

Fehlerkarte

Fehlerfall	Typischer Auslöser	Schaden	Erste Schutzmaßnahme
.env committen	”Füge es für CI auch hinzu”	API-Key-Leak und unerwartete Kosten	.gitignore plus Scan der staged files
Produktionsdaten löschen	Migration läuft gegen falsche URL	Datenverlust	Umgebungscheck vor DB-Befehlen
git push --force	Konflikte unter Zeitdruck lösen	Team-Commits überschrieben	ask-Regeln und Branch Protection
KI-Review-Schleifen in CI	Jede PR startet breite Automatisierung	Actions- und API-Kosten	max-turns, Timeout, Least Privilege
Ungeprüfte Logs einfügen	Logs enthalten versteckte Anweisungen	Prompt Injection	Riskante Web- und Shell-Fetches verweigern
Zu breiter MCP-Zugriff	Externer Server wird zu schnell vertraut	Zu viel lokales Lesen	Nur vertrauenswürdige MCP-Server erlauben
Approval Fatigue	Bestätigungen werden durchgeklickt	Gefährliche Befehle passieren	Hooks, die sicher blockieren

Die Aussage ist nicht, dass Claude Code standardmäßig unsicher ist. Die offizielle Security-Dokumentation beschreibt lesende Standardrechte, Bestätigungsflüsse, Sandboxing und Nutzerverantwortung. Das operative Risiko entsteht, wenn Menschen unter Zeitdruck Kontrollen überspringen. Gute Konfiguration macht den sicheren Weg einfach und den riskanten Weg sichtbar.

Praxisfall 1: API-Key-Leaks in Einzelprojekten verhindern

Der häufigste Einsteigerfehler ist, .env wie einen Tresor zu behandeln. Das ist es nicht: Es ist eine lokale Textdatei. Sie ist nur relativ sicher, solange sie nicht in Git, Logs, Screenshots oder Prompts landet. Wenn ein Stripe-, SendGrid-, Anthropic- oder GitHub-Token öffentlich wird, gilt er als kompromittiert.

Committe nur die Form der Konfiguration, nicht die echten Werte.

# .gitignore
.env
.env.*
!.env.example
secrets/
*.pem
*.key
*service-account*.json
credentials.json

# .env.example
ANTHROPIC_API_KEY=replace_me
DATABASE_URL=postgres://app_user:password@localhost:5432/app_dev
STRIPE_SECRET_KEY=sk_test_replace_me

Danach werden die Claude-Code-Rechte enger gesetzt. deny blockiert, ask verlangt Bestätigung, allow genehmigt sichere Routinebefehle. Die offiziellen Seiten Settings und Configure permissions erklären die Auswertung dieser Regeln.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm run deploy *)",
      "Write(./migrations/**)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "WebFetch"
    ]
  }
}

Diese Konfiguration schaltet Claude Code nicht ab. Sie macht ungefährliche Routine schnell und destruktive Aktionen bewusst langsam. Wenn ein Projekt Webzugriff braucht, starte eng: erlaubte Domain, Zweck und Review festlegen, dann gezielt lockern.

Praxisfall 2: Team-PRs prüfbar halten

In Teams ist der gefährliche Fehler oft ein Prozessfehler. “Die KI hat es geprüft” wird dann zur Ausrede, Permission-Dateien, Workflow-Änderungen und Credential-Handling nicht mehr genau anzusehen. Genau dort rutschen Sicherheitsprobleme durch.

Dieser Scanner hat keine externen Abhängigkeiten. Standardmäßig prüft er staged files; in CI kann er mit --all das gesamte Repository prüfen.

// scripts/claude-security-check.mjs
import { execFileSync } from "node:child_process";
import fs from "node:fs";

const args = process.argv.slice(2);
const scanAll = args.includes("--all");
const explicitFiles = args.filter((arg) => arg !== "--all");

function runGit(args) {
  return execFileSync("git", args, { encoding: "utf8", maxBuffer: 10 * 1024 * 1024 });
}

function filesToScan() {
  if (explicitFiles.length > 0) return explicitFiles;
  if (scanAll) return runGit(["ls-files"]).split(/\r?\n/).filter(Boolean);
  return runGit(["diff", "--cached", "--name-only"]).split(/\r?\n/).filter(Boolean);
}

function readTrackedOrWorkingTree(file) {
  if (scanAll || explicitFiles.length > 0) return fs.readFileSync(file, "utf8");
  return runGit(["show", `:${file}`]);
}

const forbiddenPath = [
  /^\.env$/,
  /^\.env\./,
  /(^|\/)secrets\//,
  /(^|\/).*service-account.*\.json$/i,
  /(^|\/)credentials\.json$/i,
  /\.(pem|key)$/i
];

const secretPattern =
  /(sk-ant-[A-Za-z0-9_-]{20,}|sk_live_[A-Za-z0-9_-]{20,}|AKIA[0-9A-Z]{16}|-----BEGIN (?:RSA |EC |OPENSSH )?PRIVATE KEY-----)/;

let failed = false;

for (const file of filesToScan()) {
  if (forbiddenPath.some((pattern) => pattern.test(file))) {
    console.error(`[blocked] forbidden secret path: ${file}`);
    failed = true;
    continue;
  }

  try {
    const text = readTrackedOrWorkingTree(file);
    if (secretPattern.test(text)) {
      console.error(`[blocked] secret-like value found in: ${file}`);
      failed = true;
    }
  } catch {
    // Ignore deleted or binary files.
  }
}

if (failed) process.exit(1);
console.log("security check passed");

{
  "scripts": {
    "security:staged": "node scripts/claude-security-check.mjs",
    "security:all": "node scripts/claude-security-check.mjs --all"
  }
}

Die Falle ist, beim Skript aufzuhören. npm run security:staged gehört in Commit-Routine, PR-Template oder CI. Eine Bitte an Claude Code, “daran zu denken”, ist schwächer als ein Befehl, der automatisch fehlschlägt.

Praxisfall 3: Produktion und CI-Budget schützen

Produktionsvorfälle entstehen oft durch verwechselte Umgebungen. Nicht nur DROP TABLE ist das Problem, sondern es gegen die Produktions-DATABASE_URL auszuführen, während man Entwicklung erwartet. Bevor Claude Code alte Daten entfernt, sollten Datenbanklabel, Cloud-Projekt, Branch und Backup-Zeitpunkt sichtbar ausgegeben werden.

Für GitHub Actions empfiehlt die offizielle Claude Code GitHub Actions-Dokumentation, API-Keys in Secrets zu speichern und Rechte zu begrenzen. Dieser Workflow reviewt nur den PR-Diff und erhält keinen Schreibzugriff auf das Repository.

name: Claude Code guarded review

"on":
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  claude-security-review:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false

      - name: Run repository secret scan
        run: node scripts/claude-security-check.mjs --all

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: "${{ secrets.ANTHROPIC_API_KEY }}"
          prompt: >
            Review only the pull request diff for secret handling, auth checks,
            destructive commands, and permission changes. Do not modify files.
          claude_args: |
            --max-turns 3
            --disallowedTools "Bash(git push *)" "Bash(npm run deploy *)" "Bash(rm -rf *)"

permissions: contents: read ist wichtig, weil ein reiner Review-Job keinen Schreibzugriff braucht. timeout-minutes und --max-turns sind ebenfalls Sicherheitskontrollen: grenzenlose Automatisierung kann Kosten- und Verfügbarkeitsvorfälle auslösen.

Wiederherstellung nach einem Vorfall

Wenn ein API-Key geleakt ist, beginne nicht mit Git-Historie. Widerrufe oder rotiere zuerst den Schlüssel beim Anbieter. Ein bereinigtes Repository hilft nicht, wenn der Wert bereits kopiert wurde.

1. Den exponierten Schlüssel widerrufen oder rotieren.
2. Nutzungslogs und Abrechnung für das Zeitfenster prüfen.
3. GitHub Secrets, Deployment-Variablen und CI-Werte ersetzen.
4. Den Wert aus der Git-Historie entfernen und bei Bedarf Cache-Bereinigung anfragen.
5. .gitignore, Permission-Regeln und Scanner im selben Remediation-PR ergänzen.

Wenn Produktionsdaten beschädigt wurden, stoppe Schreibzugriffe oder schalte auf read-only, bevor du Korrekturen ausführst. Backup-Zeitpunkt, Restore-Ziel und akzeptablen Datenverlust zuerst festlegen. Recovery-Befehle sollten einzeln, mit menschlicher Bestätigung und Log ausgeführt werden.

Dokumentation, interne Links und nächster Schritt

Nutze die offiziellen Seiten Security, Configure permissions, Settings, Hooks und GitHub Actions als Quelle. Hooks sind besonders nützlich, weil sie vor der Tool-Ausführung eigene Prüfungen ermöglichen.

Für mehr Kontext im Blog passen /de/blog/claude-code-security-best-practices/, /de/blog/claude-code-permissions-guide/ und /de/blog/claude-code-secrets-management/ dazu.

Wenn du anpassbare Vorlagen brauchst, nutze die Materialien unter /products/. Für Team-Rollout, CI-Policy und Review-Prozess sind die Beratung und Trainings unter /training/ der passende nächste Schritt.

Im lokalen Test-Repository von Masa blockierte diese Konfiguration vor der Veröffentlichung ein versehentlich gestagtes .env, einen falschen sk_live_-String und einen zu breit berechtigten GitHub-Actions-Review-Job. Regex-Scanning erkennt nie alle Secret-Formate. Dauerhaft trägt nur ein Schichtenmodell: Rotation beim Anbieter, Least Privilege, automatische Checks und menschliche Prüfung vor der Freigabe von Claude-Code-Aktionen.