Sécuriser ses clés API en production : les erreurs que 90% des développeurs font

Un audit de 200 projets open-source réalisé par GitGuardian en 2023 a trouvé des secrets exposés dans 1 projet sur 10. Clés API en dur dans le code, fichiers .env committés, tokens dans les logs CI/CD — les erreurs sont souvent les mêmes. Voici les 8 erreurs les plus fréquentes que commettent les développeurs sur la sécurisation des clés API en production, avec la correction pour chacune.

Erreur #1 — Mettre la clé API directement dans le code front-end

C’est l’erreur la plus classique. La clé est visible dans le HTML ou dans un fichier JavaScript téléchargé par le navigateur. N’importe qui peut l’extraire avec les DevTools en 30 secondes.

// ❌ À ne JAMAIS faire
const apiKey = "AIzaSyBxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
const map = new google.maps.Map(document.getElementById('map'), {
  zoom: 8,
  key: apiKey
});

La correction : Pour les APIs front-end comme Google Maps, utilisez les restrictions de referrer HTTP dans Google Cloud Console (APIs & Services → Credentials → Edit API Key → HTTP referrers). La clé sera visible, mais inutilisable depuis un autre domaine. Pour les APIs qui ne nécessitent pas d’être côté client, créez un proxy backend.

Erreur #2 — Committer un fichier .env sur Git

Le fichier .env contient vos secrets locaux. Si vous le committez par erreur — même une seule fois, même sur un repo privé — les secrets sont dans l’historique Git pour toujours (jusqu’à un rebase). Des bots scannent GitHub en continu et trouvent ces clés en quelques minutes.

# Vérifier si .env est dans votre .gitignore
cat .gitignore | grep .env

# Si .env a déjà été committé, le retirer de l'historique
git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch .env" \
  --prune-empty --tag-name-filter cat -- --all

# Force push (coordination avec l'équipe requise)
git push origin --force --all

La correction : Ajoutez .env et .env.local à votre .gitignore dès le début du projet. Committez uniquement un fichier .env.example avec des valeurs fictives. Utilisez un outil de gestion de secrets (AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Doppler) pour les environnements partagés.

Erreur #3 — Utiliser une seule clé pour tout

Une seule clé qui gère production, staging, développement et CI/CD. Si elle fuite, tout est compromis. Et auditer qui utilise quoi devient impossible.

La correction : Créez une clé par environnement et par usage. Production, staging, développement ont chacun leur clé. Le CI/CD a sa propre clé avec des permissions minimales (lecture seule si possible). Configurez chaque clé avec les restrictions appropriées à son contexte.

Erreur #4 — Clés sans restriction de scope

Une clé Google Cloud sans restriction de scope peut appeler n’importe quelle API activée sur votre projet. Si votre clé Maps est volée, elle peut potentiellement accéder à vos APIs Cloud Storage, Cloud Functions ou Cloud Run si elles sont activées sur le même projet.

La correction : Dans APIs & Services → Credentials → Edit API Key → API restrictions, sélectionnez « Restrict key » et ajoutez uniquement les APIs nécessaires. Principe du moindre privilège appliqué aux clés.

Erreur #5 — Pas de rotation de clés

Une clé non tournée peut avoir été exposée sans que vous le sachiez — dans un log, une erreur stacktrace, un email de debug. La durée de vie d’une clé augmente mécaniquement le risque d’exploitation silencieuse.

La correction : Mettez en place une rotation mensuelle ou trimestrielle. Avec Google Secret Manager, vous pouvez stocker plusieurs versions d’un secret et déprécier les anciennes :

# Créer une nouvelle version d'un secret
echo -n "NOUVELLE_CLE_API" | gcloud secrets versions add mon-secret \
  --data-file=- \
  --project=VOTRE_PROJECT_ID

# Désactiver l'ancienne version
gcloud secrets versions disable 1 \
  --secret=mon-secret \
  --project=VOTRE_PROJECT_ID

Erreur #6 — Pas de monitoring des appels API

Sans monitoring, une clé compromise peut être utilisée pendant des semaines sans que vous le sachiez. Vous découvrez le problème sur la facture du mois suivant.

La correction : Configurez des alertes Cloud Monitoring sur le nombre d’appels API. Dans Monitoring → Alerting → Create Policy, créez une alerte quand le nombre d’appels dépasse votre baseline normale × 2. Exportez aussi les logs API vers BigQuery pour une analyse historique.

# Créer une policy d'alerte pour les appels API anormaux
gcloud monitoring policies create \
  --notification-channels=CHANNEL_ID \
  --display-name="Anomalie appels API" \
  --condition-display-name="API calls spike" \
  --condition-filter='metric.type="serviceruntime.googleapis.com/api/request_count" resource.type="api"' \
  --condition-threshold-value=10000 \
  --condition-threshold-duration=300s

Erreur #7 — Exposer des clés dans les logs CI/CD

Les logs de build GitHub Actions, CircleCI ou GitLab CI sont parfois publics. Si votre workflow affiche des variables d’environnement dans les logs — même accidentellement via un echo ou un stacktrace — les clés sont exposées.

# ❌ À éviter dans vos workflows CI/CD
run: echo "API Key: $API_KEY"  # NE JAMAIS FAIRE

# ✅ Utilisez les secrets GitHub Actions
# Dans Settings → Secrets → Actions → New repository secret
# Puis dans votre workflow :
jobs:
  deploy:
    steps:
      - name: Deploy
        env:
          API_KEY: ${{ secrets.GOOGLE_API_KEY }}
        run: ./deploy.sh  # Le secret n'apparaît jamais dans les logs

Erreur #8 — Pas de plan d’urgence documenté

Quand une clé fuite à 23h un vendredi, personne ne sait quoi faire. Chaque minute de panique supplémentaire coûte de l’argent. L’absence de runbook est une erreur opérationnelle autant que technique.

La correction : Documentez une procédure d’incident qui répond à ces questions : Où sont listées toutes les clés API du projet ? Qui a les permissions pour les révoquer ? Quel est le contact support Google ? Comment est-ce qu’on réactive la facturation après un kill switch ? Cette procédure doit tenir sur une page et être accessible à toute l’équipe à n’importe quelle heure.

Récapitulatif des corrections

• ☑ Clés front-end restreintes par referrer HTTP — jamais hardcodées
• ☑ .env dans .gitignore, secrets dans un gestionnaire dédié
• ☑ Une clé par environnement et par usage
• ☑ Restrictions de scope API sur toutes les clés
• ☑ Rotation mensuelle ou trimestrielle
• ☑ Monitoring des appels API avec alertes d’anomalie
• ☑ Secrets CI/CD via les vaults natifs (GitHub Secrets, etc.)
• ☑ Runbook d’incident documenté et accessible

---