Overview of Web Security Scanner

Web Security Scanner identifies security vulnerabilities in your App Engine, Google Kubernetes Engine (GKE), and Compute Engine web applications. It crawls your application, following all links within the scope of your starting URLs, and attempts to exercise as many user inputs and event handlers as possible. Currently, Web Security Scanner only supports public URLs and IPs that aren't behind a firewall.

Web Security Scanner currently supports the App Engine standard environment and App Engine flexible environments, Compute Engine instances, and GKE resources.

Web Security Scanner is designed to complement your existing secure design and development processes. To avoid distracting you with false positives, Web Security Scanner errs on the side of under reporting and doesn't display low confidence alerts. It does not replace a manual security review, and it does not guarantee that your application is free from security flaws.

Scan types

Web Security Scanner provides managed and custom web vulnerability scanning for public App Engine, GKE, and Compute Engine serviced web applications.

Managed scans

Web Security Scanner managed scans are configured and managed by Security Command Center. Managed scans automatically run once each week to detect and scan public web endpoints. These scans don't use authentication and they send GET-only requests so they don't submit any forms on live websites.

Managed scans run separately from custom scans.

If Security Command Center is activated at the organization level, you can use managed scans to centrally manage basic web application vulnerability detection for projects in your organization, without having to involve individual project teams. When findings are discovered, you can work with those teams to set up more comprehensive custom scans.

When you enable Web Security Scanner as a service, managed scan findings are automatically available in the Security Command Center Vulnerabilities page and related reports. For information about how to enable Web Security Scanner managed scans, see configuring Security Command Center.

Managed scans support only applications that use the default port, which is 80 for HTTP connections and 443 for HTTPS connections. If your applcation uses a non-default port, do a custom scan instead.

Custom scans

Web Security Scanner custom scans provide granular information about application vulnerability findings, like outdated libraries, cross-site scripting, or use of mixed content.

You define custom scans at the project level.

Custom scan findings are available in Security Command Center after you complete the guide to set up Web Security Scanner custom scans.

Scan findings

This section describes Web Security Scanner finding types and relevant compliance standards.

Detectors and compliance

Web Security Scanner supports categories in the OWASP Top Ten, a document that ranks and provides remediation guidance for the top 10 most critical web application security risks, as determined by the Open Web Application Security Project (OWASP).

The compliance mapping is included for reference and is not provided or reviewed by the OWASP Foundation.

This functionality is only intended for you to monitor for compliance controls violations. The mappings are not provided for use as the basis of, or as a substitute for, the audit, certification, or report of compliance of your products or services with any regulatory or industry benchmarks or standards.

For more information about compliance, see Assess and report security benchmark compliance.

Finding types

Web Security Scanner custom and managed scans identify the following finding types. In the Standard tier, Web Security Scanner supports custom scans of deployed applications with public URLs and IPs that aren't behind a firewall.

Category Finding description OWASP 2017 Top 10 OWASP 2021 Top 10
Accessible Git repository

Category name in the API: ACCESSIBLE_GIT_REPOSITORY

A Git repository is exposed publicly. To resolve this finding, remove unintentional public access to the GIT repository.

Pricing tier: Standard

Fix this finding

A5 A01
Accessible SVN repository

Category name in the API: ACCESSIBLE_SVN_REPOSITORY

An SVN repository is exposed publicly. To resolve this finding, remove public unintentional access to the SVN repository.

Pricing tier: Standard

Fix this finding

A5 A01
Cacheable password input

Category name in the API: CACHEABLE_PASSWORD_INPUT

Passwords entered on the web application can be cached in a regular browser cache instead of a secure password storage.

Pricing tier: Premium

Fix this finding

A3 A04
Clear text password

Category name in the API: CLEAR_TEXT_PASSWORD

Passwords are being transmitted in clear text and can be intercepted. To resolve this finding, encrypt the password transmitted over the network.

Pricing tier: Standard

Fix this finding

A3 A02
Insecure allow origin ends with validation

Category name in the API: INSECURE_ALLOW_ORIGIN_ENDS_WITH_VALIDATION

A cross-site HTTP or HTTPS endpoint validates only a suffix of the Origin request header before reflecting it inside the Access-Control-Allow-Origin response header. To resolve this finding, validate that the expected root domain is part of the Origin header value before reflecting it in the Access-Control-Allow-Origin response header. For subdomain wildcards, prepend the dot to the root domain—for example, .endsWith(".google.com").

