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: "sk-ant-api03-..." });

// ❌ Écrit dans CLAUDE.md ou des fichiers de configuration
// ANTHROPIC_API_KEY=sk-ant-api03-...

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

La bonne approche

# .env (exclu de git, stocké uniquement en local)
ANTHROPIC_API_KEY=sk-ant-api03-...
QIITA_TOKEN=06b4441b...
SLACK_BOT_TOKEN=xoxb-...
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: "Clé API Anthropic", re: /sk-ant-api\d+-[A-Za-z0-9_-]{80,}/ },
  { name: "Clé API OpenAI", re: /sk-[A-Za-z0-9]{48}/ },
  { name: "Clé d'accès AWS", re: /AKIA[0-9A-Z]{16}/ },
  { name: "Token Slack", re: /xox[baprs]-[0-9A-Za-z-]{10,}/ },
  { name: "Secret générique", re: /[Ss]ecret[_-]?[Kk]ey\s*[:=]\s*['"][^'"]{10,}['"]/ },
];

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

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)"
    ],
    "deny": [
      "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*)"
    ]
  }
}

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.

Fichier de configuration spécifique à la production

Pour les environnements de production, restreindre à la lecture seule est l’approche la plus sûre.

// .claude/settings.production.json
{
  "permissions": {
    "allow": ["Read(**)", "Glob(**)", "Grep(**)", "Bash(git log*)", "Bash(git diff*)"],
    "deny": ["Write(**)", "Edit(**)", "Bash(git push*)", "Bash(rm*)", "Bash(*deploy*)"],
    "ask": []
  }
}

# Spécifier explicitement lors du travail en production
CLAUDE_SETTINGS=.claude/settings.production.json claude

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.

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)
- [ ] settings.production.json dédié utilisé pour la production
- [ ] 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	Paramètres spécifiques à la production + 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 permissions Claude Code
• Supprimer des secrets de l’historique avec git-filter-branch
• BFG Repo Cleaner