Google API Keys Security Guide

Google API keys were long treated as harmless project identifiers that could sit in web pages and mobile apps, but once the Gemini API is enabled in a project, an unrestricted key in that project becomes a credential that can run up AI charges and reach uploaded files. Research published by Truffle Security in February 2026 found 2,863 live Google API keys with Gemini access in a public web archive, and Google has since changed how Gemini treats unrestricted keys. The underlying problem is older: keys default to broad access, they carry no user identity, and enabling a new API silently changes what every existing key can do. This guide explains standard and authorization keys, how restrictions work, who can manage keys, how to monitor them and how to clean up an estate of old keys. It is for Google Cloud, Firebase, Maps and Gemini developers and the platform teams that govern their projects. For service account JSON keys, which are a different and more powerful credential, see the Google Cloud Service Account Keys Security Guide.

Key takeaways

A key's power is whatever its project has enabled. Unrestricted keys can call every enabled API that accepts keys, so turning on Gemini changes the risk of every unrestricted key in that project.
Always set both restriction types. An application restriction (website, IP, Android or iOS) plus an API restriction listing only the services the key needs.
Keep public keys and AI keys apart. Firebase's documentation says never to include the Gemini Developer API in the allowlist of a publicly accessible key; use separate keys, and ideally separate projects.
Authorization keys act as a service account. They are bound to an identity and behave like long-lived access tokens, so give the bound account no IAM roles unless needed.
Monitor by key. Cloud Monitoring can break down usage by credential_id, which is how you find which keys are live before restricting or deleting them.

How identity and access work in Google API keys

Credential	Identifies	Typical use	Risk if leaked
Standard API key	A project, for billing and quota; not a principal, so IAM cannot evaluate the caller	Maps, Firebase client SDKs, YouTube Data, Gemini (legacy)	Quota theft, billing abuse, and data access on any enabled API it is not restricted from
Authorization key (bound to a service account)	The bound service account	Gemini API and Vertex AI (`generativelanguage.googleapis.com`, `aiplatform.googleapis.com`)	Acts as the service account until disabled; behaves like a long-lived access token
Service account key (JSON)	A service account, with full IAM	Server workloads outside Google Cloud	Everything the service account can do; see the linked guide
Short-lived OAuth token	A user or service account	Recommended for server workloads	Limited by token lifetime

Anatomy: a key has a key string (used in calls, beginning AIza, which the Gitleaks gcp-api-key rule matches), a key ID used by admin tools, an optional display name and, for authorization keys, the bound service account.
Defaults: keys created in the console or gcloud must now have at least one API restriction, but keys created through the REST API are unrestricted unless the request sets restrictions. Google's own documentation calls unrestricted keys insecure.
Sending keys: Google recommends the x-goog-api-key header or a client library rather than a query parameter, because URLs end up in logs and scans.
Firebase is a special case: Firebase keys identify the project and app; data access is controlled by Security Rules, App Check and IAM, so a Firebase key restricted to Firebase APIs can be public. Auto-created Firebase keys have been restricted to a Firebase API list by default since May 2024.

Restriction types

Restriction	Use for	Limits
Websites (HTTP referrers)	Browser keys such as Maps JavaScript	Wildcards only for subdomains or paths; referrer headers can be spoofed outside browsers
IP addresses	Server-side keys	IPv4, IPv6 and CIDR; no internal addresses or localhost; the only application restriction available for authorization keys
Android apps	Mobile SDK keys	Package name and SHA-1 fingerprint sent in headers; Google notes this is easy to bypass
iOS apps	Mobile SDK keys	Bundle ID based; also bypassable by a determined attacker
API restrictions	Every key	The API must be enabled before you can restrict to it

Only one application restriction type can be set per key. Because client-side restrictions can be bypassed, the API restriction is the control that really limits impact.

Admin roles and privileged access