Pricing tier: Premium

Fix this finding

A5 A01
Insecure allow origin starts with validation

Category name in the API: INSECURE_ALLOW_ORIGIN_STARTS_WITH_VALIDATION

A cross-site HTTP or HTTPS endpoint validates only a prefix of the Origin request header before reflecting it inside the Access-Control-Allow-Origin response header. To resolve this finding, validate that the expected domain fully matches the Origin header value before reflecting it in the Access-Control-Allow-Origin response header—for example, .equals(".google.com").

Pricing tier: Premium

Fix this finding

A5 A01
Invalid content type

Category name in the API: INVALID_CONTENT_TYPE

A resource was loaded that doesn't match the response's Content-Type HTTP header. To resolve this finding, set X-Content-Type-Options HTTP header with the correct value.

Pricing tier: Standard

Fix this finding

A6 A05
Invalid header

Category name in the API: INVALID_HEADER

A security header has a syntax error and is ignored by browsers. To resolve this finding, set HTTP security headers correctly.

Pricing tier: Standard

Fix this finding

A6 A05
Mismatching security header values

Category name in the API: MISMATCHING_SECURITY_HEADER_VALUES

A security header has duplicated, mismatching values, which result in undefined behavior. To resolve this finding, set HTTP security headers correctly.

Pricing tier: Standard

Fix this finding

A6 A05
Misspelled security header name

Category name in the API: MISSPELLED_SECURITY_HEADER_NAME

A security header is misspelled and is ignored. To resolve this finding, set HTTP security headers correctly.

Pricing tier: Standard

Fix this finding

A6 A05
Mixed content

Category name in the API: MIXED_CONTENT

Resources are being served over HTTP on an HTTPS page. To resolve this finding, make sure that all resources are served over HTTPS.

Pricing tier: Standard

Fix this finding

A6 A05
Outdated library

Category name in the API: OUTDATED_LIBRARY

A library was detected that has known vulnerabilities. To resolve this finding, upgrade libraries to a newer version.

Pricing tier: Standard

Fix this finding

A9 A06
Server side request forgery

Category name in the API: SERVER_SIDE_REQUEST_FORGERY

A server-side request forgery (SSRF) vulnerability was detected. To resolve this finding, use an allowlist to limit the domains and IP addresses that the web application can make requests to.

Pricing tier: Standard

Fix this finding

Not applicable A10
Session ID leak

Category name in the API: SESSION_ID_LEAK

When making a cross-domain request, the web application includes the user's session identifier in its Referer request header. This vulnerability gives the receiving domain access to the session identifier, which can be used to impersonate or uniquely identify the user.

Pricing tier: Premium

Fix this finding

A2 A07
SQL injection

Category name in the API: SQL_INJECTION

A potential SQL injection vulnerability was detected. To resolve this finding, use parameterized queries to prevent user inputs from influencing the structure of the SQL query.

Pricing tier: Premium

Fix this finding

A1 A03
Struts insecure deserialization

Category name in the API: STRUTS_INSECURE_DESERIALIZATION

The use of a vulnerable version of Apache Struts was detected. To resolve this finding, upgrade Apache Struts to the latest version.

Pricing tier: Premium

Fix this finding

A8 A08
XSS

Category name in the API: XSS

A field in this web application is vulnerable to a cross-site scripting (XSS) attack. To resolve this finding, validate and escape untrusted user-supplied data.

Pricing tier: Standard

Fix this finding

A7 A03
XSS angular callback

Category name in the API: XSS_ANGULAR_CALLBACK

A user-provided string isn't escaped and AngularJS can interpolate it. To resolve this finding, validate and escape untrusted user-supplied data handled by Angular framework.

Pricing tier: Standard

Fix this finding

A7 A03
XSS error

Category name in the API: XSS_ERROR

A field in this web application is vulnerable to a cross-site scripting attack. To resolve this finding, validate and escape untrusted user-supplied data.

Pricing tier: Standard

Fix this finding

A7 A03
XXE reflected file leakage

Category name in the API: XXE_REFLECTED_FILE_LEAKAGE

