Browser Security

Twingate’s Browser Extension restricts which browsers can access sensitive Resources and applies Enterprise application controls. Paired with a compatible Client and a managed browser, the browser extension ensures that your users are accessing Resources in a secure, managed environment.

Additionally, when using DNS filtering, the browser extension will show a DNS filtering block page on HTTPS sites.

By configuring Data Loss Prevention Policies in the Admin Console, you can specify which Resources must be accessed from a managed browser. Furthermore, you can prevent users from taking certain actions (copy, paste, download, upload, and print) when viewing a Resource in the browser.

Use cases

App gating

Limited to the Enterprise tier.

As part of Twingate’s application gating, Twingate lets admins restrict access to SaaS apps and private services to devices that are running Twingate. App gating allows admins to ensure that devices accessing SaaS apps meet Twingate’s device posture checks, ensuring that devices fulfill security requirements.

The Twingate Browser Extension allows admins to take app gating one step further and lock down which browser employees use to access Resources. If your team is using a managed browser to ensure that users are browsing securely, Twingate lets you ensure that only your secure browser is used for Resource access. This is particularly important if you have company-managed browser extensions to enforce security requirements or healthy browsing hygiene.

Enterprise application controls

Limited to the Enterprise tier.

You can also use Twingate’s browser extension to restrict what actions can be taken on a sensitive SaaS app. Users might inadvertently copy or download sensitive information, so the browser extension allows you to block actions like copying or downloading completely for a Resource. These controls nudge users to act in a more security-minded way and help keep your information safe inside of a SaaS app or internal tool.

DNS filtering

Twingate’s browser extension augments your employees experience when using DNS filtering. The browser extension will show a DNS filtering block page whenever users visit a blocked site, no matter whether that site uses HTTP or HTTPS. By leveraging a browser extension, Twingate doesn’t need to intercept SSL and TLS connections leaving your employees’ devices.

Read the configuration guide to learn how to get started with all of these use cases.

How the browser extension works

When a Resource has a Data Loss Prevention Policy, the Client and the browser extension will apply new restrictions to that Resource:

• Traffic destined for that Resource will be routed through Twingate if and only if that traffic originates from a browser running the browser extension. Other traffic will be routed outside of Twingate.
• The browser extension will apply Enterprice application controls to the Resource when it’s being viewed in the browser running the extension.

The browser extension uses the Twingate Client for authentication and for communication with Twingate’s servers. This means that the browser extension requires a compatible Twingate Client to function properly.

DNS filtering block page

The browser extension will show the block page on any domains blocked by DNS filtering, including sites that use HTTPS. Data Loss Prevention Policies are not required for the DNS filtering block page to work.

Analytics

Twingate records actions blocked by the browser extension and reports them in analytics. This includes, for example, when a copy action is blocked by the extension or when the extension blocks a user from downloading a file.

Currently, the information recorded about the event includes when the event happened, what action was blocked, and the domain the action was performed on.

Analytics may be exported via syncing data to AWS S3.

Configuration

The following sections cover the basic steps for deploying the browser extension and configuring it for two common use cases: controlling Resource access and showing a DNS filtering block page. No matter your use case, you must install a compatible Client and distribute the browser extensions to your users’ browsers. To configure the extension for the most common use cases, read the following sections:

• To restrict and control Resource access, follow the guide to configuring Data Loss Prevention Policies.
• To show the DNS filtering block page, follow the guide to show the DNS filtering block page.

Compatible Clients

The browser extension requires a compatible Client. Currently, the only supported Client is the standalone macOS client, versions 2024.238 and newer.

Distributing the browser extension

→ Install the extension from the Chrome Web Store

For one-off deployments, you can install the browser extension directly from the Chrome Web Store. To deploy the browser extension to your users, you can either use Google Workspace or MDM.

To distribute the extension via Google Workspace, follow the Google Workspace guide to automatically installing apps and extensions on Chrome. When adding an extension from the Chrome Web Store, search by ID and use the Twingate browser extension’s ID: jfkgjobgdomomdkjlndhpolcbbfbfdbp. We strongly suggest force installing and pinning the extension.

To distribute the extension without Google Workspace, you can install extensions via an MDM policy. Google Chrome Enterprise, Edge, and other Chromium browsers with management support allow admins to deploy the ExtensionInstallForceList parameter. For more information see

• Google Chrome Enterprise documentation
• Edge documentation

By default, developer tools are disabled on force installed extensions (whether that extension is installed via Google Workspace or the ExtensionInstallForceList policy), meaning that your users won’t be able to inspect or modify the contents of the Twingate browser extension. This generally prevents users from modifying how the extension behaves. If desired, you can also further lock down the browser by disabling developer tools globally. Doing so will prevent users from inspecting the source of a page and copying information from the source directly. For more information see

• Google Chrome Enterprise documentation
• Edge documentation

Configuring Data Loss Prevention Policies

Data Loss Prevention Policies are used to restrict access to a Resource to a specific browser and to apply Enterprise application controls. Data Loss Prevention Policies are configured in the Admin → Policies → Data Loss Prevention Policies section of the Admin Console.

New Data Loss Prevention Policies can be created via the Create button. Existing Data Loss Prevention Policies can be configured by clicking on them. Data Loss Prevention Policies can be configured to block actions and show a watermark. Data Loss Prevention Policies can block the following actions:

• Copy
• Paste
• Upload
• Download
• Print

Further, Data Loss Prevention Policies can be configured to show a watermark via the Content Restrictions tab.

Once configured, Data Loss Prevention policies can be added to Resources just like Resource Policies.

Once a Data Loss Prevention Policy is added to a Resource, that Resource will only route traffic through Twingate if that traffic comes from a browser running the browser extension.

When configuring Data Loss Prevention policies for the first time, it’s strongly recommended to apply them to testing Resources before enabling them more widely. Once added to a Resource, the Data Loss Prevention Policy will require the Resource to be accessed from a browser running the extension, which may break your users’ workflows if configured prematurely.

DNS filtering block page

Beyond enabling DNS filtering, no additional configuration is needed to show a DNS filtering block page using the extension. Once the extension is installed alongside a compatible Client, the DNS filtering block page will be shown when visiting a blocked site.