Leaked Google API Key? Restrict, Rotate and Check Usage

A Google API key is a single string that identifies your Google Cloud project to Google services. Unlike an OAuth token it carries no user identity: any request made with the key is attributed and billed to your project, for every API the key is allowed to call. How bad a leak is depends almost entirely on those restrictions. An unrestricted key is an open tab on your account; a key locked to one API and one website is a minor incident. Either way, replace it and then find out which of the two you had.

Check your GitHub account for leaked secrets — free

Provider: Google
Severity: High
Impact: Cloud infrastructure access
Checked live by LeakWatch: Yes
Revoke at: Google Cloud

What a Google API key looks like

Google API keys share one recognizable shape, whatever the service they are used for:

AIza…XXXX   Google API key (masked)

The same format is used by Maps, YouTube Data, Firebase, Gemini and many other APIs, so the prefix does not tell you which service the key was made for. You can see that in the Cloud console: open the key and read its API restrictions.

Two things are not this secret. A Google OAuth client secret (GOCSPX-…) belongs to a different login flow and has its own rotation steps. A service account JSON file is a much bigger credential: if that is what you leaked, use the GCP service account key guide.

One nuance worth knowing: Firebase web configuration files contain an AIza key on purpose, and Google documents that key as an identifier rather than a secret, protected by Firebase security rules. Finding it in a front-end repository is not by itself an incident. The same format in a backend .env file, or with a Gemini or Cloud API enabled, is.

How Google API keys get leaked

Keys embedded in front-end code. A Maps or Places key in a web page or mobile app is visible to every visitor by design, which is why it must be restricted to your domain or app.
Committed config. google-services.json, .env files and config.js copied into a repository together with a key that had no restrictions.
Switching on a new API later. A key created for Maps and restricted to nothing quietly gains access to every API you enable on the project afterwards, including paid ones.
Notebooks and demos. A Gemini key pasted into a Colab cell or a tutorial repository, then published with the output.
Screenshots and logs. Browser developer tools or a request URL (?key=AIza…) shared in a bug report.

What to do in the first hour

Create a replacement key first. In the Google Cloud console go to APIs & Services → Credentials → Create credentials → API key. Before you use it, open the new key and set an API restriction (only the APIs the app really calls) and an application restriction (HTTP referrers for web, IP addresses for servers, package name and fingerprint for Android, bundle ID for iOS).
Deploy the new key, then go back to Credentials and delete the old one. Deleting is what actually ends the exposure; there is no benefit in keeping an exposed key around “just in case”.
Check which APIs the old key could call. Before you delete it, note its API restrictions. No restrictions means every enabled API in the project.
Check usage. Open APIs & Services → Metrics and filter by the credential for the period since the exposure. A spike, an API you never call or odd hours are the signs. Usage numbers can lag by hours, so look again later.
Check billing. Under Billing → Reports, compare the daily cost with your normal level. Set a budget alert and, where the API supports it, a per-API quota cap, so a stolen key cannot run up a large bill unnoticed.
Review the project, not only the key. Disable APIs you do not use, and check IAM for unfamiliar accounts. A leaked API key does not grant IAM access, but a project that has one exposed key often has other weak spots.
Then clean the repository: remove the value and rewrite history if you want to. See I accidentally pushed an API key to GitHub.

Not sure what else leaked? Run a free scan.

Revoke it at Google Cloud

Open console.cloud.google.com/apis/credentials, make sure you are in the right project (keys belong to a project, and a key you cannot find is probably in another one), and delete the key. If the key was created from Google AI Studio for Gemini, it is still a Google Cloud project key and shows up under the same Credentials page. After deletion, requests with the old value fail.

How LeakWatch detects it

LeakWatch recognizes the AIza prefix followed by the base64-style body Google uses. All Google services share that format, so LeakWatch cannot tell which one a key was created for. This type is checked live against the Generative Language (Gemini) API with a read-only request that lists available models. It does not generate any content and does not spend credits. A key restricted to other APIs, such as Maps only, may therefore not show as active in that check even though it is a real key: do not take “not confirmed” as “safe”.

LeakWatch can check whether a detected key is still active with a read-only request to Google. It never reads your data or spends your credits.

FAQ

Is a Google Maps key in my website's JavaScript a leak?

Not on its own: Maps keys are meant to be visible. It becomes a problem when the key has no HTTP referrer restriction, because anyone can then copy it and use it on their own site at your expense. Add the restriction.

Can someone read my Google data with an API key?

Not your Gmail or Drive: those need OAuth consent from a signed-in user. An API key reaches only the project-level APIs it is allowed to call, which is why the damage is mostly abuse and cost, unless the APIs enabled are sensitive ones such as Gemini.

Should I regenerate the key instead of creating a new one?

Either achieves the goal, as long as the old value stops working. Creating a new restricted key and deleting the old one lets you add restrictions from day one and gives you a clean cut-over.