Guide Complet de Sécurité pour Claude Code : Clés API, Permissions et Protection de la Production

Claude Code dispose de puissantes capacités de manipulation de fichiers et d’exécution de commandes — mais une mauvaise configuration peut entraîner des accidents irréversibles. Commiter un fichier .env, supprimer accidentellement une base de données de production, afficher une clé API dans les logs — ce sont des incidents réels causés par l’utilisation de Claude Code sans protections adéquates.

Cet article fournit une explication au niveau de l’implémentation des meilleures pratiques de sécurité pour Claude Code. L’accent est mis non pas sur la théorie, mais sur des configurations prêtes à l’emploi et du code préventif que vous pouvez copier et appliquer immédiatement.

Pourquoi Claude Code nécessite des mesures de sécurité

Contrairement à un éditeur de texte ordinaire, Claude Code possède les capacités suivantes :

• Lire, écrire et supprimer n’importe quel fichier (Read / Write / Edit / Bash(rm))
• Exécuter des commandes shell (Bash)
• Accès réseau (WebFetch / appels API)
• Publier sur des services externes (GitHub, Slack, etc.)

Tout cela peut être exécuté avec l’approbation de l’utilisateur. Le problème est qu’approuver mécaniquement chaque prompt laisse passer des opérations non souhaitées. Les mesures de sécurité consistent à éliminer structurellement toute marge d’erreur.

Mesure 1 : Gestion des clés API — .env + .gitignore comme base

Ce qu’il ne faut PAS faire

// ❌ Écrit directement dans le code source
const client = new Anthropic({ apiKey: "PASTE_REAL_API_KEY_HERE" });

// ❌ Écrit dans CLAUDE.md ou des fichiers de configuration
// ANTHROPIC_API_KEY=PASTE_REAL_API_KEY_HERE

// ❌ Inclus dans le prompt de claude -p
// Utilise QIITA_TOKEN=PASTE_REAL_TOKEN_HERE pour publier

La bonne approche

# .env (exclu de git, stocké uniquement en local)
ANTHROPIC_API_KEY=<anthropic-api-key>
QIITA_TOKEN=<qiita-token>
SLACK_BOT_TOKEN=<slack-bot-token>
DATABASE_URL=postgresql://...

# Toujours ajouter à .gitignore
.env
.env.*
.env.local
!.env.example   # ← Le fichier d'exemple peut être commité
*.pem
*.key
credentials.json
*-service-account.json

# .env.example (sûr à commiter, valeurs vides)
ANTHROPIC_API_KEY=
QIITA_TOKEN=
SLACK_BOT_TOKEN=
DATABASE_URL=

Lecture des variables dans le code

// ✅ Lire depuis les variables d'environnement
import { config } from "dotenv";
config();

const token = process.env.QIITA_TOKEN;
if (!token) throw new Error("QIITA_TOKEN n'est pas défini. Veuillez vérifier votre fichier .env.");

Documenter les interdictions dans CLAUDE.md

## Interdictions de sécurité
- Ne jamais inclure de clés API ou de tokens dans les prompts
- Ne jamais lire et afficher le contenu des fichiers .env
- Ne jamais écrire les valeurs des variables d'environnement dans les logs ou commentaires
- Ne jamais faire console.log du contenu de process.env

Mesure 2 : Analyse des secrets avant le commit

Même avec .env dans .gitignore, des entrées accidentelles dans d’autres fichiers ou des erreurs de copier-coller peuvent survenir. Ajoutez une analyse automatique pré-commit.

Vérification pré-commit avec les Hooks

.claude/settings.json :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit*)",
        "hooks": [
          {
            "type": "command",
            "command": "node scripts/secret-scan.mjs"
          }
        ]
      }
    ]
  }
}

scripts/secret-scan.mjs :

import { execSync } from "child_process";

// Récupérer les changements en staging
const diff = execSync("git diff --cached").toString();

