AppInspected

Fix guides

There's a Google API key in your website's code. Here's how to lock it down.

Last reviewed October 19, 2026 against the providers' current documentation.

The short version

Some Google keys have to be in the browser (the Maps JavaScript API needs one), so the fix is usually restriction, not hiding. In the Google Cloud console, limit the key to your website's domains and to only the APIs your page calls. Make sure it can't call the Gemini API or any paid web-service API meant for servers. If you can't restrict it, or you see usage you don't recognize, rotate it.

Why it matters

A Google API key tells Google which project to bill. If the key has no restrictions, anyone who copies it from your JavaScript can use it from their own site or script, for any API enabled in your Google Cloud project, and you pay. Google's Maps documentation says plainly that you're financially responsible for charges caused by abuse of unrestricted keys. Since the Gemini API arrived, the stakes went up: in February 2026 Truffle Security reported that public Google keys in projects with the Gemini API enabled could call it, and found 2,863 live keys like that on public websites. Google has since tightened the Gemini API and rejects unrestricted standard keys, but a key that is restricted to a list that includes Gemini still works.

Fix it, in this order

  1. Find out which key it is and what it's for

    Our free check flags AIza… keys that aren't part of a Firebase config. Search your code for the key, then open Google Cloud console → APIs & Services → Credentials (for Maps keys: Google Maps Platform → Credentials) and find the key with the same value. Note what your page actually uses it for: a map, Places autocomplete, YouTube, Translate, Gemini…

  2. Restrict it to your website

    Edit the key and under Application restrictions choose Websites. Add your domain, for example example.com/*, and *.example.com/* if you use subdomains; Google's docs note that allowing a whole domain takes both entries. Use a separate key for local development instead of adding localhost to your production key. A key can have only one kind of application restriction.

  3. Restrict it to the APIs it needs

    Under API restrictions, choose Restrict key and tick only the APIs your page calls. For a map with autocomplete that might be the Maps JavaScript API and the Places API. Leave the Generative Language API (Gemini) off any key that's in public code: Firebase's docs say never to allowlist the Gemini Developer API on a publicly accessible key. Save. Then turn off APIs your project doesn't use at all under APIs & Services, which blocks them for every key in the project.

  4. Move server-only APIs to your server

    Some Google APIs are web services meant to be called from a server, such as the Geocoding, Directions or Places web service endpoints called over HTTP, and the Gemini API. Google says keys for those shouldn't be public and that client code shouldn't hold them. Put those calls behind a small server endpoint (an API route, a Supabase Edge Function, a Cloudflare Worker) that reads a separate, IP- and API-restricted key from a server-only environment variable.

  5. Check usage, then rotate if needed

    In Monitoring → Metrics explorer, filter by the key's credential to see which APIs it has been calling. If you see traffic you don't recognize, or the key can't be restricted, use Rotate key on the key's page: the new key keeps the old restrictions, both work during the overlap, and you delete the previous key once your site has switched. Google's Maps guidance treats rotation as the last step after restricting, because a restricted key is already of little use to anyone else.

  6. Set a budget alert

    Create a budget under Billing → Budgets & alerts so you hear about a spike early. Google notes that an alerts-only budget doesn't cap spending, so restrictions are still what actually limits misuse.

Or ask your AI tool to do it

Paste this into Lovable, Bolt, Cursor, Claude Code or whichever tool built your app. Review what it changes before you deploy.

My website's frontend contains a Google API key (starts with AIza). List every place the app uses a Google API key and which Google API each call goes to. Keep in the browser only the key for client-side APIs (such as the Maps JavaScript API), and tell me which APIs to allow on it. Move every call to server-side Google web services (Geocoding, Directions, Places web service, Gemini / Generative Language API, Translate and similar) into a server-side endpoint that reads a separate key from a server-only environment variable, requires a logged-in user where possible, and rate-limits requests. Do not put the server key in any VITE_, NEXT_PUBLIC_ or EXPO_PUBLIC_ variable. Finally, give me the exact website restrictions (domains) and API restrictions to set for each key in the Google Cloud console.

How this happens

Google's keys look the same whatever they're for, and for years the advice for the Maps JavaScript API was simply to paste the key into the page. AI coding tools follow that pattern for every Google API, including ones meant for servers, and they rarely open the Cloud console to add restrictions. New keys start out unrestricted, so a key made for one map can quietly work for every API the project has enabled, including ones added later.

Check that it's really fixed

After you deploy, run the free check. It reads your live site the way an attacker would and tells you if any secret key is still visible.

Check my app free

Topic check: Exposed API key checker

Questions

Is a Google Maps API key supposed to be public?

A key used by the Maps JavaScript API in a webpage will always be visible, so it doesn't have to be secret. It does have to be restricted: limited to your websites and to the Maps APIs the page uses. Keys for Google's web-service APIs and for Gemini are different; keep those on a server.

My key is a Firebase key. Do I need to do anything?

Firebase web keys are meant to be in your app, and Firebase restricts the keys it creates to Firebase APIs. What protects your data is your Security Rules (see Firestore test mode rules). Firebase recommends separate, restricted keys for any non-Firebase Google API, and never allowing the Gemini API on a public key.

Will restricting the key break my site?

It can, if you miss a domain or an API your page uses. Add every domain you serve the site from (including www and preview domains you care about), then test the map or feature in a private window. Errors in the browser console usually name the blocked API or referrer.

Can someone fake my domain to get around website restrictions?

Website restrictions check the referrer the browser sends, which a script outside the browser can set to anything. That's why API restrictions matter too: even if someone gets past the website check, the key can only call the few client-side APIs you allowed. For Maps JavaScript and Places, Google also offers App Check as an extra layer.

Does your check know which Google API my key is for?

No. The free check is passive: it sees the key in your public JavaScript and whether a Firebase config is next to it, but it doesn't call Google with your key. Only the Cloud console shows which restrictions and APIs a key has.

I removed the key from my code. Is that enough?

If the key was unrestricted, no. Old copies of your JavaScript stay in caches and archives. Restrict the key, check its usage, and rotate it if anything looks wrong.

Sources

Related guides