> Retroactive Privilege Expansion. You created a Maps key three years ago and embedded it in your website's source code, exactly as Google instructed. Last month, a developer on your team enabled the Gemini API for an internal prototype. Your public Maps key is now a Gemini credential. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill. Nobody told you.

Malpractice/I can't believe they're just rolling forward

▲

crest 8 hours ago | parent | next [-]

They should limit the new features to new API keys that explicitly opt-in instead of fucking over every user who trusted their previous documentation that these keys are public information.

	▲	abustamam 24 minutes ago \| parent [-]
		Isn't it standard practice to harden permissions on API keys? Like, if I were a bootstrapped startup maybe I'd take shortcuts and let an API key have a * permission but not for anything that could rack up thousands of dollars in bills for the customer. But at googles scale that just seems irresponsible.

▲

charcircuit 8 hours ago | parent | prev [-]

Maps keys should not be made public otherwise an attacker can steal them and drain your wallet and use it for their own sites.

▲

grey-area 7 hours ago | parent | next [-]

Maps keys are always public in js on the website (but locked to use on certain domains). That’s how they work.

▲

charcircuit 7 hours ago | parent [-]

It is not actually locked to a site is just based off the host header. Which is public information an attacker can use to make the requests.

▲

nl 3 hours ago | parent | next [-]

Sure, but the practical form of this attack is limited.

You can't maliciously embed it in a site you control to either steal map usage or run up their bill because other people's web browsers will send the correct host header.

That means you can use a botnet or similar to request it using a a script. But if you are botnetting Google will detect you very quickly.

	▲	KomoD 2 hours ago \| parent [-]
		> But if you are botnetting Google will detect you very quickly. They don't do anything against that.

▲

grey-area 7 hours ago | parent | prev [-]

Is there a way to use Google maps apis on the web without exposing the key?

Re host header seems an odd way for Google to do it, surely they would have fixed that by now? I guess not a huge problem as attackers would have to proxy traffic or something to obscure the host headers sent by real clients? Any links on how people exploit this?

▲

KomoD 2 hours ago | parent | next [-]

What is there to fix? It was designed this way.

Something that can be abused is if the key also has other Maps APIs enabled, like Places API, Routes API or Static APIs especially for scraping because those produce valuable info beyond just embedding a map.

The only suggestions I have are:

- If you want to totally hide the key, proxy all the requests through some server.

- Restrict the key to your website.

- Don't enable any API that you don't use, if you only use the Maps Javascript API to embed a map then don't enable any other Maps API for that key.

▲

yla92 7 hours ago | parent | prev [-]

Google's own recommended practices https://developers.google.com/maps/api-security-best-practic...

	▲	grey-area 7 hours ago \| parent [-]
		It would be helpful if you answer the question about web api usage, most of that is not relevant. The only suggestion I see there from a quick skim that would avoid the above is for customers to set up a google maps proxy server for every usage with adds security and hides the key. That is completely impractical suggestion for the majority of users of embedded google maps.

▲

IanCal 7 hours ago | parent | prev [-]

It’s been years but I thought I recalled having to use the key but then also setting what sites it’d work on.

	▲	charcircuit 7 hours ago \| parent [-]
		If an attacker can figure out what sites it can be used on, they can use the API.