Your users aren’t downloading files to their desktops anymore. They’re not running local applications. They’re working in Google Docs, Salesforce, Slack, and dozens of other browser-based platforms. The endpoint—the place where work actually happens—has moved entirely into the browser.

Your security tools haven’t made that move with them.

Legacy vendors built traditional Secure Web Gateways and Endpoint Detection and Response solutions for a different era. These tools monitor network traffic and inspect files on disk, but they can’t see what’s happening inside the browser itself. To these tools, the browser is essentially a black box. They can see requests going in and responses coming out, but the context of what the user is doing, what the browser renders, and how the browser reassembles malicious code? That’s invisible.

How Attackers Exploit the Visibility Gap

Attackers have figured this out, and they’re exploiting it systematically:

• Evasive assembly attacks bypass SWGs entirely by delivering malicious components as seemingly innocent web resources—CSS files, SVG images, JavaScript variables—and assembling them into a malicious payload inside the browser. The network traffic looks clean because no single request contains anything dangerous. The threat only materializes on the client side.
• Web Assembly files present a particular challenge. These binary files execute intensive tasks directly in the browser and never touch the disk. Attackers hide malicious payloads inside WASM variables, which then trigger downloads that appear completely normal to network-based security tools.
• Steganography embeds malicious files inside images. The image passes through your security stack without raising flags. Once it’s in the browser, client-side JavaScript extracts the hidden file and triggers a download.
• File chunking defeats Data Loss Prevention systems by breaking sensitive files into small pieces that don’t individually look like data worth protecting. Each chunk uploads separately, looking innocuous. The file reassembles on the server side, and your DLP solution never saw it leave.
• OAuth consent attacks are surging. An attacker sends an email with a legitimate link to a real application—say, Salesforce. The domain is valid, so email security doesn’t flag it. The user clicks and unknowingly grants the attacker broad access to their data. The entire attack happens through legitimate OAuth flows that bypass traditional controls.

Recent attacks have used seemingly trivial files like malicious RDP configurations. When opened, these files mount all of the victim’s local drives onto the attacker’s device for exfiltration. The file itself looks harmless in transit.

What Browser Detection and Response Actually Does

SquareX explained the concept of Browser Detection and Response during the recent Security Field Day, positioning it as the security layer that finally operates where the threats materialize.

BDR functions like EDR, but for the browser. It monitors activity, enforces policies, and detects threats inside the browser environment itself—where identity attacks, malicious extensions, phishing, and evasive file delivery occur.

The architecture consists of a browser extension deployed via MDM and a web platform for policy management. The extension runs on Chromium-based browsers, Safari, and Firefox, acting as the enforcement point with full visibility into what’s happening in the browser context.

Last-Mile and First-Mile Control

SquareX provides control at the exact moments that matter most:

• Last-mile control for downloads means the extension stops malicious files at the instant they’re triggered in the browser—regardless of how they were delivered. If a file was assembled via Web Assembly or extracted from an image via steganography, it doesn’t matter. The extension sees the final download attempt and can block it. It also offers Content Disarm and Reconstruction capabilities, stripping macros from Office documents directly in the client before the file reaches the disk.
• First-mile control for uploads prevents data loss before the file leaves the browser. Even if an attacker uses chunking or other evasion techniques, the extension can block the upload before the website receives any pieces.

Policies That Adapt to Novel Threats

One of SquareX’s technical differentiators is its use of Lua scripting running entirely client-side within the browser extension. This enables security teams to create complex, custom policies that respond to novel threats without waiting for cloud updates or vendor releases.

Security teams can build policies using a standard interface, generate them with an AI-based tool that accepts plain-language descriptions, or write custom Lua scripts for specific threats. This flexibility allows rapid response to emerging attack techniques—like blocking RDP files that contain specific commands used for drive redirection.

Attack Graphs Reveal the Full Context

When a suspicious event occurs, SquareX generates an Attack Graph that maps the user’s complete path to the malicious page. This goes beyond showing just the source URL. It details whether the user clicked a search result, followed a link from Outlook, or arrived through a redirect chain.

This visibility fills a critical gap that EDRs currently leave open. Understanding how a user ended up at a malicious page helps security teams identify the initial vector and assess whether other users might be at similar risk.

The platform also provides visibility and control over browser extensions and enables granular policies for OAuth permissions—blocking users from granting risky access to applications.

For high-risk user groups, Attack Vision can be selectively enabled. This feature captures lightweight DOM changes (not video) to reconstruct what the user saw during an attack, helping security teams understand why a particular phishing attempt or social engineering tactic succeeded.

Why Not an Enterprise Browser?

SquareX deliberately chose an extension-based approach over building an enterprise browser. Enterprise browsers face adoption challenges—asking employees to switch browsers meets resistance. They also create reliability concerns, acting as a single point of failure, and they inherit security patching delays because they depend on upstream Chromium updates.

The extension approach is lightweight and doesn’t disrupt the user experience. It requires MDM deployment with administrative permissions but leverages the native security controls and performance optimizations already built into major browsers. Background service workers and offscreen workers handle intensive tasks like OCR without impacting user performance.

BDR: The Security Layer You’re Missing

The browser has become the primary workspace for modern organizations. Network-based SWGs can’t see what’s being assembled inside it. Endpoint-based EDRs can’t inspect what never touches the disk. The visibility gap is real, and attackers are actively exploiting it.

Browser Detection and Response provides the security layer that operates precisely where these threats materialize. It offers last-mile control against file-based malware hidden in web resources, first-mile control for data loss prevention, and Attack Graph visibility that transforms incident response.

The endpoint moved. Your security needs to move with it.