An XML External Entity (XXE) vulnerability was detected. This vulnerability can cause the web application to leak a file on the host. To resolve this finding, configure your XML parsers to disallow external entities.

Pricing tier: Premium

Fix this finding

A4 A05

Usage Caveats

The IAM roles for Security Command Center can be granted at the organization, folder, or project level. Your ability to view, edit, create, or update findings, assets, and security sources depends on the level for which you are granted access. To learn more about Security Command Center roles, see Access control.

Other important things to be aware of when using Web Security Scanner:

  • Because Web Security Scanner is undergoing continual improvements, a future scan might report issues that are not reported by the current scan.
  • Some features or sections of your application might not be tested.
  • Web Security Scanner attempts to activate every control and input it finds.
  • If you expose state-changing actions for which your test account has permission, Web Security Scanner is likely to activate them. This might lead to undesirable results.
  • Web Security Scanner has a limit of 15 scans per project. Because scans are run concurrently, users who reach this limit are advised to add multiple starting URLs per scan, or to add scans to different projects that have not yet reached the limit.

Who can run a security scan?

For information about the Identity and Access Management (IAM) roles that are available for Web Security Scanner, see Access Control.

How much time is required for a security scan?

The security scan does not execute immediately. It is queued and then executes later, possibly hours later depending on system load. After the scan starts to execute, the time it takes will depend on the size of your application. Large applications with many URLs might take several hours to complete.

Target restrictions

Web Security Scanner has filters in place that restrict scan targets to the specific App Engine instance for which the scan is created. Entering URLs for a different App Engine project or an outside domain will result in an error message.

Scans for Compute Engine and GKE are restricted to domains that map to static external IP addresses reserved for the same project and static external IP addresses that belong to the same project. For instructions on reserving IP addresses for projects, see the following links:

App Engine does not provide a way to map static IP addresses to an application. However, you can use Cloud Load Balancing and serverless network endpoint groups to reserve a static IP address for your load balancer, which then directs traffic to your application. For information about pricing, see External IP address pricing.

Within your project, the Web Security Scanner automatically attempts to avoid logout URLs and other generic locations that may adversely affect a scan. However, to be sure, you can use the scan settings to manually exclude URLs.

Validation

Scan configurations are validated when they are created and before each scan. Web Security Scanner checks Security Command Center settings and your application's authentication credentials to ensure scans are configured correctly and can log in to your application successfully. Configuration parameters, including maximum scan speed, are also checked to ensure they are within supported ranges.

You must resolve errors before a scan is created or updated. Applications that are changed after initial configuration may produce errors during scans. For example, if a domain no longer points to an IP address owned by the project, the resource is not scanned and an error is reported on the scan configuration page.

Best practices

Because Web Security Scanner populates fields, pushes buttons, clicks links, and performs other user actions, you should use it with caution, particularly if you are scanning production resources. Web Security Scanner could potentially activate features that change the state of your data or system, with undesirable results.

For example:

  • In a blog application that allows public comments, Web Security Scanner might post test strings as comments on all your blog articles.
  • In an email sign-up page, Web Security Scanner might generate large numbers of test emails.

Following are some techniques that you can use, separately or in combination, to avoid unwanted outcomes:

  1. Run scans in a test environment. Set up a test environment by creating a separate App Engine project and loading your application and data there. If you use the Google Cloud CLI, you can specify the target project as a command-line option when you upload your app.
  2. Use a test account. Create a user account that doesn't have access to sensitive data or harmful operations, and use it when scanning your app. Many applications present a special workflow during a user's first-time login, like accepting terms and creating a profile. Because of the different workflow, a test account for an initial user can have different scan results than an established user account. It's best to scan with an account that is in the normal user state, after the first-time flow is complete.
  3. Block individual user interface elements that you do not want activated by applying the CSS class inq-no-click. Event handlers that are attached to this element aren't activated during crawling and testing, regardless of whether they are inline JavaScript, or attached using addEventListener, or attached by setting the appropriate event handler property.
  4. Use backup data. Consider making a backup of your data before scanning.
  5. Excluded URLs. You can specify URL patterns that won't be crawled or tested. For information on syntax, see Excluding URLs.

Before you scan, carefully audit your application for any feature that might affect data, users, or systems beyond the desired scope of your scan.

What's next