Overview of Web Security Scanner

This page provides an overview of Web Security Scanner.

Introduction

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. For more information on web security, see the OWASP Top Ten Project.

Learn more about Google Cloud Security

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 that you define at the project 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 tab and related reports. For information about how to enable Web Security Scanner managed scans, see configuring Security Command Center.

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. Custom scan findings are available in Security Command Center after you complete the guide to set up Web Security Scanner custom scans.

Scan findings

These tables include a description of the mapping between supported detectors and the best effort mapping to relevant compliance regimes.

The CIS Google Cloud Foundation 1.0 mappings have been reviewed and certified by the Center for Internet Security for alignment for the CIS Google Cloud Computing Foundations Benchmark v1.0.0. Additional compliance mappings are included for reference and are not provided or reviewed by the Payment Card Industry Data Security Standard or the OWASP Foundation. You should refer to CIS Google Cloud Computing Foundations Benchmark v1.0.0 (CIS Google Cloud Foundation 1.0), Payment Card Industry Data Security Standard 3.2.1 (PCI-DSS v3.2.1), OWASP Top Ten, National Institute of Standards and Technology 800-53 (NIST 800-53), and International Organization for Standardization 27001 (ISO 27001) for how to check for these violations manually.

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.

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

Table 18.Web Security Scanner findings
Category Finding description CIS GCP Foundation 1.0 PCI-DSS v3.2.1 OWASP Top 10 NIST 800-53 ISO-27001
ACCESSIBLE_GIT_REPOSITORY A GIT repository is exposed publicly. To resolve this, remove unintentional public access to the GIT repository. A3
ACCESSIBLE_SVN_REPOSITORY An SVN repository is exposed publicly. To resolve this, remove public unintentional access to the SVN repository. A3
CLEAR_TEXT_PASSWORD Passwords are being transmitted in clear text and can be intercepted. To resolve this, encrypt the password transmitted over the network. A3
INVALID_CONTENT_TYPE A resource was loaded that doesn't match the response's Content-Type HTTP header. To resolve this, set `X-Content-Type-Options` HTTP header with the correct value. A6
INVALID_HEADER A security header has a syntax error and will be ignored by browsers. To resolve this, set HTTP security headers correctly. A6
MISMATCHING_SECURITY_HEADER_VALUES A security header has duplicated, mismatching values, which results in undefined behavior. To resolve this, set HTTP security headers correctly. A6
MISSPELLED_SECURITY_HEADER_NAME A security header is misspelled and will be ignored. To resolve this, set HTTP security headers correctly. A6
MIXED_CONTENT Resources are being served over HTTP on an HTTPS page. To resolve this, make sure that all resources are served over HTTPS. A6
OUTDATED_LIBRARY A library was detected that has known vulnerabilities. To resolve this, upgrade libraries to a newer version. A9
XSS A field in this web application is vulnerable to a cross-site scripting (XSS) attack. To resolve this, validate and escape untrusted user-supplied data. A7
XSS_ANGULAR_CALLBACK A user-provided string isn't escaped and can be interpolated by AngularJS. To resolve this, validate and escape untrusted user-supplied data handled by Angular framework. A7
XSS_ERROR A field in this web application is vulnerable to a cross-site scripting attack. To resolve this, validate and escape untrusted user-supplied data. A7

Usage Caveats

Some 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.

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.

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.

Best practices

Because Web Security Scanner populates fields, pushes buttons, clicks links, and performs other user actions, you should use it with caution. 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 gcloud command-line tool, 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 UI 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