const PATTERNS = [
  { name: "Affectation de clé API Anthropic", re: /\b(?:ANTHROPIC_API_KEY|CLAUDE_API_KEY)\s*[:=]\s*["']?[^"'\s]{20,}/i },
  { name: "Affectation de clé API OpenAI", re: /\bOPENAI_API_KEY\s*[:=]\s*["']?[^"'\s]{20,}/i },
  { name: "Clé d'accès AWS", re: /\bAKIA[0-9A-Z]{16}\b/ },
  { name: "Token Slack", re: /\bxox[baprs]-[0-9A-Za-z-]{10,}\b/ },
  { name: "Secret générique", re: /\b(?:secret|token|api[_-]?key|password)\s*[:=]\s*["'][^"']{10,}["']/i },
];

const found = PATTERNS.filter(({ re }) => re.test(diff));

if (found.length > 0) {
  console.error("🚨 Secret détecté ! Abandon du commit :");
  found.forEach(({ name }) => console.error(`  - ${name}`));
  console.error("\nSolution : exécutez `git reset HEAD <fichier>` pour retirer le fichier du staging");
  process.exit(1);  // Code de sortie 1 → Le Hook bloque la commande
}

console.log("✓ Analyse des secrets : aucun problème détecté");
process.exit(0);

Cela signifie que dès que Claude Code tente d’exécuter git commit, une analyse automatique est lancée et toute fuite détectée est bloquée.

Mesure 3 : Configuration des modes de permissions

Les paramètres d’autorisation/refus de Claude Code peuvent être contrôlés de manière granulaire au niveau des fichiers.

Paramètres de permissions dans .claude/settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "disableBypassPermissionsMode": "disable",
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Bash(DROP TABLE*)",
      "Bash(truncate*)",
      "Bash(curl * | bash)",
      "Bash(wget * | sh)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(npm publish*)",
      "Bash(wrangler pages deploy*)"
    ]
  },
  "disableAutoMode": "disable"
}

Paramètre	Signification
allow	Exécuter sans confirmation
deny	Ne jamais exécuter (complètement bloqué)
ask	Nécessite une approbation à chaque fois

Principe clé : Les commandes destructives vont dans deny, les opérations d’écriture dans ask, les opérations de lecture dans allow.

Séparer production et politique d’organisation avec local ou managed settings

Le modèle officiel de configuration applique les scopes dans cet ordre : managed, arguments de ligne de commande, local, project, puis user. Au lieu de dépendre d’un basculement par fichier personnalisé non officiel, utilisez .claude/settings.local.json pour un terminal personnel de production plus strict et les managed settings pour les règles d’organisation.

Utilisez .claude/settings.local.json pour les surcharges locales et ne le commitez pas.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "plan",
    "disableBypassPermissionsMode": "disable",
    "allow": ["Read(**)", "Glob(**)", "Grep(**)", "Bash(git log*)", "Bash(git diff*)"],
    "deny": ["Write(**)", "Edit(**)", "Bash(git push*)", "Bash(rm*)", "Bash(*deploy*)"],
    "ask": []
  },
  "disableAutoMode": "disable"
}

Pour une politique d’équipe ou d’entreprise, placez la frontière dans les managed settings. Avec allowManagedPermissionRulesOnly, les utilisateurs et dépôts de projet ne peuvent pas redéfinir les règles allow, ask ou deny pour contourner la politique d’organisation.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "disableAutoMode": "disable",
  "allowManagedPermissionRulesOnly": true
}

Mesure 4 : Protection de l’environnement de production

Séparer explicitement les cibles de connexion

## CLAUDE.md — Règles de l'environnement de production

## Détection d'environnement
- Si DATABASE_URL contient 'prod' ou 'production', il s'agit d'un **environnement de production**
- En production, ne jamais exécuter :
  - DROP / TRUNCATE / DELETE (sans clause WHERE)
  - Migrations (confirmation préalable requise)
  - Suppressions massives de fichiers

## Flux de confirmation
Tous les changements en production doivent :
1. Être testés d'abord dans un environnement de staging
2. Recevoir la confirmation de l'utilisateur
3. Reporter les résultats après exécution

Contrôler les connexions avec les variables d’environnement

// scripts/db-query.mjs
const env = process.env.NODE_ENV ?? "development";
const dbUrl = process.env.DATABASE_URL;

if (env === "production" && process.argv.includes("--write")) {
  console.error("❌ L'écriture en production nécessite le flag --force-production");
  process.exit(1);
}

Mesure 5 : Mécanismes de sécurité pour les opérations sur les fichiers

Automatiser les sauvegardes avant la suppression

// Hooks dans .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(rm *)",
        "hooks": [
          {
            "type": "command",
            "command": "echo '⚠️  Une commande de suppression est sur le point de s'exécuter. Appuyez sur Ctrl+C pour annuler.' && sleep 3"
          }
        ]
      }
    ]
  }
}

