D3-ABPI Application-based Process Isolation: How browsers isolate code, and how to verify it

When one component of an application is compromised, the damage it can do depends on whether the application itself keeps that component away from the rest of its memory and data. MITRE D3FEND names this countermeasure Application-based Process Isolation (D3-ABPI) and defines it as "Application code which prevents its own subroutines from accessing intra-process / internal memory space." It sits under the Isolate tactic as a child of Execution Isolation, beside Executable Allowlisting, Executable Denylisting, Hardware-based Process Isolation and Kernel-based Process Isolation. D3FEND's own worked example is the web browser, and its synonyms are Sandbox, Remote Browser Isolation and Browser-based Process Isolation. This card explains what the technique covers, which ATT&CK techniques D3FEND relates to it, where it is implemented, how to verify it is on, and where it stops. It is written for endpoint, browser and application security engineers. Browsers are listed alphabetically by engine where several are named; the order is not a ranking.

Key takeaways

• Isolation enforced by the application itself. D3-ABPI is the application deciding which of its own parts may reach which data, as opposed to the operating system (D3-KBPI) or the CPU (D3-HBPI) doing it.
• Browsers are the main real-world case. Site isolation, the same-origin policy, per-site storage and in-process sandboxes such as the V8 sandbox are all application-level isolation boundaries.
• Mostly on by default, so the job is keeping it on. Chromium-based desktop browsers have isolated all sites since Chrome 67; the practical control is policy that stops users and flags turning it off.
• D3FEND's ATT&CK links are inferred. They come from the shared Process artefact, so they show where process-level isolation is relevant, not proof that browser isolation blocks LSASS dumping.
• It does not fix application bugs. Site isolation explicitly leaves cross-site scripting, CSRF and clickjacking inside a site out of scope, and costs memory.

D3-ABPI at a glance

How it works

D3FEND's knowledge base article describes applications that "permit or deny a particular subroutine access to other data within the same application process" so that critical data cannot be tampered with. In a modern browser that idea is implemented as several layers, each of which D3FEND lists.

• Same-origin policy: a document or script from one origin (scheme, host and port) cannot read data from another origin's documents, Web Storage or IndexedDB. Cross-origin writes and embedding are usually allowed; reads are not.
• Site isolation: the Chromium design document states the goal that "a renderer process can be limited to contain pages from at most one web site", using the sandboxed renderer process as the boundary. A site is the scheme plus registered domain. Cross-site iframes render in their own out-of-process iframes. Firefox's equivalent (Fission) loads site-attributable content in per-site webIsolated content processes, with container tabs and private browsing kept separate.
• Cross-origin read blocking: the Chromium browser process blocks sensitive cross-site HTML, XML and JSON responses from reaching a renderer, using MIME type and content sniffing.
• CORS: cross-site data reaches a page only when the server allows it, which is why D3FEND warns that the protection depends on correct CORS configuration.
• Cross-origin isolation headers: a site that sends Cross-Origin-Opener-Policy: same-origin with Cross-Origin-Embedder-Policy: require-corp (or credentialless) becomes cross-origin isolated, which is the precondition for SharedArrayBuffer and high-resolution timers. Firefox loads such pages in dedicated per-site webCOOP+COEP processes.
• In-process sandboxes: the V8 sandbox keeps the JavaScript engine's heap inside a reserved address region and replaces raw pointers with offsets, so memory corruption in the heap should not spread to the rest of the renderer. The V8 team's April 2024 post says it had been on by default for about two years on 64-bit Chrome builds, cost about 1% or less on typical benchmarks, and was not yet a strong security boundary.

Remote browser isolation, which D3FEND lists as a synonym, moves the same idea off the endpoint: web content runs in a remote container and only a rendering or a sanitised page reaches the user. It is covered in the Remote Browser Isolation Guide.

ATT&CK techniques D3FEND relates to D3-ABPI

Relationship type: inferred only. D3FEND links D3-ABPI to ATT&CK through its Process artefact: these techniques access, create or produce a Process, and D3-ABPI isolates Process. D3FEND labels such relations "inferred, experimental". The seven below are the same-artefact relations in the D3FEND ontology (checked November 2026); the D3FEND website also shows a wider list through related artefacts, including T1053.005 Scheduled Task, T1505.001 SQL Stored Procedures, T1505.002 Transport Agent and Modify Authentication Process (T1556). That list also includes Disable or Modify Tools under an ID that ATT&CK v20 has revoked; its v20 successor is T1685. Each ID was checked against ATT&CK v20.

Read the table as context, not coverage. Browser site isolation does nothing against LSASS dumping; the credential rows are there because D3FEND relates every Process-isolating technique to them. For those rows the relevant siblings are D3-HBPI Hardware-based Process Isolation and D3-KBPI Kernel-based Process Isolation, and the attack itself is covered in T1003 OS Credential Dumping. Web shell response is in T1505 Server Software Component Defensive Guide.

Where it is implemented

