Une clé API Google dans votre frontend, est-ce un problème ?

Ouvrez votre appli dans un navigateur, affichez le code source de la page et cherchez AIza. Si une chaîne de quarante caractères apparaît, quelqu'un vous a probablement déjà dit qu'elle était « exposée », sans probablement dire quoi faire ensuite.

Voici ce que la plupart des conseils sur le sujet se trompent : une clé API Google dans votre frontend n'est pas le même genre de problème qu'une clé secrète Stripe dans votre frontend, et la solution ne consiste pas à la cacher. Traiter les deux de la même façon mène soit à paniquer pour votre carte, soit, pire, à apprendre à hausser les épaules devant le mot « exposée » juste avant le jour où il compte.

Entre le 12 et le 14 août 2026, nous avons passé les mêmes neuf vérifications externes sur 30 998 applis en ligne créées avec Lovable, Bolt, v0, Replit et Base44. Une clé API Google est apparue dans 1 142 d'entre elles. Une clé secrète Stripe est apparue dans trois. Les chiffres complets sont dans notre rapport de scan.

Est-ce grave que ma clé API Google soit exposée dans le frontend ?

En général non. Tout dépend de si la clé est restreinte.

Une clé API Google n'est pas un mot de passe. Elle ressemble davantage à un numéro de compte : elle indique à Google quel projet facturer et sur quel quota prélever. À elle seule, elle ne dit rien de qui envoie la requête.

C'est pourquoi elle peut vivre dans votre page. La carte est dessinée par le navigateur de votre visiteur, donc c'est le navigateur qui doit envoyer ce numéro de compte à Google. Il n'existe aucune version de cela où la carte se charge et où le numéro reste caché.

La protection vient d'un second réglage, conservé du côté de Google, qui indique depuis quels sites le numéro peut être utilisé. Google appelle cela une restriction de référent HTTP. Une fois réglée, la clé imprimée dans votre page fonctionne sur votre site et renvoie une erreur partout ailleurs.

Pourquoi votre appli envoie la clé

Parce que la requête part du navigateur de votre visiteur et non de votre serveur.

Quand quelqu'un charge une page contenant une carte, ce navigateur parle directement à maps.googleapis.com. Il doit dire à quel projet Google la requête appartient, et cet identifiant doit se trouver dans la page, parce que la page est l'endroit d'où part la requête.

Google le sait. C'est pour cela que la restriction existe comme contrôle séparé : l'identifiant allait de toute façon devenir public, donc ce qui décide de qui peut l'utiliser se trouve dans un endroit que le public n'atteint pas.

Comment restreindre une clé API Google

C'est gratuit, cela prend environ cinq minutes, et vous n'avez pas besoin de toucher au code de votre appli. Dans la console Google Cloud :

1. Allez dans API et services → Identifiants et cliquez sur la clé que vous avez trouvée.
2. Sous Restrictions relatives aux applications, choisissez Sites web.
3. Ajoutez votre domaine. Pour un site à yourapp.com, ajoutez https://yourapp.com/*. Ajoutez aussi votre domaine de préversion ou de test, si vous en avez un, et souvenez-vous de l'adresse .lovable.app ou .vercel.app sur laquelle votre appli était publiée avant que vous y rattachiez un domaine personnalisé.
4. Sous Restrictions relatives aux API, choisissez Restreindre la clé et cochez uniquement les API que votre appli appelle réellement. Une carte avec recherche de lieux a besoin de l'API Maps JavaScript et de l'API Places, et de rien d'autre.
5. Enregistrez, attendez quelques minutes, puis chargez votre propre site et vérifiez que la carte se dessine toujours.

Si l'étape 3 est fausse, vous vous en apercevez immédiatement et visiblement : la carte échoue avec RefererNotAllowedMapError dans la console du navigateur, ce qui nomme précisément le problème. Ajoutez le domaine manquant et cela refonctionne. C'est un changement réversible, et c'est pourquoi il vaut la peine de le faire avant d'avoir fini de lire cet article.

Une chose à ne pas faire : les propres conseils de dépannage de Google indiquent que les restrictions par adresse IP sont destinées aux clés côté serveur et ne conviennent pas à une clé utilisée par un navigateur. Si vous restreignez une clé de frontend par IP, votre appli casse pour tous les visiteurs.

Si vous préférez voir quelles clés votre appli envoie réellement avant de les passer une par une, notre scan gratuit lit votre site en ligne depuis l'extérieur et vous dit ce qu'il trouve. Il dure environ 20 secondes et ne demande aucun compte : scannez votre appli.

Quels identifiants Google ont leur place dans un navigateur

Les trois premières lignes sont la même chaîne. Une clé API Google ne porte pas écrit sur elle à quoi elle sert, donc la question n'est jamais « à quoi ressemble cette clé » mais « qu'a le droit de faire cette clé », et cette réponse vit dans la console et pas dans votre code.

La clé Firebase est faite pour être publique

C'est la ligne sur laquelle on nous interroge le plus, et la documentation de Firebase y répond clairement : les clés API des services Firebase peuvent figurer dans le code ou dans des fichiers de configuration, parce qu'elles ne contrôlent l'accès à rien. Ce sont les règles de sécurité Firebase et App Check qui en décident.

Si cela vous semble familier, c'est le même dispositif que chez Supabase. La clé publiable identifie le projet, et les règles derrière elle décident ligne par ligne qui peut lire quoi. Dans les deux cas, la clé n'est sûre que grâce à ces règles, donc ce sont les règles qu'il faut aller regarder : les activer ne revient pas à être protégé.

Ce qui arrive vraiment quand une clé sans restriction fuit

Une facture, une panne, ou les deux. Pas une fuite de données.

Des robots automatiques parcourent les pages publiques en collectant les chaînes AIza, et une clé sans restriction fonctionne depuis n'importe où, si bien que la vôtre finit par servir des tuiles de carte et des recherches de lieux pour le projet de quelqu'un d'autre. Google le nomme directement dans sa propre documentation de démarrage : la raison de poser des restrictions est d'empêcher le vol de quota.

Vous le remarquez en général de deux façons. La facture est plus élevée que le mois dernier sans raison identifiable, ou les cartes de votre appli cessent de se dessiner en cours de mois parce que le projet a épuisé son quota et que chaque visiteur voit désormais un rectangle gris.

Les deux se réparent. Aucune n'expose les données de vos utilisateurs, car une clé Maps ne peut pas lire votre base de données. C'est la différence honnête entre ce constat et une clé de base de données ayant fuité, et c'est pourquoi notre scanner signale une clé API Google comme quelque chose à vérifier et non comme une urgence.

Le seul identifiant Google qui se comporte réellement comme une urgence est un compte de service. Si votre appli envoie un fichier JSON contenant "type": "service_account" et un bloc "private_key", ce sont de véritables identifiants avec de véritables permissions sur votre projet cloud. Supprimez la clé dans la console, puis regardez ce à quoi elle pouvait accéder.

Quoi faire maintenant

Si vous préférez traiter cela comme une liste, la checklist de sécurité en 10 minutes couvre ce point ainsi que les autres choses à désactiver dans une appli tout juste lancée. Et pour la question plus large de savoir quelles clés ont leur place dans un navigateur, nous avons un guide pour distinguer les clés publiables des clés secrètes.