Qu'est-ce que la sécurité des clés d'API ?

Une clé d’API est une chaîne unique qui identifie l’app appelant une API ; la sécurité des clés d’API consiste à en limiter la portée et à la protéger. La précision d’abord, car la plupart des définitions la brouillent : une clé identifie l’application, n’offre qu’une authentification faible (c’est un identifiant bearer — qui la détient, l’incarne) et porte une autorisation grossière (la portée qui lui a été attachée à sa création). Les utilisateurs sont authentifiés par des tokens ; les apps sont identifiées par des clés — et aucune RFC ne définit la clé d’API. C’est une convention, et c’est exactement pour cela que sa sécurité dépend de votre configuration, pas de la garantie d’un standard.

Points clés

La requête, et les deux types de clés

GET /v1/search?q=espresso HTTP/1.1
Host: api.example.com
X-Api-Key: pk_live_7f2c…      ← dans un HEADER — les URL finissent dans les logs,
                                 l'historique et les referrers

Deux espèces différentes partagent un même nom :
clé publiable     livrée dans les bundles web/mobiles · identifie l'app,
                  mesure l'usage · conçue en sachant qu'elle SERA extraite
clé secrète       côté serveur uniquement · identifiant bearer, niveau mot de passe ·
                  quiconque la détient, c'est vous

Le modèle publiable en pratique — des clés qui sont livrées parce que la sécurité se joue ailleurs :

// JavaScript / Node.js — Back4app JS SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
Parse.initialize(APP_ID, JS_KEY); // both ship in your bundle — by design
Parse.serverURL = 'https://parseapi.back4app.com';
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request

// The one key that never ships: the Master Key bypasses every ACL and CLP.
// Server-only (Cloud Code / trusted backend), read from env or secret manager.

// Flutter / Dart — Back4app Flutter SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
await Parse().initialize(
  appId, // ships in the app — by design
  'https://parseapi.back4app.com',
  clientKey: clientKey, // publishable, extractable, NOT a secret
);
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request
// The Master Key bypasses every ACL and CLP: server-only, never in the app.

// iOS / Swift — Back4app Swift SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
ParseSwift.initialize(
    applicationId: appId,  // ships in the IPA — by design
    clientKey: clientKey,  // publishable, extractable, NOT a secret
    serverURL: URL(string: "https://parseapi.back4app.com")!
)
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request
// The Master Key bypasses every ACL and CLP: server-only, never in the app.

// Android / Kotlin — Back4app Android SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
Parse.initialize(
    Parse.Configuration.Builder(context)
        .applicationId(APP_ID) // ships in the APK — by design
        .clientKey(CLIENT_KEY) // publishable, extractable, NOT a secret
        .server("https://parseapi.back4app.com")
        .build()
)
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request
// The Master Key bypasses every ACL and CLP: server-only, never in the app.

Clés d’API vs. tokens vs. JWT

La comparaison se résume en une phrase à retenir : les clés identifient des apps ; les tokens authentifient des utilisateurs. Utiliser une clé là où l’identité de l’utilisateur compte revient à reconstruire l’authentification en moins bien ; utiliser des tokens par utilisateur pour compter l’usage anonyme d’une app, c’est de la machinerie sans objet.

Où vivent les clés : l’échelle du stockage

Codée en dur — jamais. Le code source est copié, forké et commité ; git se souvient pour toujours, et les bots de détection de secrets trouvent les clés dans les commits publics en quelques minutes. Les variables d’environnement — le minimum, avec la réserve sur laquelle le cheat sheet de l’OWASP est sans détour : les variables d’environnement fuient par les logs d’erreur, les dumps de processus et les définitions de conteneurs ; elles gardent les secrets hors de git, pas hors de danger. Un gestionnaire de secrets — le standard d’équipe : chiffré au repos, à accès contrôlé par service, audité à chaque lecture, avec une rotation centralisée (les options open-source incluent Vault, SOPS et Infisical). Ajoutez l’hygiène qui rend les fuites survivables : des clés générées de façon cryptographiquement aléatoire, préfixées (style sk_live_…) pour que les scanners les reconnaissent, hachées au repos côté fournisseur comme des mots de passe, une clé par app et par environnement — et une détection de secrets (gitleaks, trufflehog) branchée sur la CI, pour que le commit qui divulgue une clé échoue avant d’atterrir.

Le problème côté client, en toute honnêteté

Toutes les explications disent “ne mettez pas de clés secrètes dans le code client” ; presque aucune ne dit la seconde moitié : votre bundle est public. Le JavaScript web est lisible par définition ; les binaires mobiles sont décompressés et leurs chaînes extraites en routine ; l’obfuscation fait passer l’effort de quelques minutes à quelques heures, une seule fois. Deux conséquences en découlent. D’abord, les seules clés qui ont leur place dans un client sont les clés publiables — conçues pour identifier, pas pour protéger, avec la véritable autorisation appliquée côté serveur à chaque requête. Ensuite, quand un client doit utiliser un service tiers protégé par une clé secrète, le secret reste derrière votre propre backend — le pattern proxy :

