Guidelines for setting up a third-party CASB with Google Workspace

If possible, don't use an inline/active CASB on network traffic between users and Google (don’t use a proxy or network filter). Consider other ways to meet your goals—for example, APIs or Gmail add-ons such as an offline CASB. The Google Support team can't provide assistance with troubleshooting and resolution of potential Google Workspace issues involving inline/active CASB solutions.

Instead, we recommend the following options offered by Google Workspace:

• Reports API
• Add-ons
• Data loss prevention (DLP)
• Security investigation tool
• API controls

If you must use a CASB, make sure you can test your configuration by bypassing or disabling the CASB for a specific machine or user. This is important because CASB providers/configurations often cause connection issues to Google services (rather than Google having a problem).

Here are some common options for testing whether an issue with Google Workspace is caused by a CASB:

• (Recommended) Use a different machine to connect, where network traffic isn't routed through the CASB, and isn't under any corporate policies that require installation of local network filters or browser extensions. For example, access the Google service from a personal device, or connect the affected machine to a mobile network (tethering) instead of the corporate network.
• Set up your CASB to passthrough traffic from the affected machine. This option is often more difficult to set up.
• If your organizational policies don't allow connecting to your Google Workspace account directly, use a separate Google Workspace test environment.

If you must block Google traffic, you should not modify the payload/response body—for example, by injecting your own Javascript code. Instead, make sure your CASB/proxy replaces the response with a 500 response. Ideally, the 500 response should have a unique header to indicate that it came from the CASB. If you do modify response bodies, Google is not able to guarantee support for any resulting issues.

Google can't guarantee any assistance with issues related to blocking or modifying network traffic between the browser (or API client) and Google, or issues that occur as a side effect of such changes. Google provides APIs for integrations, but we can't support integrations created by other means (for example, code/CSS injection). This is because Google doesn’t have visibility into the configuration or code in third-party systems, and can’t provide any guarantees about non-public interfaces.

The Google Workspace Support team also can't assist with debugging third-party code, especially if the code doesn't use official Google APIs or interfaces. For example, you can use a Gmail add-on to add a button to the Gmail UI, and that's supported. However, adding a button to the Gmail UI by injecting your own Javascript—either with a Chrome extension or a man-in-the-middle (MITM) proxy—isn't supported.

Listed below are some possible side effects and symptoms of network issues related to CASB/network filters. This isn't a comprehensive list of issues, so there might be other symptoms as well:

• The user interface is not loading, or it’s blank.
• Users are redirected to a Google support page with instructions for how to clear the cache, and this redirect persists even after clearing the cache.
• The application is loading, but some functionality is disabled—for example, users are unable to compose an email, or Docs/Sheets/Slides editor options are disabled or grayed out.
• Errors are occurring across multiple unrelated Google Workspace products (for example, Gmail and Drive) despite no outage reported on the Google Workspace Status Dashboard.

• Compare HTTPS certificate fingerprints with the real Google certs. For example, use the SSL Server Test to compare the fingerprint of the cert you're seeing in the browser with the fingerprint shown for the same hostname (for example, docs.google.com). 
• If the certificates are different, this indicates an inline/active CASB. Try to reproduce the issue on a direct connection to Google—for example, on a separate machine connected via a mobile network as mentioned above—and make sure there are no locally-running agents that intercept network traffic.
• If the certificates are the same, it likely indicates there's no inline CASB. Try to reproduce the issue in Chrome incognito mode, while making sure no Chrome extensions are allowed in incognito mode. This eliminates issues related to locally-running agents installed as Chrome extensions.

If you’re experiencing CASB/network issues, and if you verify that your network traffic is being modified by a CASB/proxy as described in the sections above, do the following:

• Talk to your network administrator.
• Check to see if the issue happens on an unrelated machine or accounts (see the section above: Make sure you can disable the CASB for testing). Google can't guarantee connections that are interrupted or modified—or pages that are modified by extension—will work as expected. Please contact your CASB provider.
• If you still believe this issue is on the Google side, collect the following information and provide it to the Google Support team:
  • Details that you learned related to the above sections: Identify issues related to CASB/network filters and Verify if your network traffic/browsing session is being modified by the CASB/proxy
  • Any other symptoms or unexpected issues seen on Google sites or non-Google sites
  • Any other patterns that you’ve noticed (for example, with specific users, user groups, geographical regions, network topology groupings, or specific pages)
  • A HAR capture from incognito mode, with all extensions disabled, while reproducing the issue (see How to get a HAR capture)
  • Screenshots or video demonstrating any errors encountered