1.14 Ensure API Keys Are Restricted to Only APIs That Application Needs Access

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

API keys are always at risk because they can be viewed publicly, such as from within a browser, or they can be accessed on a device where the key resides. It is recommended to restrict API keys to use (call) only APIs required by an application.

Rationale:

Security risks involved in using API-Keys are below:

API keys are simple encrypted strings

API keys do not identify the user or the application making the API request

API keys are typically accessible to clients, making it easy to discover and steal an API key

In light of these potential risks, Google recommends using the standard authentication flow instead of API-Keys. However, there are limited cases where API keys are more appropriate. For example, if there is a mobile application that needs to use the Google Cloud Translation API, but doesn't otherwise need a backend server, API keys are the simplest way to authenticate to that API.

In order to reduce attack surfaces by providing least privileges, API-Keys can be restricted to use (call) only APIs required by an application.

Impact:

Setting API restrictions may break existing application functioning, if not done carefully.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

From Console:

Go to APIs & Services\Credentials using https://console.cloud.google.com/apis/credentials

In the section API Keys, Click the API Key Name. The API Key properties display on a new page.

In the Key restrictions section go to API restrictions.

Click the Select API drop-down to choose an API.

Click Save.

Repeat steps 2,3,4,5 for every unrestricted API key

Note: Do not set API restrictions to Google Cloud APIs, as this option allows access to all services offered by Google cloud.

Default Value:

By default, API restrictions are set to None.

See Also

https://workbench.cisecurity.org/files/3817