Es gibt diesen Satz, den man in Dev‑Teams oft hört wie ein Mantra: „API‑Keys sind keine Secrets.“ Gemeint ist: Ein Key identifiziert ein Projekt oder ein Limit, aber er authentifiziert keine Person. Also: halb so wild, wenn er irgendwo im Client oder in einem Repo landet. [1]

Das funktioniert — bis ein Produktteam (oder ein Modell) die Bedeutung ändert. [2]

Bei Googles Gemini hat genau das viele Leute kalt erwischt: Keys, die jahrelang wie „Public IDs mit Rate‑Limit“ behandelt wurden, wurden plötzlich zu einem Hebel für echte Aktionen und Kosten. Und damit werden sie praktisch zu Passwörtern: Wer den Key hat, kann (unter Umständen) in deinem Namen Ressourcen verbrennen. [1] [3]

Der Kernfehler: ein statisches Label

„Secret“ ist kein Etikett, das du einmal auf einen String klebst. „Secret“ ist ein Risikoprofil:

  • Was kann jemand damit tun?
  • Wie leicht ist Missbrauch zu automatisieren?
  • Wie schnell merkst du es?
  • Wie gut kannst du rotieren und einschränken? Wenn eine dieser Antworten kippt, kippt die Klassifikation.

Eine einfache Faustregel

Behandle jeden Key so, dass er im Worst‑Case in fremden Händen landet. Das heißt nicht „paranoid werden“. Das heißt: Scope klein, Limits hart, Rotation billig, Monitoring laut.

Im nächsten Abschnitt baue ich daraus eine kurze Checkliste (Client‑Keys vs. Server‑Keys, Quotas, Allow‑Lists, getrennte Projekte pro Umgebung) — und warum Passwort‑Manager als Mental‑Model helfen, obwohl es hier nicht um Passwörter geht.

Checkliste: wenn ein Key plötzlich „wie ein Passwort“ wirkt

Sobald ein Key Kosten auslösen, Daten schreiben oder privilegierte Aktionen anstoßen kann, ist die Diskussion „Secret oder nicht?“ vorbei. Dann geht es nur noch um Blast Radius und Beobachtbarkeit.

1) Client‑Key vs. Server‑Key (und warum Referrer‑Locks keine Rettung sind)

  • Client‑Keys sind nur dann ok, wenn sie wirklich nur für public/low‑impact Dinge taugen. Alles, was „write“, „admin“, „billing“ oder „model‑usage“ bedeutet, gehört serverseitig.
  • Referrer-/Origin‑Restriktionen sind nett, aber sie sind kein Sicherheitsgurt. Sie sind eher ein Rückspiegel: hilfreich, aber du fliegst trotzdem durch die Windschutzscheibe, wenn jemand deinen Key kopiert und deine Konfiguration ausnutzt. [2] Wenn du eine API unbedingt aus dem Browser ansprechen willst: gib dem Client keinen Master‑Key, sondern einen kurzlebigen, zweckgebundenen Token (z.B. signiert, 5–15 Minuten gültig, nur für genau eine Aktion).

2) Scope ist Security (Quotas sind nur Schadensbegrenzung)

Wenn du eine externe Checkliste willst: OWASP API Security ist dafür eine solide Basis (Threat‑Model + typische Fehlerklassen). [3]

Quotas/Budgets sind super — aber sie sind keine Security‑Kontrolle, sondern ein Airbag. Der Sicherheitsgurt ist Scope:

  • getrennte Keys pro Umgebung (dev/stage/prod)
  • getrennte Keys pro Feature (z.B. „image‑gen“ ≠ „chat“)
  • harte Limits pro Key (Requests/Minute, Token/Minute, Tagesbudget)
  • wenn möglich: Allow‑Lists (IP, VPC‑Egress, Service‑Accounts) Der wichtigste Satz dabei: „Ein geleakter Key darf maximal eine kleine Ecke deines Systems anknabbern.“

3) Rotation muss billig sein, sonst passiert sie nie

Teams rotieren nicht „weil sie faul sind“, sondern weil Rotation oft weh tut: Deployments, Downtime‑Angst, unbekannte Abhängigkeiten.

Mach Rotation zur Routine:

  • Keys sind versioniert (Key‑A + Key‑B parallel, sauberes Cutover)
  • ein Key‑Leak ist ein Runbook, kein Drama
  • Secrets liegen nicht „irgendwo“, sondern in einem Secrets‑Store (und der Zugriff ist auditiert)

    4) Monitoring: nicht „ob“, sondern „wie schnell“

    Wenn ein Key missbraucht wird, ist die Frage nicht „wie konnte das passieren“, sondern wann merkst du es.