For Microsoft Edge, Microsoft documents SitePerProcess ("Enable site isolation for every site") as a Boolean in SOFTWARE\Policies\Microsoft\Edge, supported from version 77 on Windows and macOS, needing a browser restart. When enabled, users cannot opt out; when disabled or not configured, users can opt out through edge://flags, but site isolation itself stays on. The Chromium documentation states the same opt-out is not possible when an enterprise policy enables site isolation. Header-level controls are covered in the Permissions Policy, COOP, COEP and CORP Guide and the Iframe Sandboxing and srcdoc Security Guide.

Implementation steps

1. Inventory browsers and versions. Find every browser and embedded browser runtime in use, including Android devices and in-app web views. Chromium documents that site isolation is not supported in Android WebView or on Chrome for Android devices with less than 2 GB of RAM.
2. Lock isolation on by policy. Set SitePerProcess to enabled for managed Chromium-based browsers so users and flags cannot opt out. For Android, decide whether full-site isolation is worth the memory cost; by default Chrome 77 and later isolates only sites users log into on devices with at least 2 GB of RAM.
3. Isolate sensitive internal origins. Use IsolateOrigins with wildcards such as https://[*.]corp.example.com (an example value) to give admin consoles and identity provider pages finer-grained processes.
4. Remove the escape hatches. Find shortcuts and scripts that launch browsers with --disable-site-isolation-trials, --disable-web-security or --disable-features=IsolateOrigins,site-per-process. Chromium lists these as ways to switch isolation off.
5. Pilot and watch memory. Chromium measured about 10 to 13% more memory on desktop with all sites isolated and many tabs open, and about 3 to 5% on Android for login sites. Pilot on the lowest-specification devices first.
6. Fix the web applications. Ask application teams to stop relying on document.domain (deprecated, per MDN), set tight CORS rules and adopt COOP and COEP where they need cross-origin isolation.
7. Roll back narrowly. If a business application breaks, test with the opt-out flag on one test device, fix the application, and avoid disabling isolation fleet-wide. Chromium notes that full-page layout became asynchronous and unload handlers may not always run, which are the usual causes.

How to verify it works

• Check the mode: in Chromium-based browsers open chrome://process-internals (Edge: edge://process-internals) to see the active site isolation mode. In Firefox open about:processes, which lists content processes and labels COOP+COEP processes "cross-origin isolated".
• Prove the boundary: load a page with a cross-site iframe and open the browser task manager (Shift+Esc in Chromium). The iframe should run under a different process ID from the main page.
• Check policy delivery: confirm the policy appears as applied in the browser's policy page (chrome://policy or edge://policy) on a sample of devices.
• Check application headers: confirm self.crossOriginIsolated is true in the browser console on pages that need it.

Limits, bypasses and failure patterns

• Bugs inside one site: the Chromium design document places cross-site scripting, CSRF, XSSI and clickjacking within a victim site out of scope. Isolation separates sites, not the parts of one site.
• Escaping the boundary: an attacker who chains a renderer exploit with a sandbox escape or a browser process bug crosses the boundary. Fast patching is the defence; isolation buys time.
• Partial coverage on mobile: Android isolates a subset of sites by default and Android WebView is not covered, so apps that embed web content do not get the same protection.
• Leaky embedding: MDN notes cross-origin reads are "leaked through embedding", for example image dimensions, and Chromium notes images and scripts cannot all be blocked. Sensitive resources should not be embeddable.
• Flags left from troubleshooting: a shortcut with an isolation-disabling flag survives long after the support call that created it.
• Isolation treated as data protection: a compromised site still has full access to its own cookies and storage. Session theft within a site needs controls covered in Browser Storage Security Guide.

Framework mapping

Related countermeasures

• Kernel-based Process Isolation (D3-KBPI) and Hardware-based Process Isolation (D3-HBPI): the operating system and CPU boundaries that browser sandboxes rely on underneath.
• Executable Allowlisting (D3-EAL) and Executable Denylisting (D3-EDL): the other Execution Isolation children; see D3-EAL Executable Allowlisting.
• Execution Isolation: the parent technique, which groups all five; the wider D3FEND picture is in the MITRE D3FEND Guide.

Practitioner checklist

• Inventory browsers, versions and embedded web views across desktop and mobile.
• Enforce SitePerProcess on managed Chromium-based browsers.
• Add IsolateOrigins entries for admin consoles and identity provider pages.
• Hunt for shortcuts and scripts that pass isolation-disabling flags.
• Verify isolation mode on sample devices each quarter with process-internals or about:processes.
• Ask application teams to retire document.domain and tighten CORS.
• Adopt COOP and COEP on applications that need cross-origin isolation.
• Keep browsers inside the vendor's supported release window.

Standards and references

• MITRE D3FEND: Application-based Process Isolation (D3-ABPI)
• The Chromium Projects: Site Isolation design document
• The Chromium Projects: Site Isolation overview
• Mozilla: Firefox process model
• Microsoft Learn: Microsoft Edge SitePerProcess policy
• V8: The V8 Sandbox
• MDN: Same-origin policy
• MDN: Cross-Origin-Opener-Policy

Related NHI Mgmt Group resources: Browser Security Hardening Guide · Remote Browser Isolation Guide · M1048 Application Isolation and Sandboxing · Enterprise Browser and Browser Security Guide · MITRE D3FEND Guide