Isolation: The Next Web Application Security Frontier

Isolation: The Next Web Application Security Frontier

Speakers: Artur Janc, Senior Staff Information Security Engineer, Google

Conference: LocoMocoSec

YouTube: https://www.youtube.com/watch?v=8A0N1s7FjJ4

Overview

In this insightful LocoMocoSec talk, Artur Janc, a Senior Staff Information Security Engineer at Google, delves into the critical and often overlooked realm of web application isolation. Titled "Isolation: The Next Web Application Security Frontier," the presentation unpacks a cohesive class of vulnerabilities that stem from the web's fundamental lack of robust isolation between different applications a user might have open simultaneously. Janc argues that while issues like cross-site request forgery (CSRF), clickjacking, and cross-site script inclusion (XSSI) are often treated as distinct problems, they are, at their core, manifestations of a single underlying weakness: the web's original design as a document-sharing platform, ill-equipped for the complex application ecosystem it has become.

Janc’s talk is a deep dive into the browser-level mechanisms designed to address this systemic flaw. He introduces a suite of new and emerging web platform security features that empower developers to enforce isolation at three crucial layers: resource, window, and process. The discussion highlights the urgent need for developers to adopt these opt-in mechanisms to protect users from both classic web vulnerabilities and newer, more insidious attacks like Spectre and Meltdown, which exploit shared process memory. This presentation is not merely a summary of problems but a prescriptive guide for building more secure web applications in an increasingly hostile online environment, advocating for a paradigm shift in how web security is approached.

Background

▶ Watch: The web's fundamental missing isolation problem (7:00)

The modern web, while incredibly powerful and versatile, operates on foundations never intended for the sophisticated applications it now hosts. As Artur Janc explains, the web was initially conceived as a system for hyperlinked documents, not a platform for complex, interactive applications. This fundamental mismatch has led to a critical security challenge: a pervasive lack of isolation between different web applications that a user might access concurrently. Janc posits that client-side web security fundamentally rests on three pillars: secure transport (HTTPS), protection against cross-site scripting (XSS), and robust isolation between applications. While significant progress has been made on the first two, the third—isolation—remains a largely unaddressed frontier, often manifesting as a disparate collection of vulnerabilities rather than a unified problem.

Historically, security features like encryption, client-side state management (cookies), script execution, and even the Same-Origin Policy (SOP) were retrofitted onto the web platform. This evolutionary approach left significant gaps, particularly concerning how user authentication credentials (cookies) are handled. A core issue is that browsers, by design, attach cookies to any request made to a specific domain, regardless of the requesting origin. Coupled with the inherent addressability of web resources via URLs, this creates a vast attack surface. An attacker can easily craft a request or open a window targeting a sensitive endpoint on a legitimate application, and the browser will automatically authenticate it with the user's cookies. This fundamental behavior underpins a range of seemingly distinct vulnerabilities, each with its own acronym: Cross-Site Request Forgery (CSRF), Clickjacking, Cross-Site Script Inclusion (XSSI) (also known as JSON or JavaScript hijacking), and various Cross-Site Leaks. While their exploitation patterns differ, their common root cause is the lack of robust isolation, allowing an untrusted website to leverage a user's authenticated session with another, trusted application. Addressing this requires a principled, platform-level approach to isolation, moving beyond piecemeal mitigations for individual bug classes.

Key Findings

▶ Watch: Protecting resources with Fetch Metadata Headers (17:50)

Artur Janc's talk identifies the critical need for a new generation of web security mechanisms focused on isolation, proposing that many seemingly disparate client-side vulnerabilities stem from a single, underlying problem: the web's inherent lack of robust isolation. The core finding is that to build truly secure web applications, developers must implement and adopt isolation at three distinct, yet interconnected, levels within the web platform.

First, resource-level isolation is paramount to prevent untrusted origins from loading or requesting sensitive assets (like images, scripts, or HTML) from an application. This addresses classic issues where an attacker might hotlink to or embed resources to exfiltrate information or trigger unintended actions.

Second, window-level isolation is essential to prevent malicious windows or pop-ups from tampering with or inspecting other sensitive windows. This tackles threats like tabnabbing and certain cross-site leaks, where an attacker could gain control over a legitimate window's navigation or glean information about its structure.

