Overview of Cloud Security Scanner

This page introduces Cloud Security Scanner.

Introduction

Cloud Security Scanner identifies security vulnerabilities in your App Engine 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. The scanner currently detects the following:

  • XSS
  • Flash injection
  • Mixed-content
  • Clear text passwords
  • Usage of insecure JavaScript libraries

Cloud Security Scanner currently supports the App Engine standard environment and Compute Engine instances only. It is not yet enabled for App Engine flexible environment, or other Google Cloud Platform (GCP) resources.

The Cloud Security Scanner is designed to complement your existing secure design and development processes. To avoid distracting you with false positives, the Cloud Security Scanner errs on the side of under reporting and will not 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 GCP Security

Usage Caveats

Some important things to be aware of when using Cloud Security Scanner:

  • Because the Cloud Security Scanner is undergoing continual improvements, a future scan may report issues that are not reported by the current scan.
  • Some features or sections of your application might not be tested.
  • The Cloud Security Scanner attempts to activate every control and input it finds.
  • If you expose state-changing actions for which your test account has permission, the Cloud Security Scanner is likely to activate them. This may lead to undesirable results.

Who can run a security scan?

See Access Control for details on Cloud Identity and Access Management (Cloud IAM) roles for Cloud Security Scanner.

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 may take several hours to complete.

Target restrictions

The Cloud 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 Cloud Security Scanner automatically attempts to avoid logout URLs and other generic locations that may adversely affect a scan. However, to be sure, you can manually exclude URLs via the scan settings.

Preventing unintended consequences

Because the Cloud Security Scanner populates fields, pushes buttons, clicks links, and so on, it should be used with caution. Cloud 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, Cloud Security Scanner may post test strings as comments on all your blog articles.
  • In an email sign-up page, Cloud Security Scanner may generate large numbers of test emails.

Here are some techniques which can be used, 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 uploading your app.
  2. Use a test account. Create a user account that does not 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, creating a profile, and so on. Because of the different workflow, a test account for an initial user can yield 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 complet.
  3. Block individual UI elements that you do not want activated by applying the CSS class inq-no-click. Event handlers attached to this element are not 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 will not be crawled or tested. For information on syntax, see Excluding URLs.

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

If you use a test account

Many applications present a special workflow during a user's first-time login, such as accepting terms, creating a profile, and so on. If your application has a different flow for first-time users, keep this in mind when choosing a user account for your scan. Because of the different workflow, a new user account completing the first time flow can yield 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.

What's next

Was this page helpful? Let us know how we did:

Send feedback about...

Cloud Security Scanner Documentation