Standard keys: creating and managing them needs API Keys Admin (roles/serviceusage.apiKeysAdmin) and Service Usage Viewer (roles/serviceusage.serviceUsageViewer). Anyone with API Keys Admin can also widen or remove a key's restrictions, so grant it to a platform team, not to every developer.
Authorization keys: also need Service Account User (roles/iam.serviceAccountUser) and Service Account API Key Binding Admin (roles/iam.serviceAccountApiKeyBindingAdmin), because binding a key lets its holder act as the account.
Organisation policy: binding keys to service accounts is blocked by default by constraints/iam.managed.disableServiceAccountApiKeyCreation, except for keys restricted to the Gemini API. Keep the constraint enforced and allow specific services only where justified. Projects without an organisation cannot use this control, which is another reason to keep all projects inside your organisation. See the Google Cloud Organization Policy Guide.
Enabling APIs is a privileged act: whoever can enable services (for example through Service Usage Admin or project Owner) can change what every unrestricted key in the project can reach. Review who holds those roles. See the Google Cloud IAM and Service Accounts Guide.

Integrations, API tokens and service accounts

Choosing a credential

Situation	Use	Why
Browser or mobile app calling Maps or Firebase	Standard key with app restriction and narrow API restriction; Firebase App Check	Key will be public, so its reach must be minimal
Browser or mobile app needing Gemini	Firebase AI Logic via the Firebase key and App Check, or your own backend	Never put a Gemini Developer API key in client code
Server calling Gemini	Authorization key with IP restriction, bound service account with no IAM roles, stored in Secret Manager	Google allows this for Gemini because it does not create project resources
Server calling APIs that create or manage resources	Short-lived service account credentials through IAM	Google advises against authorization keys in production for these APIs
Maps Static or Street View Static	Key plus URL signing, signature generated server-side	Signing secret kept out of the source tree

Structure projects for blast radius

One key per application and platform: Maps guidance allows up to 300 keys per project; separate keys let you rotate or delete one without breaking others.
Separate client and server projects: Google's Maps guidance suggests putting client-side and server-side usage in different projects, which also keeps public keys away from projects where Gemini is enabled.
Treat enabling an API as a change to every key: before enabling the Generative Language API in an existing project, list every key there and confirm each has an API restriction that excludes it.

The Google API Keys Exposure 2026 page records how this went wrong at scale: keys published years earlier for Maps or Firebase could, after Gemini was enabled, reach the Gemini /files/ and /cachedContents/ endpoints and bill usage to the owner. A follow-up found Gemini-capable keys hard-coded in popular Android apps.

What Google changed

Google's Gemini API documentation states that unrestricted keys left dormant for an extended period have been blocked since 7 May 2026, that new keys created in AI Studio are authorization keys by default from 28 May 2026, that authorization keys have fast-acting leaked key enforcement, and that the Gemini API will reject requests from unrestricted standard keys. These changes reduce the Gemini exposure but do not restrict your keys for other APIs, and they change over time, so check the current page rather than relying on defaults.

Logging and detection

Source	What to watch
Cloud Monitoring, API metrics filtered by `credential_id` and `platform_type`	Which APIs each key calls; new APIs (especially `generativelanguage.googleapis.com`) appearing for an existing key; spikes and unusual platforms
Cloud Audit Logs, Admin Activity for `apikeys.googleapis.com`	Keys created, updated (restrictions removed or widened) or undeleted
Cloud Audit Logs for Service Usage	APIs enabled in projects that hold public keys
Billing budgets and alerts	Unexpected cost on Gemini, Maps or other key-billed APIs
Secret scanning on code, CI and web assets	`AIza` keys in repositories, bundles and app packages; verify liveness and Gemini access

Note that requests made with authorization keys do not appear in service account usage metrics, so rely on API metrics by credential for those keys.

Responding to an exposed key