Finally, and perhaps most critically, the talk highlights the necessity of process-level isolation. This is a more recent and complex requirement, driven by hardware-level vulnerabilities like Spectre and Meltdown, as well as browser renderer bugs. The finding here is that if an attacker's code runs in the same operating system process as sensitive application data, it becomes incredibly difficult for the browser to enforce security boundaries. Therefore, applications must explicitly opt into mechanisms that guarantee they operate in a separate process from untrusted, cross-origin content.

Janc's presentation consolidates these varied attack vectors under the umbrella of "isolation bypasses" and presents a unified set of browser features—Fetch Metadata Request Headers, Cross-Origin Resource Policy (CORP), Cross-Origin Opener Policy (COOP), and Cross-Origin Embedder Policy (COEP)—as the principled solution. These mechanisms, when deployed in concert, provide a defense-in-depth strategy that not only mitigates known vulnerability classes but also offers protection against future, as-yet-undiscovered attack techniques, ultimately reducing the overall attack surface of web applications.

Technical Deep Dive

▶ Watch: Breaking window links with Cross-Origin Opener Policy (26:00)

The core of Janc's proposed solution lies in a set of new web platform security features designed to enforce isolation at multiple layers. These mechanisms require explicit opt-in by web developers, offering fine-grained control over how resources, windows, and processes interact across origins.

Resource-Level Isolation

To prevent untrusted websites from loading or requesting sensitive resources, Janc introduces two primary mechanisms:

1. Fetch Metadata Request Headers: These are a set of four HTTP request headers that browsers automatically attach to every HTTPS request. They provide the server with security-relevant metadata about how a request was initiated. The headers include:

• Sec-Fetch-Site: Indicates the relationship between the request initiator's origin and the requested resource's origin (e.g., same-origin, same-site, cross-site, none).
• Sec-Fetch-Mode: Describes the request's mode (e.g., navigate, no-cors, cors, websocket).
• Sec-Fetch-Dest: Specifies the destination of the request (e.g., document, image, script, iframe).
• Sec-Fetch-User: A boolean indicating if the request was initiated by a user activation.

Servers can implement robust security logic based on these headers. For example, a simple middleware could allow same-origin or same-site requests, but for cross-site requests, it might only permit navigations and block sub-resource loads. This prevents CSRF by ensuring that only trusted origins can trigger sensitive actions, and it mitigates XSSI by preventing cross-origin embedding of scripts or JSON data. Janc emphasizes that this server-side logic is powerful because it allows the server to reject a request before processing it, thus preventing information leakage or state changes. Deployment tips include using a report-only mode to detect breakage and being prepared to block "bogus" cross-site traffic that legitimate applications might not expect.

1. Cross-Origin Resource Policy (CORP): This is a client-side (browser-enforced) response header that works similarly to X-Frame-Options but applies to sub-resources like images, scripts, and stylesheets. It has three self-explanatory values:

• Cross-Origin: Allows resource loading from any origin.
• Same-Origin: Only allows the resource to be loaded by documents from the same origin.
• Same-Site: Allows loading from the same site (e.g., example.com can load from sub.example.com).

When a browser tries to load a resource, it inspects the CORP header. If the relationship between the requester and the resource's server doesn't match the policy, the browser prevents the resource from loading. While simpler to deploy than Fetch Metadata, CORP acts after the server has processed the request, meaning it cannot prevent CSRF or timing attacks where the server's response itself (even if blocked by the browser) could leak information. Janc recommends using CORP in combination with Fetch Metadata, where server-side logic sets the CORP header based on the Sec-Fetch headers, reinforcing the protection.

Window-Level Isolation

To prevent untrusted windows from interacting with or tampering with sensitive windows, the primary mechanism is:

1. Cross-Origin Opener Policy (COOP): This response header allows a document to control its relationship with its opener (the window that opened it) or any windows it opens. Traditionally, an evil website opening a pop-up to a legitimate site could still perform actions like sending postMessage messages, traversing frames, or redirecting the pop-up, leading to tabnabbing and cross-site leaks. COOP breaks this linkage. It has three values:

