This document helps you identify Google Cloud products and mitigation strategies that can help you defend against common application-level attacks that are outlined in OWASP Top 10. OWASP Top 10 is a list by the Open Web Application Security (OWASP) Foundation of the top 10 security risks that every application owner should be aware of. Although no security product can guarantee full protection against these risks, applying these products and services when they make sense in your architecture can contribute to a strong multi-layer security solution.
Google infrastructure is designed to help you build, deploy, and operate services in a secure way. Physical and operational security, data encryption at rest and in transit, and many other important facets of a secure infrastructure are managed by Google. You inherit these benefits by deploying your applications to Google Cloud, but you might need to take additional measures to protect your application against specific attacks.
The mitigation strategies listed in this document are sorted by application security risk and Google Cloud product. Many products play a role in creating a defense-in-depth strategy against web security risks. This document provides information about how other products can mitigate OWASP Top 10 risks, but it provides additional detail about how Google Cloud Armor and Apigee can mitigate a wide range of those risks. Google Cloud Armor, acting as a web application firewall (WAF), and Apigee, acting as an API gateway, can be especially helpful in blocking different kinds of attacks. These products are in the traffic path from the internet and can block external traffic before it reaches your applications in Google Cloud.
Product overviews
The Google Cloud products listed in the following table can help defend against the top 10 security risks:
Product | Summary | A01 | A02 | A03 | A04 | A05 | A06 | A07 | A08 | A09 | A10 |
---|---|---|---|---|---|---|---|---|---|---|---|
Access Transparency | Expand visibility and control over your cloud provider with administrator access logs and approval controls | ✓ | ✓ | ||||||||
Apigee | Design, secure, and scale application programming interfaces | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||
Artifact Registry | Centrally stores artifacts and build dependencies | ✓ | |||||||||
Binary Authorization | Ensure only trusted container images are deployed on Google Kubernetes Engine | ✓ | ✓ | ||||||||
Cloud Asset Inventory | View, monitor, and analyze all your Google Cloud and Google Distributed Cloud or multi-cloud assets across projects and services | ✓ | ✓ | ✓ | ✓ | ||||||
Cloud Build | Build, test, and deploy in Google Cloud | ✓ | |||||||||
Cloud Key Management Service | Manage encryption keys on Google Cloud | ✓ | ✓ | ||||||||
Cloud Load Balancing | Control which ciphers your SSL proxy or HTTPS load balancer negotiates | ✓ | ✓ | ✓ | ✓ | ||||||
Cloud Logging | Real-time log management and analysis at scale | ✓ | |||||||||
Cloud Monitoring | Collect and analyze metrics, events, and metadata from Google Cloud services and a wide variety of applications and third-party services | ✓ | |||||||||
Cloud Source Repositories | Store, manage, and track code in a single place for your team | ✓ | |||||||||
Google Cloud Armor | A web application firewall (WAF) deployed at the edge of Google's network to help defend against common attack vectors | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
Google Cloud security bulletins | The latest security bulletins related to Google Cloud products | ✓ | |||||||||
Google Security Operations | Automatically find threats in real time and at scale using Google's infrastructure, detection techniques, and signals | ✓ | |||||||||
Identity Platform | Add identity and access management capabilities to applications, protect user accounts, and scale identity management | ✓ | ✓ | ||||||||
Identity-Aware Proxy (IAP) | Use identity and context to guard access to your applications and VMs | ✓ | ✓ | ✓ | |||||||
reCAPTCHA | Help protect your website from fraudulent activity, spam, and abuse | ✓ | |||||||||
Secret Manager | Store API keys, passwords, certificates, and other sensitive data | ✓ | ✓ | ||||||||
Security Command Center | Centralized visibility for security analytics and threat intelligence to help identify vulnerabilities in your applications | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Sensitive Data Protection | Discover, classify, and protect your most sensitive data | ✓ | ✓ | ✓ | |||||||
Titan Security Keys | Help protect high-value users with phishing-resistant 2FA devices that are built with a hardware chip (with firmware engineered by Google) to verify the integrity of the key | ✓ | |||||||||
Virtual Private Cloud firewalls | Allow or deny connections to or from your virtual machine (VM) instances | ✓ | |||||||||
VirusTotal | Analyze suspicious files and URLs to detect types of malware; automatically share them with the security community | ✓ | ✓ | ||||||||
VPC Service Controls | Isolate resources of multi-tenant Google Cloud services to mitigate data exfiltration risks | ✓ | ✓ |
A01: Broken access control
Broken access control refers to access controls that are only partially enforced on the client side, or weakly implemented. Mitigating these controls often requires a rewrite on the application side to properly enforce that resources are accessed only by authorized users.
Apigee
Use case:
- Access control enforcement
- Limit data manipulation
Apigee supports a layered approach to implement access controls to keep the bad actors from making unauthorized changes or accessing the system.
Configure role-based access control (RBAC) to only allow users access to the resources and configuration that they need. Create encrypted key value maps to store sensitive key-value pairs, which appear masked in the Edge UI and in management API calls. Configure single sign-on with your company's identity provider.
Configure developer portals to show specific API products according to user role. Configure the portal to show or hide content based on user role.
Cloud Asset Inventory
Use case:
- Monitor for unauthorized IT (also known as shadow IT)
- Outdated compute instances
One of the most common vectors for data exposure is orphaned or unauthorized IT infrastructure. Set up real-time notifications to alert you for unexpected running resources, which might be improperly secured or using outdated software.
Cloud Load Balancing
Use case:
- Fine-grained SSL and TLS cipher control
Prevent the use of weak SSL or TLS ciphers by assigning a predefined group or custom list of ciphers that Cloud Load Balancing can use.
Google Cloud Armor
Use case:
- Filter cross-origin requests
- Filter local or remote file inclusion attacks
- Filter HTTP parameter pollution attacks
Many cases of broken access control cannot be mitigated by using a web application firewall, because applications don't require or don't properly check access tokens for every request, and data can be manipulated client side. Multiple Juice Shop challenges related to broken access control. For example, posting feedback in another user's name uses the fact that some requests are not authenticated server side. As you can see in the challenge solution, the exploit for this vulnerability is completely client-side and can therefore not be mitigated using Google Cloud Armor.
Some challenges can be partially mitigated server side if the application cannot be immediately patched.
For example, if cross-site request forgery (CSRF) attacks are possible because your web server implements cross-origin resource sharing (CORS) poorly, as demonstrated in the CSRF Juice Shop challenge, you can mitigate this issue by blocking requests from unexpected origins altogether with a custom rule. The following rule matches all requests with origins other than example.com and google.com:
has(request.headers['origin']) &&
!((request.headers['origin'] == 'https://example.com')||
(request.headers['origin'] == 'https://google.com') )
When traffic that matches such a rule is denied, the solution for the CSRF challenge stops working.
The
basket manipulation challenge
uses
HTTP parameter pollution (HPP)
so that you can see how to attack the shop by following the
challenge solution.
HPP is detected as part of the protocol attack rule set. To help block this kind of attack, use the following rule:
evaluatePreconfiguredExpr('protocolattack-stable')
.
Identity-Aware Proxy and Context-Aware Access
Use case:
- Centralized access control
- Works with cloud and on-premises
- Protects HTTP and TCP connections
- Context-Aware Access
IAP lets you use identity and context to form a secure authentication and authorization wall around your application. Prevent broken authorization or access control to your public-facing application with a centrally managed authentication and authorization system built on Cloud Identity and IAM.
Enforce granular access controls to web applications, VMs, Google Cloud APIs, and Google Workspace applications based on a user's identity and the context of the request without the need for a conventional VPN. Use a single platform for both your cloud and on-premises applications and infrastructure resources.
Security Command Center
Security Command Center includes two services that help you address broken access controls: Security Health Analytics and Web Security Scanner.
Security Health Analytics supports the following use cases:
- MFA or 2FA enforcement
- API key protection
- SSL policy monitoring
Security Health Analytics helps prevent broken access control by monitoring for multi-factor authentication compliance, SSL policy, and the health of your API keys.
Web Security Scanner supports the following use cases:
- Repositories exposed to the public
- Insecure request header validation
Web Security Scanner scans your web applications for vulnerabilities, such as publicly visible code repositories and misconfigured validation of request headers.
A02: Cryptographic failures
Cryptographic failures can happen due to a lack of encryption or weak encryption in transit, or accidentally exposed sensitive data. Attacks against those vulnerabilities are usually specific to the application and therefore, need a defense-in-depth approach to mitigate.
Apigee
Use case:
- Protect sensitive data
Use one-way and two-way TLS to guard sensitive information at the protocol level.
Use policies such as Assign Message policy and JavaScript policy to remove sensitive data before it's returned to the client.
Use standard OAuth techniques and consider adding HMAC, hash, state, nonce, PKCE, or other techniques to improve the level of authentication for each request.
Mask sensitive data in the Edge Trace tool.
Encrypt sensitive data at rest in key value maps.
Cloud Asset Inventory
Use case:
- Search service
- Access analyzer
One of the most common vectors for data exposure is orphaned or unauthorized IT infrastructure. You can identify servers that nobody is maintaining and buckets with over-broad sharing rules by analyzing the cloud asset time series data.
Set up real-time notifications to alert you to unexpected provisioning of resources which might be improperly secured or unauthorized.
Cloud Data Loss Prevention API (part of Sensitive Data Protection)
Use case:
- Sensitive data discovery and classification
- Automatic data masking
The Cloud Data Loss Prevention API (DLP API) lets you scan for any potentially sensitive data stored in buckets or databases to prevent unintended information leakage. If disallowed data is identified, it can be automatically flagged or redacted.
Cloud Key Management Service
Use case:
- Secure cryptographic key management
(Cloud KMS) helps to prevent potential exposure of your cryptographic keys. Use this cloud-hosted key management service to manage symmetric and asymmetric cryptographic keys for your cloud services the same way that you do on-premises. You can generate, use, rotate, and destroy AES256, RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 cryptographic keys.
Cloud Load Balancing
Use case:
- Fine-grained SSL and TLS cipher control
SSL policies can help prevent sensitive data exposure by giving you control over the SSL and TLS features and ciphers that are allowed in a load balancer. Block unapproved or insecure ciphers as needed.
Google Cloud Armor
Use case:
- Filter known attack URLs
- Restrict sensitive endpoint access
In general, sensitive data exposure should be stopped at the source, but because every attack is application specific, web application firewalls can only be used in a limited way to stop data exposure broadly. However, if your application can't be immediately patched, you can restrict access to vulnerable endpoints or request patterns by using Google Cloud Armor custom rules.
For example, several Juice Shop challenges about sensitive data exposure can be exploited due to insecure directory traversal and null byte injection attacks. You can mitigate these injections by checking for the strings in the URL with the following custom expression:
request.path.contains("%00") || request.path.contains("%2500")
You can
solve
the
exposed metrics
challenge by accessing the /metrics
subdirectory that is used by Prometheus.
If you have a sensitive endpoint that is exposed and you can't immediately remove
access, you can restrict access to it except for certain IP address ranges. Use
a rule similar to the following custom expression:
request.path.contains("/metrics") && !(inIpRange(origin.ip, '1.2.3.4/32')
Replace 1.2.3.4/32
with the IP address
range that should have access to the metrics interface.
Accidentally exposed log files
are used to solve one of the Juice Shop challenges. To avoid exposing logs, set
a rule disallowing access to log files completely:
request.path.endsWith(".log")
.
Identity-Aware Proxy and Context-Aware Access
Use case:
- Secure remote access to sensitive services
- Centralized access control
- Context-Aware Access
Use identity and context to form a secure authentication and authorization perimeter around your application. Deploy tools, such as internal bug reporting, corporate knowledge base, or email behind IAP, in order to allow Context-Aware Access to only authorized individuals from anywhere on the internet.
With Context-Aware Access, you can enforce granular access controls to web applications, virtual machines (VMs), Google Cloud APIs, and Google Workspace applications based on a user's identity and context of the request without a conventional VPN. Based on the zero-trust security model and Google's BeyondCorp implementation, Context-Aware Access lets you provide access for your users, enforce granular controls, and use a single platform for both your cloud and on-premises applications and infrastructure resources.
Secret Manager
Use case:
- Crypto keys
- API keys
- Other system credentials
Secret Manager is a secure storage service for your most valuable data such as API keys, service account passwords, and cryptographic assets. Centrally storing these secrets lets you rely on Google Cloud's authentication and authorization systems, including IAM, to determine whether any given request for access is valid.
Secret Manager isn't designed for massive scale operations such as credit card tokenization or individual user password storage. Such applications should rely on Identity Platform for customer identity and access management (CIAM), Cloud Identity for members of your organization, or dedicated tokenization software.
Security Command Center
Security Command Center includes two services that help you address cryptographic failures: Security Health Analytics and Web Security Scanner.
Security Health Analytics supports the following use cases:
- MFA/2FA enforcement
- API key protection
- API key rotation enforcement
- Compute image privacy
- SSH key rule enforcement
- Secure boot monitoring
- API access security
- SSL policy monitoring
- Disabled logging
- Public bucket ACL alerts
Security Health Analytics helps prevent sensitive data exposure by monitoring for multi-factor authentication compliance and the health of your API keys. Get alerts for insecure configurations in container image storage, Cloud Storage, SSL policy, SSH key policy, logging, API access, and more.
Web Security Scanner supports the following use case:
- Unencrypted passwords transmitted over the network
Web Security Scanner scans your web
applications and reports findings of errors and vulnerabilities. If your
application transmits passwords in clear
text,
Web Security Scanner generates a CLEAR_TEXT_PASSWORD
finding.
VirusTotal
Use case:
- Phishing prevention
VirusTotal lets you scan URLs for malicious content before presenting them to your users or employees, whether they're found in user input, emails, chat, logs, or other locations.
VPC Service Controls
Use case:
- Firewall for managed services
Wrap critically managed services in a firewall in order to control who can call the service and who the service can respond to. Block unauthorized egress and data exfiltration with outbound perimeter rules on services such as Cloud Run functions. Prevent requests from unauthorized users and locations to managed data stores and databases. Create secure perimeters around powerful or potentially costly APIs.
Web Application Scanner
Use case:
- Web application security risk scanner
- Source repository availability scanner
To prevent your web application from exposing sensitive data, ensure that passwords are not sent in clear text. Avoid leaking potentially devastating raw source code by checking for exposed git and Apache Subversion source code repositories. These scans are designed to cover specific OWASP top 10 controls.
A03: Injection
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into running unintended commands or accessing data without proper authorization. We recommend that user data is sanitized or filtered by the application before it is sent to an interpreter.
The following sections discuss the Google Cloud products that can help mitigate this risk.
Apigee
Use case:
- SQL injection blocking
- NoSQL injection blocking
- LDAP injection blocking
- JavaScript injection blocking
Apigee provides several input validation policies to verify that the values provided by a client match your configured expectations before allowing the further processing of the policies or rules. Apigee, acting as a gateway for the incoming API requests, runs a limit check to ensure that the payload structure falls within an acceptable range. You can configure an API proxy so that the input validation routine transforms the input in order to remove risky character sequences, and then replace them with safe values.
There are several approaches to validating input with the Apigee platform:
- JSONThreatProtection checks the JSON payload for threats.
- XMLThreatProtection checks the XML payload for threats.
- JavaScript validates parameters and headers.
- The RegularExpressionProtection policy handles SQL code injections.
- The
OASValidation
policy validates an incoming request or response message against an OpenAPI Specification (JSON or YAML). - The
SOAPMessageValidation
policy validates any XML message against their XSD schemas and can also validate SOAP messages against a WSDL definition.
Google Cloud Armor
Use case:
- SQL injection filtering
- PHP injection filtering
Google Cloud Armor can block common injection attacks before they reach your
application. For SQL injection (SQLi), Google Cloud Armor has a
predefined rule set that
is based on the
OWASP Modsecurity core rule set. You can
build security policies
that
block common SQLi attacks
defined in the core rule set by using the
evaluatePreconfiguredExpr('sqli-stable')
rule either by itself or in
conjunction with other custom rules. For example, you can limit SQLi blocking to
specific applications by using
a URL path filter.
For PHP injection, another
preconfigured rule set
exists. You can use the evaluatePreconfiguredExpr('php-stable')
rule to block common PHP injection attacks.
Depending on your application, activating the preconfigured expressions might lead to some false positives because some of the rules in the rule set are quite sensitive. For more information, see troubleshooting false positives and how to tune the rule set to different sensitivity levels.
For injection attacks other than those targeting SQL or PHP, you can create custom rules to block requests when specific keywords or escape patterns in those protocols are used in the request path or query. Make sure that these patterns don't appear in valid requests. You can also limit these rules to only be used for specific endpoints or paths that might interpret data passed to them.
Additionally, some injection attacks can be mitigated by using the preconfigured rules for remote code execution and remote file injection.
Security Command Center
Security Command Center includes two services that help you address injection flaws: Container Threat Detection and Web Security Scanner.
Container Threat Detection supports the following use cases:
- Malicious script detection
- Reverse shell detection
- Malware installation detection
The Malicious Script
Executed
detector of
Container Threat Detection
analyzes every shell script executed on the system and reports ones that look
malicious. This detector lets you discover shell command injection attacks.
After a successful shell command injection, an attacker can spawn a reverse
shell, which triggers the Reverse
Shell
detector. Alternatively, they can install malware, which triggers the Added
Binary
Executed
and Added Library
Loaded
detectors.
Web Security Scanner supports the following use cases:
- Monitoring for cross-site scripting
- Monitoring for SQL injection
Web Security Scanner scans your web applications for vulnerabilities and provides detectors that monitor for cross-site scripting and SQL injection attacks.
A04: Insecure Design
Insecure design occurs when organizations don't implement the means to evaluate and address threats during the development lifecycle. Threat modeling, when done early in the design and refine phases, and continued throughout the development and testing phases, helps organizations analyze assumptions and failure flaws. A blameless culture of learning from mistakes is key to secure design.
Apigee
Use cases:
- Input validation
- Access controls
- Fault handling
- Content protection policies
- Password management
Apigee lets you validate incoming requests and responses to your application using the OASValidation policy. In addition, to protect access, you can configure single sign-on (SSO), role-based access control (RBAC), limit access to APIs (using Auth0 for example) and restrict which IP addresses have access to your environment. Using fault handling rules, you can customize how the API proxy reacts to errors.
To protect against unsafe passwords for Apigee global users, Apigee provides password expiration, lockout, and reset password options. In addition, you can enable two-factor authentication (2FA).
Cloud Data Loss Prevention API (part of Sensitive Data Protection)
Use case:
- Identify and redact confidential data
Using the Cloud Data Loss Prevention API, you can identify confidential data and tokenize it. The DLP API can help you limit the exposure of confidential data, because after data has been tokenized and stored, you can set up access controls to restrict who can view the data. For more information, see Automating the classification of data uploaded to Cloud Storage and De-identification and re-identification of PII in large-scale datasets using Sensitive Data Protection.
Secret Manager
Use case:
- Protect storage of credentials
Secret Manager lets applications and pipelines access the values of named secrets based on permissions granted with IAM. It also provides programmatic access to secrets so automated processes can access secret values. When enabled, every interaction with Secret Manager provides an audit trail. Use these audit trails to assist with forensics and compliance needs.
Security Command Center
The Web Security Scanner service that is part of Security Command Center supports the following use case:
- Identify security vulnerabilities in your applications.
Web Security Scanner
scans your web applications for vulnerabilities. It follows links and attempts
to exercise as many user inputs and event handlers as possible. Its
CACHEABLE_PASSWORD_INPUT
detector generates a
finding if passwords entered on the web application can be cached in a regular
browser cache instead of a secure password storage.
A05: Security misconfiguration
Security misconfiguration refers to unpatched application flaws, open default accounts, and unprotected files and directories that can typically be prevented with application hardening. Security misconfiguration can happen in many ways, such as trusting default configurations, making partial configurations that might be insecure, letting error messages contain sensitive details, storing data in the cloud without proper security controls, or misconfiguring HTTP headers.
Apigee
Use case:
- Manage security configurations
- Monitor security configurations
A shared flow lets API developers combine policies and resources into a reusable group. By capturing reusable policies and resources in one place, a shared flow helps you ensure consistency, shorten development time, and manage code. You can include a shared flow inside individual API proxies using a FlowCallout policy or you can place shared flows in flow hooks to automatically run shared flow logic for every API proxy deployed in the same environment.
Cloud Asset Inventory
Use case:
- Real-time notification service
Real-time notifications can alert you to unexpected provisioning of resources that might be improperly secured or unauthorized.
Cloud Load Balancing
Use case:
- Fine-grained SSL and TLS cipher control
Prevent the usage of known-vulnerable SSL or TLS ciphers by assigning a predefined group or custom list of ciphers usable by a load balancer.
Google Cloud Armor
Use case:
- Filter insecure endpoints
- Filter local or remote file inclusion attacks
- Filter protocol attacks
Because security misconfiguration can happen at the application level, the OWASP Foundation recommends hardening and patching your application directly and removing all unnecessary functionality.
Although a web application firewall (WAF), such as Google Cloud Armor, can't help you fix the underlying misconfiguration, you can block access to parts of the application either fully or for everyone except specific IP addresses or countries. Restricting access can reduce the risk of those misconfigurations being exploited.
For example, if your application exposes an administrative interface using a
common URL such as /admin
, you can restrict access to this interface even if
it is authenticated. You can do this with a deny rule—for example:
request.path.contains("/admin") && !(inIpRange(origin.ip, '1.2.3.4/32')
Replace 1.2.3.4/32
with the IP address
range that should have access to the administrator interface.
Some misconfigurations can be partially mitigated by using the predefined local
file inclusion (LFI) or remote file inclusion (RFI) rulesets. For example,
exploiting the Juice Shop
cross-site imaging
challenge doesn't succeed when the LFI ruleset is applied. Use the
evaluatePreconfiguredExpr('lfi-stable') ||
evaluatePreconfiguredExpr('rfi-stable')
rule to block requests using the LFI
and RFI rule sets and
tune the rules
as necessary. You can verify that the
challenge solution
no longer succeeds.
Some HTTP attacks can also be mitigated using preconfigured rulesets:
- To avoid
HTTP verb tampering,
use the method enforcement rule set. Use the
evaluatePreconfiguredExpr('methodenforcement-stable')
rule to disallow HTTP request methods other than theGET
,HEAD
,POST
, andOPTIONS
methods - To block common attacks against HTTP parsing and proxies, such as
HTTP request smuggling,
HTTP response splitting,
and
HTTP header injection,
use the protocol attack rule set by using the
evaluatePreconfiguredExpr('protocolattack-stable')
rule.
Security Command Center
Security Command Center includes two services that help you address security misconfigurations: Security Health Analytics and Web Security Scanner.
Security Health Analytics supports the following use case:
- Security control monitoring and alerting
Security Health Analytics monitors many signals through a single interface to ensure your application is maintaining security best practices.
Web Security Scanner supports the following use cases:
- Web application scanner tailored for OWASP Top 10
- HTTP server configuration errors
- Mixed HTTP/HTTPS content
- XML external entity (XXE)
Web Security Scanner monitors for common security errors, such as content-type mismatches, invalid security headers, and mixed content serving. Web Security Scanner also monitors for vulnerabilities, like XXE vulnerabilities. These scans are designed to cover the OWASP top 10 controls. The following detectors scan for security misconfigurations:
INVALID_CONTENT_TYPE
INVALID_HEADER
MISMATCHING_SECURITY_HEADER_VALUES
MISSPELLED_SECURITY_HEADER_NAME
MIXED_CONTENT
XXE_REFLECTED_FILE_LEAKAGE
For more information on these and other detectors, see Overview of Web Security Scanner.
A06: Vulnerable and outdated components
Components with known vulnerabilities is a category for generic attack vectors, and such vulnerabilities are best mitigated by monitoring and quickly upgrading all of your application components.
Binary Authorization
Use case:
- Restrict GKE clusters to trusted containers
Binary Authorization is a deploy-time security control that helps ensure that only trusted container images are deployed on Google Kubernetes Engine (GKE). With Binary Authorization, you can require that images are signed by trusted authorities during the development process and then enforce signature validation when deploying. By enforcing validation, you can be assured that your build-and-release process uses only verified images.
Cloud Load Balancing
Use case:
- Fine-grained SSL and TLS cipher control
Prevent the use of known-vulnerable SSL or TLS ciphers by assigning a predefined group or custom list of ciphers that Cloud Load Balancing can use.
Google Cloud Armor
Use case:
- Block access to unused application endpoints
- Block common attack vectors
A web application firewall (WAF) like Google Cloud Armor shouldn't be used as a single mitigation strategy to block attacks against this category, because attacks are often library specific and cannot be blocked by preconfigured rule sets or cannot be patched server side. Regularly monitoring and upgrading all components of your application is the only option to mitigate these kind of vulnerabilities.
However, Google Cloud Armor can help mitigate some common attacks against vulnerable applications through its preconfigured rules for remote code execution, local file inclusion, or remote file inclusion.
If you're aware of vulnerable components in your application but can't patch the application immediately, you can block access to these parts of your application to temporarily lower the risk of an exploit of these components. Build a custom rule that matches either the URL path or queries that access these vulnerable components and deny access. If you require access to these components from specific users or locations, you can still allow certain trusted source IP addresses to access these components. A rule using the URL path looks similar to the following:
`request.path.contains("/component") && !(inIpRange(origin.ip, '1.2.3.4/32')
Replace the following:
/component
: the path of the component with known vulnerabilities1.2.3.4/32
: the IP address range that should keep access to the interface.
If there are parts of your application—for example, certain directories or file types that never need to be accessed by end users—you can also block or restrict access to these resources with a custom rule, proactively mitigating the risk if these components become vulnerable in the future.
Google Cloud Security Bulletins
Use case:
- Security bulletin monitoring
- CVEs for Google Cloud products
Google Cloud Security Bulletins are an authoritative source for security bulletins that impact Google Cloud. Posts include background information, CVE links, and recommendations for further action.
Security Command Center
Security Command Center includes three services that help you address vulnerable and outdated components: Container Threat Detection, Event Threat Detection, and Web Security Scanner.
Container Threat Detection supports the following use cases:
- Malicious script detection
- Reverse shell detection
- Malware installation detection
If an attacker exploits a vulnerable component and runs a malicious script, the
Malicious Script
Executed
detector of
Container Threat Detection
generates a finding. If an attacker spawns a reverse shell, the Reverse
Shell
detector generates a finding. If an attacker installs malware, the Added
Binary
Executed
,
and Added Library
Loaded
detectors generate findings.
Event Threat Detection supports the following use cases:
- Cryptomining detection
- Malware detection
- Data exfiltration
- Outgoing DoS
Event Threat Detection monitors your Cloud Logging stream and applies detection logic and threat intelligence at a granular level. When Event Threat Detection detects a threat, it writes a finding to Security Command Center and to a Cloud Logging project. The following detection rules are useful for detecting the effects of using components with known vulnerabilities:
- Cryptomining. Detect cryptomining based on DNS requests or connection to known mining addresses.
- Malware. Detect malware-based DNS requests or connection to known bad addresses.
- Exfiltration to external table. Detect resources that are saved outside the organization, including copy or transfer operations.
- Outgoing DoS. Detect exploited vulnerabilities attempting denial of service attacks.
Web Security Scanner supports the following use cases:
- Outdated libraries
- Vulnerabilities and findings dashboards
Web Security Scanner monitors for outdated libraries included in your web application. You can monitor these findings in the Security Command Center dashboard.
A07: Identification and authentication failures
Identification and authentication failures are common risks because application authentication and session management are often implemented incorrectly. Attackers can exploit implementation flaws, such as compromised passwords, keys, and session tokens, in order to temporarily or permanently assume other users' identities.
Access Transparency
Use case:
- Service provider monitoring
- Access justifications
Usually, if you wanted custom support from external vendors, you had to grant and share temporary credentials, which creates the potential for orphaned or leaked credentials. Access Approval is an integrated service that lets you approve or dismiss requests for access by Google employees working to support your account. Each access request includes an access justification so you can view the reason for each access, including references to support tickets.
Apigee
Use case:
- Key validation
- Token validation
- OAuth policies
Apigee provides VerifyApiKey, OAuth, and JSON Web Token (JWT) policies, which help protect against this risk.
API key validation is the simplest form of app-based security that can be configured for an API. A client application presents an API key with its request. Apigee Edge, through a policy attached to an API proxy, checks to see that the API key is in an approved state for the resource that is being requested.
OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or on its own behalf by allowing the third-party application to obtain access.
JSON Web Tokens or JWT, are commonly used to share claims or assertions between connected applications. Apigee provides JWT support using three policies.
Google Cloud Armor
Use case:
- Limit authentication endpoint access
- Restrict unauthorized token use
Attacks against vulnerabilities that are classified under the broken authentication risk are best mitigated on the application level or by other controls. However, Google Cloud Armor can help limit the attack surface or block known-attack vectors.
For example, if your application has a limited user base and those users come from a known set of IP addresses or countries, you can create a security policy that limits access to your application to users from those IP address blocks or countries. This policy can help mitigate against automated scanning from endpoints outside of these areas.
If other security mechanisms detect that passwords, keys, or session tokens
have been compromised, you can block access for requests that contain those
parameters in a query string by using a
custom rule.
You can update rules that you previously defined by using the
securityPolicy.patchRule
method. You might be able to identify potential stolen tokens by using anomaly
detection mechanisms over
HTTP load balancing logs.
You can also detect potential adversaries by scanning for common passwords in
those logs.
You can block common session fixation attacks by using the
preconfigured ModSecurity rule set for session fixation.
You can use the rule set by adding the predefined
evaluatePreconfiguredExpr('sessionfixation-stable')
rule to your security
policy.
If your application includes password changes in the query string, you can also
block the use of common passwords by using a
custom rule
that matches the request.query
attribute. However, such checks are much better
implemented on the application side if possible.
Identity-Aware Proxy (IAP)
Use case:
- Centralized access control
- Works with cloud and on-premises
- Protect HTTP and TCP connections
- Context-Aware Access
IAP integrates with HTTP(S) load balancing so you can use identity and context to form a secure authentication and authorization wall around your application. Prevent broken authentication to your public-facing application by provisioning external users in Identity Platform (more information in the following section).
You can also prevent broken authentication to administrative interfaces by protecting them with Identity-Aware Proxy and authenticating users provisioned with Identity and Access Management or Cloud Identity. Any attempt to access the tool results in a logged authentication attempt followed by an authorization check to ensure the authenticated user is allowed to access the requested resource.
Identity Platform
Use case:
- Authentication as a service
- Multi-factor authentication
- Enterprise SLA
- Broad protocol support
- Google Account protection intelligence
Identity Platform is the CIAM platform for Google Cloud customers. Identity Platform helps provide secure authentication as a service with multi-protocol support by using SDKs and APIs. It offers multi-factor authentication, integration with third-party authentication services, and auditable activity tracking.
reCAPTCHA
Use case:
- Automated login attempts
- Content scraping
- Credential stuffing
- Fraudulent transactions
- Account takeovers
- Fake accounts
- Money laundering
reCAPTCHA provides highly effective filtering against bots and other forms of automation and bulk traffic by scoring the risk level of access attempts. You can tune your site-specific model with automated feedback. reCAPTCHA adapts future scores to fit your site.
Security Command Center
Security Command Center includes three services that help you address identification and authentication failures: Event Threat Detection, Security Health Analytics, and Web Security Scanner.
Event Threat Detection supports the following use cases:
- Brute force detection
- IAM abuse detection
Event Threat Detection monitors your Cloud Logging stream and applies detection logic and proprietary threat intelligence at a granular level. When Event Threat Detection detects a threat, it writes a finding to Security Command Center and to Cloud Logging in the project of your choosing. The following event types are useful for identifying broken authentication:
- Brute force SSH. Detect successful brute force of SSH on a host.
- Anomalous grant. Detect privileges granted to Identity and Access Management (IAM) users outside of your Google Cloud organization.
Security Health Analytics supports the following use cases:
- MFA/2FA enforcement
- API key protection
- API key rotation enforcement
Security Command Center helps prevent broken authentication by monitoring for multi-factor authentication compliance and the health of your API keys. You can identify suspicious requests and block them or flag them for special handling.
Web Security Scanner supports the following use case:
- Session identifier leaks
Web Security Scanner scans your web applications for vulnerabilities like session ID leaks, which let other parties impersonate or uniquely identify a user.
Titan Security Keys
Use case:
- Phishing-resistant 2FA
- Mobile and PC authentication
Titan Security Keys use public key cryptography to verify a user's identity and the URL of the login page to help ensure that attackers can't access your account even if you are tricked into providing your username and password.
A08: Software and data integrity failures
Software and data integrity failures can happen when integrity checks don't occur during software updates, processing confidential data, or any process in the CI/CD pipeline.
Artifact Registry
Use case:
- Centralize artifacts in a single, trusted location
- Use version management, vulnerability scanning, approval workflows
Artifact Registry is a single place for your organization to manage container images and language packages (such as Maven and npm). It can integrate with your existing development tools and provides vulnerability scanning for your containers using Artifact Analysis.
Binary Authorization
Use case:
- Ensure only trusted containers are deployed
Binary Authorization verifies the integrity of containers so that only trusted container images are deployed. You can create policies to allow or deny deployment based on the presence or absence of attestations. Binary Authorization applies policies at a cluster level, so you can configure different policies for different environments. This distinction allows for progressive attestation requirements as environments get closer to production.
Cloud Asset Inventory
Use case:
Search service
Access analyzer
One of the most common vectors for data exposure is orphaned or unauthorized IT infrastructure. You can identify servers that nobody is maintaining and buckets with over-broad sharing rules by analyzing the cloud asset time series data.
Set up real-time notifications to alert you to unexpected provisioning of resources which might be improperly secured or unauthorized.
Cloud Build
Use case:
Review code changes
Run tests
Standardize build deployments
Cloud Build lets you create a build config to provide instructions on your build deployment, including running static analysis and integration tests.
Google Cloud Armor
Use case:
- Block remote code execution
Because most attacks against software and data integrity are application specific, there are only a few ways to help mitigate these attacks—for example, using a web application firewall (WAF) like Google Cloud Armor. OWASP recommends that you don't accept serialized objects from untrusted sources. If possible, you can restrict endpoints accepting those objects to a set of trusted IP addresses with a deny rule similar to the following:
request.path.contains("/endpoint") && !(inIpRange(origin.ip, '1.2.3.4/32')
Replace the following:
/endpoint
: the path of the endpoint accepting serialized objects1.2.3.4/32
: the IP address range that should keep access to the interface.
To mitigate typical attacks against software and data integrity that use remote
code execution (RCE), use the predefined rule set against RCE attacks. You can
use the evaluatePreconfiguredExpr('rce-stable')
rule to block common RCE
attacks against UNIX and Windows Shells.
The RCE attacks described in the Juice Shop challenges for insecure deserializations run functions and regular expressions in Node.js on the server. These kinds of attacks are not blocked by the predefined RCE rule set and the corresponding OWASP Modsecurity rule and have to be mitigated by using patches on the server side or custom rules.
VirusTotal
Use case:
- Untrusted data scanning
The VirusTotal API lets you upload and scan files for malware. You can scan images, documents, binaries, and other untrusted data before it is processed to eliminate certain categories of malicious input.
Security Command Center
The Web Security Scanner service in Security Command Center supports the following use case:
- Insecure deserialization
Web Security Scanner
scans your web applications for vulnerabilities. For
example, if you're using an Apache Struts
version that makes your application vulnerable to remote command injection attacks,
Web Security Scanner generates a
STRUTS_INSECURE_DESERIALIZATION
finding.
A09: Security logging and monitoring failures
If you don't adequately log, monitor, or manage incidents in your systems, attackers can perform deeper and more prolonged attacks on data and software.
Access Transparency
Use case:
- Service provider access monitoring and auditing
- Access justifications
- Resource and method identification
Inability to audit cloud provider access can be a barrier to migrate from on-premises to cloud. Access Transparency enables verification of cloud provider access, bringing your audit controls closer to on-premises conditions. You can record the reason for each access, including references to relevant support tickets. Resource and method identification names which resources are accessed and which methods were run by which administrator. Access Approval lets you approve or dismiss requests for access by Google employees who are working to support your service.
Apigee
Use case:
- Export Apigee logs to SIEM
- Use Apigee monitoring UI
- Follow monitoring best practices
Apigee has several ways to perform logging, monitoring, error handling, and audit logging:
- Logging
- Log messages can be sent to Splunk or other syslog endpoints using the MessageLogging policy.
- API analytics data can be pulled through the analytics API and imported or exported into other systems.
- In Edge for Private Cloud, you can use the MessageLogging policy to write to local log files. Log files from each of the running components are available as well.
- The JavaScript policy can be used to send log messages to a REST logging endpoint synchronously or asynchronously.
- Monitoring
- Use the API Monitoring UI or API to regularly monitor APIs and backends and trigger alerts.
- Use health monitoring to regularly monitor target server backends.
- Apigee provides recommendations for monitoring Edge for Private Cloud.
- Apigee also provides best practices that your team can use for monitoring your API program.
- Error handling
- Apigee offers a powerful, versatile fault handling mechanism for API proxies. Similar to how a Java program would catch exceptions, API proxies can catch faults and determine how to return appropriate responses to clients.
- Apigee's custom fault handling lets you add functionality such as message logging whenever an error occurs.
- Audit logs
- The Apigee platform keeps an audit log that tracks changes to API proxies, products, and organization history.
- This log is available through the UI or through the Management API.
Google Security Operations
Use case:
- Threat detection
- Early warning
Security teams can send their security telemetry to Google Security Operations to let you apply powerful detection rules to a unified set of data.
Sensitive Data Protection
Use case:
- Automatic sensitive data masking
Identify compliance-sensitive information in your log streams and mask or transform it appropriately before archiving it in logs. For example, an error message or core dump might contain sensitive information such as credit card numbers or personally identifiable information that needs to be masked.
Cloud Key Management Service
Use case:
- Cryptographic key request event logging
- Access justifications
Key Access Justifications give you historical visibility into every request for an encryption key by logging the stated justification and a record of approval or denial of that request.
Cloud Logging
Use case:
- Log aggregation
- Log storage
- Log search
- Log analysis
Cloud Logging lets you store, search, analyze, monitor, and alert on logging data and events from Google Cloud and Amazon Web Services. It includes access to the BindPlane service, which you can use to collect logging data from over 150 common application components, on-premises systems, and hybrid cloud systems.
Cloud Monitoring
Use case:
- Log monitoring
- Event alerting
Cloud Monitoring provides visibility into the performance, uptime, and overall health of cloud-powered applications. It provides a monitoring dashboard, event monitors, and alerting through multiple channels.
Cloud Source Repositories
Use case:
- Code change attribution
- Access audit logging
Get insights into what actions were performed on your repository, including where and when, with Cloud Audit Logs generated by Cloud Source Repositories.
Error Reporting
Use case:
- Capture internal application errors in Cloud Logging
- Collect crash reports outside of the crashed compute instance
Internal application errors can be an indicator of a security problem, broken functionality, or attempts to circumvent security. Error Reporting counts, analyzes, and aggregates the crashes in your running cloud services. A centralized error management interface displays the results with sorting and filtering capabilities. A dedicated view shows the error details—for example, time chart, occurrences, affected user count, first- and last-seen dates, and a cleaned exception stack trace. Opt-in to receive email and mobile alerts on new errors.
Google Cloud Armor
Use case:
- Security policy logging
- Monitoring dashboards
- Alerting on traffic anomalies
Google Cloud Armor request logs are part of Cloud Logging for external Application Load Balancers To have access to logging information—such as which security policy rule matched traffic—enable logging on all backend services that have attached security policies. Use rules in preview mode to test them and log results without enforcing the effects.
Google Cloud Armor also offers monitoring dashboards for security policies that let you get an overview of the amount of traffic that passed or was denied by any of your security policies. Google Cloud Armor publishes findings about traffic anomalies, such as spikes in allowed traffic or increased denied traffic, in Security Command Center.
Google Cloud Armor automatically writes Admin Activity audit logs, which record operations that modify the configuration or metadata of a resource. This service can also be configured to write Data Access audit logs which contain API calls that read the configuration or metadata of resources, as well as user-driven API calls that create, modify, or read user-provided resource data.
Identity Platform
Use case:
- Admin Activity audit logs
- Data access audit logs
- System event audit logs
- Policy denied audit logs
- Authentication activity logs
Identity Platform is the CIAM platform for Google Cloud that logs authentication activity by default.
Enable several powerful audit logs including administrator activity, data access, system events, and denied authentication attempts.
Security Command Center
Use cases:
- Alert monitoring
- Threat management
- Vulnerability scan reporting
- Compliance monitoring
- Asset monitoring
- Security scan findings
With the compliance dashboard, you can continuously monitor compliance with controls from PCI-DSS, CIS Google Cloud Computing Foundations Benchmark, and more. The Assets page provides a detailed display of all Google Cloud resources, called assets, in your organization. The page lets you view assets for your entire organization or you can filter assets within a specific project, by asset type, or by change type. Finally, you can review a detailed findings inventory for all your organization assets so you can view potential security risks.
In addition, the Event Threat Detection service of Security Command Center supports the following use cases:
- Brute force
- Cryptomining
- IAM abuse
- Malware
- Phishing
Event Threat Detection monitors your Cloud Logging stream and applies detection logic and proprietary threat intelligence at a granular level. Event Threat Detection identifies notable entries in your logs and elevates them for review. When Event Threat Detection detects a threat, it writes a finding to Security Command Center and to a Cloud Logging project.
A10: Server-Side Request Forgery (SSRF)
An SSRF attack occurs when an attacker forces a vulnerable server to trigger unwanted malicious requests to third-party servers or internal resources. SSRF flaws can occur when a web application fetches a remote resource without validating the user-supplied URL.
Apigee
Use case:
- Block SSRF attacks by using LFI or RFI
Apigee has built-in XML and JSON parsers that use XPath or JSONPath to extract data. It has an XMLThreatProtection policy to guard against malicious XML payloads and a JSONThreatProtection policy to help protect against malicious JSON payloads.
The Apigee ExtractVariables policy lets you extract the content from a request or response and assign that content to a variable. You can extract any part of the message, including headers, URI paths, JSON and XML payloads, form parameters, and query parameters. The policy works by applying a text pattern to the message content and when it finds a match, sets a variable with the specified message content.
Google Cloud Armor
Use case:
- Filter SSRF attacks by using LFI or RFI
Because SSRF attacks can be complex and come in different forms, the mitigation possibilities by web application firewalls are limited. Attacks are better mitigated by patching XML or JSON parsers, disallowing external entities, and limiting XML or JSON data transfers on public web servers to a minimum. However, depending on the application and type of attack, Google Cloud Armor can still help defend against data exfiltration and other impacts.
Although no rules in the
OWASP ModeSecurity Core Rule Set
specifically defend against SSRF attacks, the
local file inclusion (LFI) and remote file inclusion (RFI) rules
can help against some of these attacks. To stop an attacker from retrieving local files on the server, you use the evaluatePreconfiguredExpr('lfi-stable')
rule
in a Google Cloud Armor Security policy.
The SSRF Juice Shop challenge uses the preconfigured remote file inclusion (RFI) or local file inclusion (LFI) rule sets to help mitigate some of these attacks because they block inclusion of URLs or path traversal. For example, the following rule enables both rule sets:
evaluatePreconfiguredExpr('lfi-stable') ||
evaluatePreconfiguredExpr('rfi-stable')
When such a rule is implemented, the solution for the SSRF challenge also stops working.
VPC Service Controls
Use case:
- Network perimeters to segment servers
To reduce the impact of SSRF attacks, you can use VPC Service Controls to create perimeters that segment servers from other resources in your organization. These perimeters provide protection against data exfiltration. When run in enforced mode, API requests to restricted services don't cross the perimeter boundary unless the conditions of the necessary ingress and egress rules of the perimeter are satisfied.
Virtual Private Cloud (VPC) firewall
Use case:
- Enforce "deny by default" firewall policies or network access control rules to block all but essential intranet traffic.
VPC firewalls apply to inbound and outbound traffic for your projects and VPC network. You can create firewall rules that block all traffic except the traffic that you want to allow. For more information, see the VPC firewall rules overview.
Security Command Center
The Web Security Scanner service in Security Command Center supports the following use case:
- Web application monitoring
Web Security Scanner
scans your web applications for vulnerabilities. For
example, if your application is vulnerable to server-side request forgery,
Web Security Scanner generates a
SERVER_SIDE_REQUEST_FORGERY
finding.
What's next
- Web application and API protection on Google Cloud
- OWASP Top 10
- Google Cloud security bulletins
- Google Cloud security best practices center
- Compliance offerings
- CIS benchmark for Google Cloud
- Security Command Center
- Apigee
- Google Cloud Armor
- All Google Cloud security products
- Explore reference architectures, diagrams, and best practices about Google Cloud. Take a look at our Cloud Architecture Center.