Quand une clé fuite : le runbook

Le temps compte — des bots surveillent les dépôts publics et exploitent les clés commitées en une à cinq minutes. Dans l’ordre : 1 · Révoquez la clé chez le fournisseur — avant d’enquêter, avant le stand-up. 2 · Remplacez — émettez la nouvelle clé et déployez-la par la configuration, pas par le code. 3 · Purgez — retirez-la du code source et de l’historique git ; une ligne supprimée survit dans chaque clone. 4 · Auditez — les logs du fournisseur sur la fenêtre de fuite : ce qui a été lu, créé, dépensé. 5 · Élargissez — tout ce qui cohabitait avec la clé (le même .env, le même dépôt) est présumé compromis ; faites-le tourner aussi. Et la réserve qui sépare une vraie réponse d’un rituel : la révocation arrête l’usage futur — elle ne fait pas revenir les données exfiltrées. Ce qui a été pris pendant la fenêtre est un incident, pas une rotation.

La rotation sans interruption de service

La rotation plafonne la valeur des fuites non détectées — une clé volée à qui il reste 60 jours n’est pas le même actif qu’une clé valide pour toujours. Une cadence fondée sur le risque : 30 à 90 jours pour les clés à portée large ou partagées à l’extérieur, jusqu’à un an pour les clés internes à portée étroite, immédiatement en cas de soupçon d’exposition ou de départ de quiconque l’a détenue. Le geste sans interruption, c’est le chevauchement à double clé : émettez la nouvelle clé pendant que l’ancienne reste valide, migrez les déploiements à votre rythme, puis révoquez l’ancienne — la même astuce que les systèmes de refresh tokens formalisent. Les régimes de conformité exigent de plus en plus ce calendrier ; l’argument de sécurité n’en a jamais eu besoin.

Cas d’usage courants

• Intégration de serveur à serveur — l’habitat naturel de la clé : un service qui s’identifie auprès d’un autre.
• Comptage de l’usage et facturation — la clé comme l’unité que les fournisseurs comptent, limitent et facturent.
• Identification publiable des clients — des bundles d’apps qui transportent des clés faites pour être exposées, avec l’autorisation ailleurs.
• Séparation des environnements — des clés de test et de production qui tiennent les accidents de staging à l’écart des données de production.
• Confinement des abus — des rate limits par clé et la révocation comme leviers de contrôle du rayon d’impact.

Quel identifiant devriez-vous utiliser ? Matrice de décision

Limites et trade-offs

• Les clés ne prouvent pas la possession. Une chaîne bearer n’offre aucun lien cryptographique avec l’appelant ; pour une authentification de service à haut niveau d’assurance, le TLS mutuel et les requêtes signées existent pour une bonne raison.
• Les identifiants statiques vieillissent mal. Sans expiration, chaque fuite reste ouverte jusqu’à ce que quelqu’un la remarque ; la rotation est le substitut manuel du cycle de vie que les tokens obtiennent gratuitement.
• Les portées grossières en partagent trop. Une clé aux permissions larges est un passe-partout ; une portée granulaire coûte de l’administration et rapporte en rayon d’impact.
• Les clés identifient, elles n’authentifient pas. Bâtir une confiance au niveau utilisateur sur une identification au niveau app, c’est le pattern de broken authentication que les auditeurs cherchent en premier.
• La dérive de l’inventaire est réelle. Les clés inutilisées d’anciennes intégrations restent valides jusqu’à leur suppression — les cousins identifiants-zombies des endpoints zombies.

Les clés d’API sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Son modèle de clés est la section côté client rendue concrète : l’Application ID et les clés client sont livrés dans vos apps par conception — la documentation de Back4app est explicite : les clés client ne sont pas des mécanismes de sécurité — parce que l’autorisation n’en dépend jamais : chaque requête est vérifiée côté serveur par rapport aux permissions au niveau de la classe et aux ACL, si bien qu’une clé extraite donne à un attaquant exactement ce qu’obtient un utilisateur anonyme. Le seul vrai secret est la Master Key, qui contourne toutes les ACL et CLP : elle vit uniquement côté serveur — Cloud Code, backends de confiance, variables d’environnement ou gestionnaire de secrets — et jamais dans un bundle. Les onglets de code montrent cette répartition en pratique ; le runbook ne s’applique qu’à la master key, et c’est tout l’intérêt : un seul secret à garder, c’est une posture de sécurité ; quarante, c’est un tableur.