• Unsafe-None: The default, status quo, with no protections.
• Same-Origin-Allow-Popups: Provides unidirectional protection. If your document is opened as a pop-up, its opener won't get a reference to it, but your document can still open pop-ups and communicate with them.
• Same-Origin: The most secure mode. It completely breaks the association in both directions, meaning neither the opener nor the opened window can access each other's references.

COOP applies only to top-level windows and should be used with X-Frame-Options to prevent embedding. It also comes with a Report-Only header for compatibility testing. A common caveat is that flows requiring cross-origin window communication (e.g., OAuth) might need Same-Origin-Allow-Popups instead of Same-Origin.

Process-Level Isolation (Cross-Origin Isolation)

The most complex and critical layer of isolation is at the operating system process level, driven by modern CPU vulnerabilities and browser bugs.

1. The Problem of Shared Processes: Since early 2018, attacks like Spectre and Meltdown have demonstrated that code executing in a browser renderer process can read data from its own address space, even if web security rules would normally prevent it. Furthermore, browser renderer processes are susceptible to memory corruption bugs, allowing attackers to execute code within the sandbox. The key insight is that if attacker-controlled code shares the same OS process as a sensitive application, the browser struggles to enforce security boundaries. This necessitates process separation as a security boundary.

1. Cross-Origin Isolation (COI): To achieve process-level isolation, applications must opt into a state known as Cross-Origin Isolation. When a document is cross-origin isolated, the browser guarantees that it lives in a separate OS process from all cross-origin content. This is achieved by combining Cross-Origin Opener Policy (COOP) with a new header:

• Cross-Origin Embedder Policy (COEP): This header dictates that a document can only embed resources that explicitly opt into being loaded by a cross-origin document. It currently has one value: Require-Corp. If a document sets COEP: require-corp, the browser will ensure that any embedded resources (images, scripts, iframes, etc.) from a cross-origin source must either:
• Have a Cross-Origin Resource Policy (CORP) header set (e.g., CORP: cross-origin).
• Be served with Cross-Origin Resource Sharing (CORS) headers.

If a resource does not meet these criteria, the browser will block its loading. This constrains what a cross-origin isolated document can embed but provides the crucial guarantee that all resources loaded into its process are either same-origin or explicitly opted-in for cross-origin embedding.

The combination of COOP: same-origin and COEP: require-corp tells the browser two things: the document doesn't directly interact with other cross-origin windows via window references, and it doesn't embed non-opt-in cross-origin resources. With these guarantees, the browser can confidently allocate the application to a separate OS process, providing robust process-level isolation. This also unlocks access to powerful browser APIs (e.g., SharedArrayBuffer, performance.measureUserAgentSpecificMemory()) that are unsafe to expose without such isolation.

The complexity arises not from individual mechanisms, but from their interplay and the deep-seated architectural challenges of the web. However, Janc stresses that understanding and adopting these features is critical for securing the next generation of web applications.

Demo / Proof of Concept

▶ Watch: Summary: Developer actions and security benefits (35:00)

While Artur Janc's talk is highly technical and provides concrete examples of code logic (e.g., for Fetch Metadata middleware) and header configurations, it does not feature a live, interactive demonstration or proof of concept in the traditional sense. Instead, the examples serve as illustrative blueprints for how developers can implement the discussed security mechanisms within their applications and server-side logic. The emphasis is on conceptual understanding and practical deployment strategies rather than a live exploit-and-mitigation showcase.

Defensive Implications

▶ Watch: Google's adoption strategy and challenges (41:00)

The mechanisms presented by Artur Janc offer a robust framework for web application defenders to significantly enhance their security posture. The core defensive implication is a shift from reactive, vulnerability-specific patches to a proactive, layered isolation strategy.

1. Defense in Depth: Deploying Fetch Metadata Request Headers, CORP, COOP, and COEP provides multiple layers of defense against both classic web vulnerabilities (CSRF, Clickjacking, XSSI, Tabnabbing, XS-Leaks) and emerging threats (Spectre/Meltdown-like attacks). These mechanisms act as a strong second line of defense, even if application-level logic has flaws.

