2

I'm using the google maps API, which has a secret key that I need to use on the client side.

I was thinking of some alternatives to store it safely. One of them is storing it in my flask database. Then the front-end can send a query to obtain it.

Is there a way to do this safely by encryption?

4
  • Is there any reason you can't just store the API key on the page when it first loads? If the client is going to have it at some point, I don't think not making it more secure by requiring the AJAX call first to get the key.
    – neilsimp1
    Commented Sep 27, 2019 at 12:06
  • I'm using reactJS with create react app. Putting secret keys in environment variables is not safe according to its docs Commented Sep 27, 2019 at 12:12
  • WARNING: Do not store any secrets (such as private API keys) in your React app! Environment variables are embedded into the build, meaning anyone can view them by inspecting your app's files. Commented Sep 27, 2019 at 12:23
  • Calling an AJAX endpoint to get the key doesn't sound any more secure then storing it in the JS directly. As @Ryathal said, if you really want to secure it, call your server to in turn call the Google API.
    – neilsimp1
    Commented Sep 27, 2019 at 15:18

4 Answers 4

4

Anything that ends up on the client in an unencrypted form can be accessed by the client. There's no way to avoid this. You have not control over what the client is doing with the responses that come from your server. The best you can do in this situation is obfuscate and/or try to make it more difficult for someone to access the key directly.

In situations like this, where you want to be able to allow your client to make direct calls to a third-party under your authority, you need some sort of token, ticket, or signing system which allows you to grant specific access to the client in a way that the 3rd-party provider can verify without giving the client your credentials.

I didn't spend much time looking into it and it's not really in the scope of this site to assist with the specifics of Googles API but as an example of how this works, it appears that this API provides a signature system. If I understand correctly, you would create a bare URL for the request that your client needs to make, and then using your credentials you get a signed URL from the API. This happens on your server, you would never provide your key to the client.

This signed URI would then be given back to the client and they can execute the call and the API will know that this is associated with your authority and billing. Presumably there is some sort of time limit on this signed URL. For those details, refer to the API documentation.

4

If you want to keep a key safe you leave it on the server side and make the call from there. If you want to not have the extra hop you must compromise your key to some degree, there is nothing you can do client side to hide from a determined client. Users have full control over their browser, there isn't anything you can do that they can't undo.

0

I think you don’t need to worry about Google Maps secret key being insecure. You can put restrictions on the referrer in your Google Maps API console.

Google earlier suggested to keep that key in html head tag. This itself gives me an indication that I don’t need to worry much.

Read this SO links: https://stackoverflow.com/questions/8729976/does-google-maps-javascript-api-key-v3-need-to-be-kept-secret-in-html-checked

https://stackoverflow.com/questions/1364858/what-steps-should-i-take-to-protect-my-google-maps-api-key

-1

Dont store it in the front end.

Instead:

Client -> Service Proxy -> Google

Your client calls a Proxy service that you own. The proxy calls Google. The key is stored with the proxy.

Do not include your key with the client.

It's a little bit of extra effort with this but your private API key stays private in this scenario.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.