Minimum‑Setup:

  • Alerts auf Spend/Usage‑Spikes (pro Key, pro Projekt)

  • Alerts auf neue Regionen / neue IPs / neue User‑Agents

  • „Budget‑Stop“: ab X € oder X Tokens/Tag wird automatisch dichtgemacht (fail‑closed, nicht fail‑open)

    5) Wo Keys wirklich rausfallen (und wie du es stopfst)

    Die meisten Key‑Leaks passieren nicht durch „Hacker mit Hoodie“. Sie passieren durch ganz normale Arbeitsabläufe, die sich wie Produktivität anfühlen:

  • Git + Copy/Paste: Ein .env landet einmal kurz im Repo „nur zum Testen“ – und wird von Bots innerhalb von Minuten gefunden.

  • CI/CD‑Logs: Debug‑Logging an, und plötzlich steht Authorization: Bearer … im Build‑Output. (Und der Build‑Output lebt länger als dein Sprint.)

  • Client‑Builds & Source Maps: Du dachtest, der Key sei „nur temporär“ im Frontend – die Source Map macht daraus eine Einladung.

  • Observability/Tracing: Request/Response‑Bodies sind Gold fürs Debugging … bis sie Tokens/Keys mitspeichern.

  • Support & Screenshots: „Schick mir kurz die Anfrage“ – und zack, der Key ist im Ticket‑System.

  • LLM‑Workflows: „Hier ist mein Fehler, hier ist meine Config“ – und dein Key ist nicht nur geteilt, sondern potenziell persistent gespeichert. Die Ableitung ist nicht „Menschen sind unfähig“, sondern: Dein System muss Key‑Leaks als Normalfall aushalten. Ein paar Gegenmittel, die wirklich wirken:

  1. Secret‑Scanning als Schranke (pre‑commit + CI). Nicht als Deko, sondern als Stoppschild. 2) Redaction by default: Alles, was nach x-api-key, token, secret aussieht, wird vor dem Logging maskiert. 3) Kurzlebige Tokens statt dauerhafte Keys im Client: Browser bekommen Tickets, keine Generalschlüssel. 4) Canary/Honey‑Keys: Ein absichtlich nie benutzter Key, der bei jeder Nutzung Alarm schlägt. Wenn der feuert, weißt du: irgendwo tropft’s. 5) Kill‑Switch: Budget/Quota/Anomalie → automatisch dicht. Fail‑closed, nicht fail‑open.

Wenn du das hast, ist „Key geleakt“ kein Weltuntergang mehr – sondern ein standardisierter Incident, den du in 10 Minuten abräumst.

Mini‑Runbook (wirklich nur das Nötigste):

  • Sofort: Key sperren/rotieren (idealerweise Key‑A/Key‑B parallel), Quota/Budget temporär runter.
  • Säubern: Suche nach dem Leak‑Pfad (Git‑History, CI‑Logs, Observability, Tickets). Alles, was „nur intern“ war, ist ab jetzt „potenziell öffentlich“.
  • Absichern: Redaction einschalten, Scanning hart machen, und einen Canary‑Key setzen, der dir beim nächsten Tropfen sofort Alarm gibt. Das ist nicht glamourös, aber es ist Betrieb. Und Betrieb ist der Unterschied zwischen „Ups“ und „wir zahlen jetzt Lehrgeld“.

6) Warum Passwort‑Manager als Mental‑Model helfen

Schneier schreibt über Passwort‑Manager, aber die Logik ist übertragbar: Ein zentrales Geheimnis ist praktisch — und gleichzeitig ein Single Point of Failure. Genau das passiert, wenn du „den einen Key“ überall reinsteckst. [4]

Der Ausweg ist nicht „nie wieder Keys“, sondern: mehr kleine Keys statt ein großer. Und ein Betrieb, der davon ausgeht, dass Leaks passieren — ohne dass du nachts um drei deine Kreditkarte einfrieren musst.

Referenzen

  1. Quelle 1: https://ai.google.dev/gemini-api/docs/api-key
  2. Quelle 2: https://docs.cloud.google.com/docs/authentication/api-keys
  3. Quelle 3: https://owasp.org/www-project-api-security/
  4. Quelle 4: https://www.schneier.com/blog/archives/2026/02/on-the-security-of-password-managers.html