Google API-nøgler var ikke hemmeligheder, men så ændrede Gemini reglerne

Når "Public by Design" bliver et sikkerhedsansvar

I næsten to årtier har udviklere, der bygger på Googles økosystem, lært en subtil, men vigtig lektie: Google API-nøgler er ikke rigtig hemmeligheder. Hvis du indlejrede en YouTube Data API-nøgle i en JavaScript-fil, var Google ikke bekymret. Hvis din Maps API-nøgle dukkede op i et offentligt GitHub-lager, var sikkerhedssvaret i det væsentlige et skulderklap og en påmindelse om at indstille domænebegrænsninger. Hele modellen blev bygget op omkring antagelsen om, at disse nøgler ville leve i kode på klientsiden, udsat for alle, der åbnede DevTools.

Den filosofi gav mening i lang tid. En Maps API-nøgle, der er afsløret uden domænebegrænsninger, vil muligvis give en overraskelsesregning, men den kom ikke til at kompromittere patientjournaler eller dræne en bankkonto. Sprængningsradius var økonomisk og overskuelig. Googles værktøj – henvisningsbegrænsninger, IP-hvidlisting, kvotegrænser – var designet til at begrænse skaden, ikke helt forhindre eksponering.

Så kom Gemini, og reglerne ændrede sig. Problemet er, at millioner af udviklere ikke har fået notatet.

Den arvelige mentale model, der nu får udviklere til at brænde

Den gamle Google-udvikleroplevelse var bevidst eftergivende. Da du oprettede en Maps JavaScript API-nøgle, opfordrede dokumentationen dig praktisk talt til at droppe den direkte i din HTML. Sikkerhedsmodellen var ikke hemmeligholdelse - det var begrænsning. Du ville låse nøglen til dit domæne, indstille kvoteadvarsler og komme videre. Dette var pragmatisk konstruktion: klient-side applikationer kan virkelig ikke holde hemmeligheder for beslutsomme brugere, så Google byggede et system, der anerkendte denne virkelighed.

Dette skabte en generation af udviklere - og endnu vigtigere, en generation af institutionelle vaner - hvor Google API-nøgler optog en anden mental kategori end for eksempel en Stripe-hemmelig nøgle eller en AWS-adgangsoplysninger. Du ville ikke indsætte din Stripe hemmelige nøgle i et offentligt repos. Men din Maps-nøgle? Det var praktisk talt en konfigurationsværdi, ikke en hemmelighed. Mange teams gemte dem i offentligt vendte konfigurationsfiler, README-filer, selv i miljøvariabler på klientsiden med præfiks med NEXT_PUBLIC_ eller REACT_APP_ uden en ekstra tanke.

Sikkerhedsforskere, der scannede GitHub for synlige legitimationsoplysninger, lærte også at behandle Google API-nøgler anderledes. En lækket Maps-nøgle var et fund med lav sværhedsgrad. En lækket Gemini-nøgle er en helt anden samtale.

Hvad ændrede sig med Gemini - og hvorfor det betyder noget

Googles Gemini API følger ikke den gamle spillebog. Når du genererer en Gemini API-nøgle gennem Google AI Studio, opretter du en legitimationsoplysninger med en fundamentalt anderledes risikoprofil end en Maps- eller YouTube-nøgle. Tvillingnøgler autentificerer adgang til store sprogmodelslutninger - en tjeneste, der koster Googles rigtige computerressourcer, og som fakturerer dig efter token, ikke ved sidevisning.

Mere kritisk har Gemini API-nøgler ikke de samme indbyggede domænebegrænsningsmekanismer, som gjorde det muligt at afsløre andre Google-nøgler. Der er ingen simpel "lås dette til mit websteds domæne" kontrol, der ville forhindre en hacker, der fandt din nøgle i et offentligt lager, i at oprette deres egen applikation og forbruge din kvote - eller din faktureringsgrænse - fra en server i et andet land.

Faren er ikke kun økonomisk. En afsløret Gemini-nøgle kan bruges til at generere skadeligt indhold, udføre hurtige injektionsangreb eller bygge værktøjer, der overtræder Googles servicevilkår – alt faktureret til din konto og kan spores tilbage til din identitet.

I 2024 identificerede sikkerhedsforskere tusindvis af udsatte Gemini API-nøgler på GitHub alene, mange af dem i repositories, der tidligere havde været vært for andre Google API-nøgler uden hændelser. Udviklerne var ikke hensynsløse efter deres egne historiske standarder - de anvendte en mental model, som Google selv havde trænet dem til at bruge. Miljøet ændrede sig hurtigere end vanerne gjorde.

Anatomien af en utilsigtet eksponering

At forstå, hvordan disse eksponeringer sker, er det første skridt mod at forhindre dem. Fejltilstandene er

Frequently Asked Questions

Why were Google API keys historically considered safe to expose publicly?

Google designed many of its APIs — Maps, YouTube, Places — for client-side use, meaning keys were intentionally embedded in front-end code visible to anyone. The security model relied on usage restrictions like domain allowlists and referrer checks rather than key secrecy. For years, an exposed key was considered a configuration issue, not a critical vulnerability requiring immediate rotation.

What changed when Google introduced Gemini API keys?

Unlike legacy Google APIs, Gemini API keys function more like traditional secrets — exposing one can result in unauthorized charges to your billing account, model abuse, or quota exhaustion with no built-in domain restriction to save you. The shift means developers must now treat Gemini keys with the same discipline as AWS credentials or Stripe secret keys, storing them server-side and never in client-facing code.

How should developers securely manage API keys for AI services today?

Best practice is to store all AI API keys as environment variables on the server, never in version-controlled files or client bundles. Use a secrets manager, rotate keys regularly, and set spending limits at the provider level. Platforms like Mewayz — a 207-module business OS at $19/mo available at app.mewayz.com — handle API credential management within their infrastructure so teams aren't manually juggling keys across services.

What should I do if I have already accidentally exposed a Gemini API key?

Revoke the compromised key immediately through Google Cloud Console and generate a replacement before doing anything else. Audit your billing dashboard for unexpected usage spikes that could indicate the key was harvested. Then review your codebase, CI/CD environment variables, and any public repositories for other leaked credentials. Treat the incident as you would any exposed payment credential — assume it was found and act accordingly.

Related Posts

• Spørg HN: Hvorfor er elektronik stadig så genanvendelig?
• Hvem smurte Feynman
• FAA lukker luftrummet omkring El Paso, Texas, i 10 dage og sætter alle flyvninger på grund
• Terence Tao, 8 år gammel (1984) [pdf]