Does the API key need to be public to be used? (Discussion)

[spenserschwartz]

Hi there, I've noticed that you get a hydration error when trying to use a non-public API key in your .env file (in Nextjs, but I imagine this would happen everywhere). I'm fairly certain I've seen that this is required, but I can't find the documentation stating as much anymore. Is this by design, and what is the recommended way to protect your API? Currently, I am setting website restrictions on the API key via Google Cloud, but want to see what everyone else is doing.

[mrMetalWood]

Yes, there is no way to load the Google Maps Api in the browser without also providing the API key in the browser (which is public for everyone).

Basically there are three ways to protect your key and usage:

• Website referrer restrictions (as you already did)
• API restrictions (only allow Maps API/Places API for a specific key for example)
• Add quota restrictions for a key or an API (certain amount of requests per hour/day/user)

[spenserschwartz]

Thank you @mrMetalWood. It's a shame it's set up as so 🤷

[Code-Victor]

@spenserschwartz Could you share how you set up website restrictions on your API key? I'd love to understand your approach.

@mrMetalWood Would you consider adding a section on key protection in your documentation? It would be incredibly helpful—thank you!

[alamenai]

I store the key in the deployment platform env configuration then I use action to get them and use them.

@mrMetalWood , does that mean they are public for the usage?

[usefulthink]

In the browser, you (and every visitor of your site) can always see the API key in the network tab of the developer tools – they become part of the URL that loads the Maps JavaScript API.

[AnshhSingh]

Did anyone find a better method? i dont want to expose my maps key to browsers!

[usefulthink]

The usual approach to this is to restrict the key as much as possible; then it will typically be safe to expose to the public.

My Recommendations (see also):

• use projects in the cloud console, and individual keys for applications
• use different keys for development and production and make them easily replaceable
• enable only the APIs for the key that are actually used
• restrict the key to the domain/path of the site you're using it on
• configure billing-alerts in the could console
• set up reasonable quotas for the maps APIs
• the new routes and places APIs additionally support Firebase AppCheck to prevent misuse

Also, especially after deploying new applications or bigger changes, regularly check the stats in the cloud console to be what you expected. And if you still see something suspicious happening, rotate the keys and report it to the maps platform support in the cloud console.

[AnshhSingh]

That's a pretty reasonable approach!