Find it: map the key string to the key ID and project, and check its restrictions and which APIs it called using the metrics above.
Restrict first if it must stay public: a Maps or Firebase key embedded in a shipped app may not be replaceable quickly; tighten its API restriction immediately to remove Gemini and anything else it does not need.
Rotate otherwise: create a replacement (Maps rotation creates a new key inheriting the restrictions, with both working during transition), deploy, confirm the old key's traffic has stopped, then delete it.
Assess data and cost: review Gemini files and cached content in the project, billing and quota usage for the exposure window.
Close the source: remove the key from code and build artefacts. See the Git Secret Scanning Guide.

Metrics

Unrestricted keys: number of keys with no API restriction (target zero).
Keys without application restrictions: count, each with a documented reason.
Public keys in Gemini-enabled projects: keys with referrer, Android or iOS restrictions living in projects where the Generative Language API is enabled.
Dormant keys: keys with no traffic in 90 days, to delete.
Budget coverage: share of projects with billing alerts.

Hardening baseline

Inventory: list keys in every project in the organisation, with restrictions, creation dates and owners, and list enabled APIs per project.
Measure before you change: use credential_id metrics to learn which APIs each key really calls over at least 30 days.
Restrict on a test key first: as Firebase advises, test restriction changes on a non-production key, because a missing API on the allowlist breaks the app.
Apply API restrictions to every key, then application restrictions appropriate to where the key is used.
Delete dormant keys and keys with no owner after a short disable period.
Move AI workloads: put Gemini usage in dedicated projects with authorization keys or IAM credentials, never sharing a project with public keys.
Enforce policy: keep iam.managed.disableServiceAccountApiKeyCreation enforced and restrict who can enable APIs and manage keys.
Monitor: budgets, audit log alerts on key updates and API enablement, and scanning.

Rollback: keep the previous restriction set recorded for each key; if a restriction breaks an app, restore the prior list for that key alone rather than removing restrictions.

Decision guidance

Small team with one project: split public client keys and Gemini into two projects, restrict every key, and set a budget alert. That covers most of the risk.
Large organisation: scan all projects centrally for unrestricted keys, require API restrictions through review, and treat enabling AI APIs as a change needing approval.
Authorization key or IAM token: authorization keys are acceptable for Gemini; for anything that manages resources, use short-lived service account credentials.

Common misconfigurations

Keys created through the REST API or by old tooling with no restrictions, able to call every key-enabled API in the project.
Public Maps or Firebase keys in a project where Gemini was later enabled, the exact pattern behind the 2026 exposure research.
Relying on referrer or app restrictions alone, which can be spoofed by anyone who extracts the key.
One key shared across many apps and servers, so it cannot be rotated without coordinated outages.
Keys passed as query parameters, leaving them in proxy, CDN and analytics logs.
Authorization keys bound to service accounts with project roles, turning a Gemini key into a resource-management credential.

Framework mapping

Control	NIST CSF 2.0	NIST SP 800-53 Rev. 5	Threat reference
Key inventory and ownership	PR.AA-01	AC-2, IA-5	ATT&CK T1552.001 Credentials In Files
API and application restrictions	PR.AA-05	AC-6, SC-7	ATT&CK T1078.004 Cloud Accounts
No embedded keys in clients	PR.AA-01	IA-5(7)	ATLAS AML.T0012 Valid Accounts
Usage and billing monitoring	DE.CM-03	AU-6	ATT&CK T1496.004 Cloud Service Hijacking; OWASP LLM10:2025 Unbounded Consumption

Practitioner checklist

Inventory every API key and enabled API across all projects in the organisation.
Give every key an API restriction and the right application restriction.
Remove the Generative Language API from every publicly exposed key.
Keep Gemini and other AI APIs in projects with no public client keys.
Use authorization keys only for Gemini, with IP restriction and a bound account holding no roles.
Send keys in the x-goog-api-key header, never in URLs.
Delete keys with no traffic in 90 days and keys with no owner.
Limit API Keys Admin and API enablement rights to a platform team.
Alert on key restriction changes, API enablement and budget thresholds.
Scan code, builds and app packages for AIza keys and test their reach.

Google API Keys Security Guide: Restrictions, Authorization Keys and Gemini Exposure