Protéger les fichiers critiques des modifications accidentelles

## CLAUDE.md — Fichiers ne devant pas être modifiés

Les fichiers suivants ne doivent **jamais être édités** :
- .env (contient des variables d'environnement et des clés secrètes)
- wrangler.toml (configuration de production Cloudflare)
- scripts/deploy.sh (script de déploiement)
- .github/workflows/*.yml (configuration CI/CD)

Si des modifications sont nécessaires, consulter d'abord l'utilisateur.

5 pièges courants

1. Ajouter .gitignore après coup est trop tard Un fichier .env déjà commité reste dans l’historique git même après l’avoir ajouté à .gitignore.

# Suppression complète de l'historique (attention : nécessite un force push)
git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch .env" \
  --prune-empty --tag-name-filter cat -- --all

# Ou utiliser BFG Repo Cleaner

Si le fichier a déjà été poussé sur GitHub, faites toujours une rotation de vos clés API en premier avant de traiter l’historique.

2. Stocker des fichiers JSON de comptes de service dans le dépôt Les clés de compte de service pour Google Cloud ou AWS sont souvent distribuées sous forme de fichiers .json, mais les stocker dans un dépôt est dangereux. Convertissez-les en variables d’environnement ou migrez vers un Secret Manager (AWS Secrets Manager / GCP Secret Manager).

3. Exécuter des commandes interactives avec l’outil Bash Lors d’une exécution sans tête avec claude -p, les commandes nécessitant une entrée interactive comme sudo ou vim feront planter le processus. N’utilisez que des commandes non interactives.

4. Inclure des identifiants dans les messages d’erreur

// ❌ Dangereux : la clé API apparaît dans les logs
throw new Error(`Authentification échouée : token=${process.env.TOKEN}`);

// ✅ Sûr : ne pas exposer la valeur
throw new Error(`Authentification échouée : veuillez vérifier la variable d'environnement TOKEN`);

5. Réutiliser les mêmes paramètres de permissions pour tous les projets Utiliser le même settings.json pour les projets personnels et professionnels signifie que les paramètres permissifs du projet personnel peuvent écraser les exigences plus strictes du projet professionnel. Gérez .claude/settings.json séparément pour chaque projet.

Règles opérationnelles pratiques

Ne pas exposer les secrets pendant le travail courant

Lorsque vous demandez à Claude Code « corrige cette erreur », ne collez pas le log complet ni le contenu de .env. Décidez à l’avance que les clés API, tokens OAuth, cookies, URLs de base de données, emails clients, IDs de facturation et clés privées ne sont jamais copiés dans les prompts, issues ou chats.

Si Claude Code a besoin de contexte, masquez les valeurs et gardez seulement la structure. DATABASE_URL=***REDACTED*** suffit pour comprendre qu’une URL de base de données existe. La valeur réelle n’est presque jamais nécessaire pour déboguer le code applicatif.

Informations acceptables	Informations interdites
Type d’erreur, noms de fichiers dans la stack trace, étapes de reproduction	Clés API, clés privées, cookies de session, vraies valeurs .env
.env.example, noms de paramètres, règles de permissions, commande échouée	URLs de base de données production, données clients, identifiants internes
Logs masqués, données de test, valeurs locales d’exemple	Tokens réels, JSON de service account, captures contenant des secrets

Ajoutez ce tableau à CLAUDE.md pour que chaque session démarre avec la même limite. Dans une équipe, « ne pas exposer de secrets » doit être une règle opérationnelle, pas une connaissance implicite.

Doubler le scan des secrets avant commit

Le Hook PreToolUse ci-dessus bloque un commit lorsque Claude Code exécute git commit. Il ne couvre pas un humain qui commit depuis un autre terminal ni les fichiers générés en CI. En production, superposez trois contrôles : Hook Claude Code, pre-commit local et secret scan en CI qui bloque le merge.

La configuration minimale utile est de bloquer localement, revérifier en CI et faire échouer la pull request si un pattern de secret apparaît. Des outils comme gitleaks ou trufflehog sont plus adaptés à la détection à l’échelle CI, tandis que le script de cet article reste utile comme garde local rapide.

Exemples concrets d’échec

Échec 1 : lire .env pendant une investigation Un développeur a demandé à Claude Code de « vérifier les variables d’environnement » et des valeurs réelles se sont retrouvées dans la conversation ou les logs de travail. La correction est de refuser la lecture de .env et de fournir seulement .env.example.

Échec 2 : coller un token de publication Qiita dans le prompt Une tâche d’automatisation incluait QIITA_TOKEN directement dans le prompt, avec un risque de persistance dans un sous-agent ou un log. Le flux sûr consiste à garder le token dans .env et à ne faire référencer que le nom de variable d’environnement.

Échec 3 : URLs production et staging trop similaires L’instruction disait seulement « nettoie la base de données » et sautait la vérification de connexion. Si l’URL active était la production, une suppression ou migration pouvait devenir un incident. Avant toute écriture, affichez NODE_ENV, host et nom de base, puis exigez une confirmation explicite.

Premiers gestes après un incident

Si vous soupçonnez une fuite de secret, la première étape n’est pas le nettoyage de l’historique. C’est la désactivation de l’identifiant.

1. Faire tourner ou révoquer immédiatement la clé API, le token ou le mot de passe concerné
2. Vérifier les logs GitHub Actions, Cloudflare, AWS, GCP et SaaS connectés
3. Noter qui a exposé quoi, quand, dans quel dépôt et via quel canal
4. Supprimer le secret de l’historique git et des logs, puis communiquer l’impact d’un éventuel force push
5. Renforcer les règles deny, Hooks, scans CI et interdictions CLAUDE.md

En pratique, désactiver d’abord l’identifiant puis nettoyer l’historique réduit les erreurs. Pendant un incident, les gens collent souvent plus de logs pour aider ; préparez donc un modèle de log masqué avant d’en avoir besoin.

Chemin naturel vers formation et conseil

La sécurité Claude Code ne se règle pas avec un seul fichier de settings. Il faut aussi examiner structure du dépôt, CI, permissions de déploiement et flux d’approbation d’équipe.

Chez ClaudeCodeLab, le parcours individuel commence par l’hygiène .env et les permission rules. Pour les équipes, les premières questions sont où forcer les managed settings et où le secret scan CI doit bloquer les merges. Si Claude Code est déjà utilisé au travail, commencez par cartographier qui peut accéder à quels secrets avant d’affiner les permissions.

Liste de vérification de sécurité

Une liste de vérification pour configurer un projet Claude Code :

### Configuration de base
- [ ] .env créé et ajouté à .gitignore
- [ ] .env.example créé et partagé avec l'équipe
- [ ] Vérifié via git log qu'aucun secret n'est présent dans les commits existants

### Paramètres de permissions
- [ ] Liste deny configurée dans .claude/settings.json
- [ ] Commandes destructives (rm -rf, DROP TABLE, etc.) ajoutées à deny
- [ ] Commandes de déploiement en production configurées comme ask

### Automatisation
- [ ] Hook d'analyse des secrets pré-commit configuré
- [ ] Interdictions de sécurité documentées dans CLAUDE.md

### Opérations
- [ ] Calendrier de rotation des clés API établi (recommandé : tous les 90 jours)
- [ ] Travail en production limité avec .claude/settings.local.json ou managed settings
- [ ] Procédure de réponse aux incidents documentée

Résumé

La sécurité avec Claude Code ne consiste pas à « imposer des restrictions » — il s’agit de construire une structure où les accidents ne peuvent structurellement pas se produire.

Menace	Contre-mesure
Fuite de clé API	.env + .gitignore + Hook d’analyse des secrets
Suppression non souhaitée	Liste deny + Hook pré-suppression
Erreurs en production	local/managed settings + interdictions CLAUDE.md
Contamination des commits	Hook PreToolUse pour l’analyse pré-commit

Une fois configurés, ces paramètres sont pratiquement sans maintenance. Passer 30 minutes aujourd’hui peut prévenir un incident majeur à l’avenir.

Articles connexes

• Guide des permissions Claude Code
• Cas d’échecs de sécurité Claude Code
• Guide complet d’intégration Claude Code + SaaS
• Meilleures pratiques CLAUDE.md

Références

• Documentation officielle des settings Claude Code
• Documentation officielle des permissions Claude Code
• Documentation officielle server managed settings
• Supprimer des secrets de l’historique avec git-filter-branch
• BFG Repo Cleaner