---
term: "Sécurité des Clés d'API"
seoTitle: "Sécurité des clés d'API : stockage, rotation, fuites, clés côté client"
headline: "Qu'est-ce que la sécurité des clés d'API ?"
slug: securite-des-cles-d-api
category: auth-security
shortDefinition: "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."
relatedTerms:
- json-web-token-jwt
- api-rate-limiting-throttling
- cors-cross-origin-resource-sharing
- data-encryption-at-rest-transit
contrastsWith:
- json-web-token-jwt
aboutTerms:
- 'Publishable vs. Secret Keys'
- 'Key Rotation'
- 'Secrets Management'
faq:
- question: "Qu'est-ce qu'une clé d'API ?"
answer: "Une chaîne unique qu'un fournisseur d'API délivre à une application enregistrée et qui accompagne chaque requête — idéalement dans un header — pour que le serveur puisse identifier l'appelant, appliquer ses permissions, mesurer l'usage et imposer des rate limits. Point notable : aucun standard ne la définit. Les clés d'API sont une convention, pas un protocole."
- question: "Une clé d'API est-elle un mot de passe ?"
answer: "Une clé secrète relève fonctionnellement de la catégorie des mots de passe : c'est un identifiant bearer, donc quiconque la détient est considéré comme vous — même discipline de stockage, mêmes conséquences en cas de fuite. Les différences : les clés identifient des applications plutôt que des personnes, et beaucoup n'expirent jamais tant que vous ne les faites pas tourner."
- question: "Quelle est la différence entre une clé d'API et un token ?"
answer: "Les clés identifient des apps ; les tokens authentifient des utilisateurs. Une clé est statique, générée par un administrateur et liée à une application ; un access token OAuth est émis à la connexion, de courte durée, renouvelable, et porte les permissions d'un utilisateur précis. L'identification de serveur à serveur convient aux clés ; tout ce qui est propre à un utilisateur relève des tokens."
- question: "Où stocker les clés d'API ?"
answer: "Jamais dans le code source. Les variables d'environnement issues d'un fichier non versionné sont le minimum — avec la réserve qu'elles fuient par les logs, les dumps de processus et les définitions de conteneurs — et un gestionnaire de secrets est le standard d'équipe : chiffré au repos, à accès contrôlé, audité et compatible avec la rotation."
- question: "Puis-je mettre une clé d'API dans du code frontend ou mobile ?"
answer: "Seulement une clé publiable conçue pour cela. Tout ce qui se trouve dans un bundle JavaScript ou un binaire d'application est public — l'extraction est routinière et l'obfuscation ne fait que la ralentir. Les clés secrètes restent côté serveur ; quand un client a besoin d'un service protégé par une clé secrète, faites passer l'appel par votre propre backend."
- question: "Que faire quand une clé d'API a fuité ?"
answer: "Immédiatement : révoquez la clé, déployez une remplaçante, purgez-la du code et de l'historique git, auditez les logs d'usage à la recherche d'abus, et faites tourner tout ce qui était stocké au même endroit. Agissez vite — des bots testent les clés commitées dans des dépôts publics en quelques minutes — et rappelez-vous que la révocation arrête l'usage futur, pas les données déjà dérobées."
- question: "À quelle fréquence faire tourner les clés d'API ?"
answer: "Selon le risque : tous les 30 à 90 jours pour les clés à portée large ou exposées à l'extérieur, plus longtemps pour les clés internes à faible risque, et immédiatement en cas de soupçon d'exposition ou de départ d'un membre de l'équipe. La rotation sans interruption repose sur une fenêtre de chevauchement pendant laquelle l'ancienne et la nouvelle clé sont toutes deux valides, le temps que les déploiements suivent."
- question: "Comment les clés d'API fuient-elles ?"
answer: "Par ordre de notoriété : commitées dans des dépôts git, livrées dans des bundles clients et des binaires mobiles, placées dans des URL que les logs serveur et l'historique du navigateur capturent, imprimées dans les logs applicatifs et de CI, et collées dans des chats et des tickets. Chaque vecteur est évitable, et c'est précisément ce qui rend la liste déprimante."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
- name: 'OWASP Secrets Management Cheat Sheet'
url: 'https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html'
- name: 'OWASP API Security Top 10 (2023)'
url: 'https://owasp.org/API-Security/editions/2023/en/0x11-t10/'
- name: 'OWASP Key Management Cheat Sheet'
url: 'https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html'
- name: 'RFC 6750 — OAuth 2.0 Bearer Token Usage'
url: 'https://datatracker.ietf.org/doc/html/rfc6750'
- name: 'API key — Wikipedia'
url: 'https://en.wikipedia.org/wiki/API_key'
cta:
title: 'Des clés conçues pour être livrées'
text: "Les clés client de Back4app sont publiables par conception — les données sont protégées par des CLP et des ACL appliquées côté serveur, pas par le secret de la clé — tandis que la Master Key reste là où vivent les secrets : sur le serveur."
linkText: 'Commencez gratuitement'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-11'
translationKey: api-key-security
---
**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](/glossary/fr/json-web-token-jwt/) ; 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
| Question | Réponse |
| --- | --- |
| Ce que fait une clé | Identifie l'app · mesure l'usage · ancre les [rate limits](/glossary/fr/rate-limiting-api/) |
| Les deux espèces | Clés publiables (faites pour être livrées) vs. clés secrètes (catégorie mot de passe) |
| L'échelle du stockage | Codée en dur : jamais → variables d'environnement : le minimum → gestionnaire de secrets : le standard |
| La loi d'airain | Tout ce qui est dans un bundle client est public — prévoyez l'extraction |
| Réponse à une fuite | Révoquer → remplacer → purger l'historique → auditer — en minutes, pas en jours |
## La requête, et les deux types de clés
```text
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:**
```javascript
// 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
// 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.
```
**Swift:**
```swift
// 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.
```
**Kotlin:**
```kotlin
// 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
| | Clé d'API | Access token OAuth | JWT |
| --- | --- | --- | --- |
| Identifie | L'application | L'utilisateur (et l'autorisation accordée) | Ce que disent ses claims |
| Émission | Une fois, par un administrateur | À chaque connexion, via un flux | C'est un *format*, pas une émission |
| Durée de vie | Jusqu'à la rotation (souvent jamais) | De quelques minutes à quelques heures | Ce que dit `exp` |
| Portée | Fixée à la création | Portées par autorisation | Définie par les claims |
| Standard | Aucun — convention | [OAuth 2.0](/glossary/fr/oauth-2-connexion-sociale/) | RFC 7519 |
| Le bon usage | Identification de serveur à serveur, comptage | Accès API délégué par l'utilisateur | Transport de claims signés |
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](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) 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 :
```mermaid
flowchart LR
accTitle: Pattern proxy qui garde les clés secrètes côté serveur
accDescr: L'app cliente ne détient qu'une clé publiable et appelle votre backend. Le backend, qui détient la clé secrète dans un gestionnaire de secrets, appelle l'API tierce et renvoie les résultats, si bien que le secret n'est jamais livré au client.
C["App cliente
clé publiable uniquement"] -->|"votre API"| B["Votre backend
clé secrète issue du
gestionnaire de secrets"]
B -->|"X-Api-Key: sk_live_…"| T["API tierce"]
T --> B --> C
X["Un attaquant décompresse le bundle"] -.->|"ne trouve rien
qui vaille la peine d'être volé"| C
```
## 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](/glossary/fr/rate-limiting-api/) par clé et la révocation comme leviers de contrôle du rayon d'impact.
## Quel identifiant devriez-vous utiliser ? Matrice de décision
| Situation | Choisissez |
| --- | --- |
| Un backend qui appelle une API tierce | Une clé secrète, dans un gestionnaire de secrets |
| Identifier votre app depuis le web ou le mobile | Une clé publiable + une autorisation côté serveur |
| Agir au nom d'un utilisateur connecté | Des tokens OAuth, pas des clés |
| Des claims signés entre services | Des [JWT](/glossary/fr/json-web-token-jwt/) |
| Un client a besoin d'un service à clé secrète | Votre backend comme proxy — le secret n'est jamais livré |
| De machine à machine avec une auth de type utilisateur | Le flux client credentials d'OAuth |
## 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](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) 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](/glossary/fr/permissions-de-classe-clp/) et aux [ACL](/glossary/fr/listes-de-controle-d-acces-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.