API keys should allow access only to APIs needed by the application

API keys are insecure 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.

Unrestricted keys, or ones allowing cloudapis.googleapis.com, expand attack surface. A leaked key can call many APIs without identity, enabling data exposure, unintended changes on permissive endpoints, and quota/billing exhaustion. API keys are insecure because they can be viewed publicly, such as from within a browser, or they can be accessed on a device where the key resides.

What this control checks

API keys are limited to only the APIs the application needs

Common pitfalls

Broad cloudapis.googleapis.com fails the check

The finding checks that keys are restricted to named Google APIs and do not include the broad cloudapis.googleapis.com.

Audit evidence

Evidence that deployed resources meet this control: Prowler check apikeys_api_restrictions_configured (prowler gcp --checks apikeys_api_restrictions_configured); PowerPipe control gcp_compliance.control.iam_api_key_restricts_apis.

Framework-specific interpretation

PCI DSS v4.0: Mapped to 10.2.1.2 (Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of...).

ISO/IEC 27001:2022: Mapped to A.8.12 (Data Leakage Prevention).

NIS2 Directive (EU 2022/2555): Mapped to 6.1.2.b (requirements regarding security updates throughout the entire lifetime of the ICT services or ICT products, or...), 6.2.2.b (apply principles for engineering secure systems and secure coding principles to any information system development...), 9.2.a (in accordance with the relevant entities classification of assets, the type, strength and quality of the cryptographic...) and 7 more clauses.

NIST SP 800-53 Rev 5: Mapped to PL-8 (Information Security Architecture) and SA-8 (Security Engineering Principles).

NIST Cybersecurity Framework v2.0: Mapped to PR.AA-01 (Identities and credentials for authorized users, services, and hardware are managed by the organization.), PR.AA-03 (Users, services, and hardware are authenticated.) and PR.AA-05 (Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and...).

Framework mappings

The clauses this control is mapped to in each framework.

PCI DSS v4.0

10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.

ISO/IEC 27001:2022

A.8.12 Data leakage prevention

NIS2 Directive (EU 2022/2555)

6 Security in network and information systems acquisition, development and maintenance
9 Cryptography

NIST SP 800-53 Rev 5

PL-8 Information Security Architecture
SA-8 Security Engineering Principles

NIST Cybersecurity Framework v2.0

PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization.
PR.AA-03
PR.AA-05

CIS GCP Benchmark v3.0.0

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

CIS GCP Benchmark v4.0.0

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

BSI C5:2025

IAM-08.05B The cloud service provider documents, communicates and makes available to all users under its responsibility rules and recommendations for the management of credentials, including at least: - Non-reuse of credentials;- Trade-offs between entropy and ability to memorise;-...
PSS-05.01B The cloud service provider provides authentication mechanisms that can force strong authentication (e.g. two or more factors) for users, IT components or applications within the cloud users' area of responsibility. These authentication mechanisms are set up at all access points that...

CIS GCP Benchmark v1.2.0