Search-Only API Keys on mobile
When running your app with the search only key embedded in your app, you might notice the following warning:
Warning: If you are building a native app on mobile, be sure to not include the search API key directly in the source code. You should instead consider fetching the key from your servers during the app’s startup
This follows our mobile security recommendations as people can potentially have access to this key. Moreover, having your key on your server gives you more flexibility as you would be able to make changes to it if needed without having to deploy a new app version to the AppStore.
What you have to do is have your API key in one of your servers, and then fetch it through a network request when the app starts. There are a ton of ways to set it up on a server, and there are a ton of backend programming languages that you can use, so feel free to use any that is comfortable to you. For example, here is a tutorial online on fetching a remote configuration file. There are plenty of other tutorials online that can help you achieve this if you Google it.
Secured API Keys
As seen in our previous section on Search Only Keys, mobile applications represent significant security risks to your API keys, and the inflexibility of mobile applications make secure operations more difficult.
API keys should not be hardcoded in the shipped mobile applications; they should always be dynamically fetched from the application backend. The reason behind this recommendation is that users might not update your application as often as it would be desired. When you then rotate your API key as part of the security workflow or the key leaks and you need to revoke it, the installed application stops working.
It is also important to keep in mind that the application, which might look secured, can be easily opened by existing tools and your API keys extracted from it. Therefore, don’t give your mobile application API keys more privileges than is necessary and use Secured API keys with expiration times.