1. Attack Surface Reduction: By enforcing strict policies on resource loading, window interactions, and process allocation, developers drastically reduce the attack surface available to malicious cross-origin content. This makes it harder for attackers to leverage browser features or shared memory to compromise user data or application integrity.

1. Enabling New Browser Features: Achieving Cross-Origin Isolation (via COOP + COEP) is not just about defense; it's also a prerequisite for accessing powerful new browser APIs, such as SharedArrayBuffer and performance.measureUserAgentSpecificMemory(). These APIs offer advanced capabilities that are inherently unsafe in a shared process environment, making isolation a key enabler for future web application development.

1. Future-Proofing and Staying Ahead of the Curve: As browser vendors like Google Chrome incrementally move towards safer defaults (e.g., SameSite cookies by default), applications that have already adopted these opt-in isolation mechanisms will be well-positioned. They will avoid the scramble to refactor and adapt when these restrictions become mandatory, ensuring smoother transitions and maintaining compatibility with evolving browser security models.

1. Deployment Strategy: Janc provides practical advice for adoption:

• Fetch Metadata: Utilize Report-Only modes or log potential rejections to identify breakage before full enforcement. Don't be afraid to block "bogus" cross-site traffic; Google's experience shows minimal breakage. Refer to Lucas Felb's article for detailed tips.
• CORP: Use in conjunction with Fetch Metadata for maximum protection, allowing server-side logic to dynamically set CORP based on request metadata.
• COOP: Leverage the Report-Only header to test for compatibility, especially for flows involving cross-origin pop-ups (e.g., OAuth, which might require same-origin-allow-popups).
• Internal Adoption (Google's Model): Google's approach involves its Information Security Engineering team doing much of the heavy lifting—writing documentation, building framework integrations, and assisting product teams with rollouts. While smaller companies might lack such resources, the principle of providing centralized support and guidance for developers remains crucial. For legacy applications, developers may still need to undertake significant refactoring, highlighting the importance of adopting these mechanisms early. Google's 70-75% adoption rate for Content Security Policy (CSP) demonstrates that widespread rollout is a multi-year effort.

In essence, these mechanisms empower developers to reclaim control over their application's security boundaries, moving towards a web platform where isolation is a robust, explicit guarantee rather than an implicit, often broken, assumption.

Key Takeaways

• Web Isolation is a Unified Problem: Many seemingly distinct client-side vulnerabilities (CSRF, Clickjacking, XSSI, Tabnabbing, XS-Leaks) stem from a single underlying issue: the web's fundamental lack of robust isolation between different applications.
• Three Levels of Isolation: Effective web security requires implementing isolation at the resource level (preventing untrusted loading), window level (preventing tampering), and process level (preventing memory-based attacks).
• Opt-in Mechanisms are Key: New browser features like Fetch Metadata Request Headers, Cross-Origin Resource Policy (CORP), Cross-Origin Opener Policy (COOP), and Cross-Origin Embedder Policy (COEP) provide the tools for developers to enforce these isolation boundaries.
• Process-Level Isolation is Critical: Hardware vulnerabilities (e.g., Spectre/Meltdown) and browser renderer bugs necessitate Cross-Origin Isolation (COI), achieved by combining COOP and COEP, to guarantee sensitive applications run in a separate OS process.
• Significant Security Benefits: Adopting these mechanisms offers defense in depth, reduces the attack surface, enables access to powerful new browser APIs, and future-proofs applications against evolving browser security defaults.
• Gradual but Necessary Adoption: While implementation can seem complex due to the web's architecture, each mechanism is conceptually simple. Their widespread adoption will be gradual but is essential for creating a safer web application ecosystem.

About the Speaker(s)

Artur Janc is a Senior Staff Information Security Engineer at Google, where he plays a pivotal role in securing Google's vast and diverse web application ecosystem. He leads a team of approximately a dozen security and software engineers dedicated to web security at Google. His work involves ensuring the security of thousands of applications, written in various languages and using different serving stacks, emphasizing the importance of a secure web platform as a foundation for these applications. Janc's expertise lies in understanding complex web security challenges and driving the adoption of advanced security mechanisms across Google's products, often working on the development and deployment of the very features he discusses, such as Fetch Metadata and Cross-Origin policies.