Existing Defenses: Partial Measures and Structural Limits

Existing defenses do real work. Content Security Policy, Subresource Integrity, Zero Trust, and Server-Side Rendering each address a real component of the threat surface. Measured against ATG, each one shows a boundary where its protection stops. The boundary is not a matter of operator skill or implementation maturity. It is architectural.

Outside the browser, far fewer of these defenses exist. Mobile WebViews and hybrid runtimes, desktop application shells built on web technology (Electron, Tauri), vehicle infotainment, IoT and operational-technology dashboards, AR/VR scene graphs, productivity-tool extension hosts, and the path by which an application calls an inference endpoint (the address an application calls to get an answer from a model) all lack an equivalent of the browser primitives by default. Where browser-engine components are embedded inside non-browser hosts, the browser-class defenses can apply to the embedded surface; they do not extend to the surrounding runtime.

The architecture defeats integrity checks made against a file before it is delivered; the defense that complements them is watching how code behaves at the rendering layer while it runs. That defense exists today in concept and in narrow practice but is not yet a default capability of any Client Runtime in the deployed landscape.

Runtime behavioral monitoring is an open engineering problem. Inspecting objects the running code has changed, DOM nodes, output from tools a model is allowed to run on its own, and inference responses as fast as the runtime executes them costs real CPU, memory, and energy, against the same economic incentives that produced the Compute Tax. Partial expressions exist today in narrow forms: in-browser script-behavior telemetry shipped by client-side attack surface management vendors, runtime sandboxing layers that observe a subset of API calls, and policy layers that sit in front of a model and check its responses against fixed rules before an application uses them. None is yet a runtime-default capability with rendering-layer breadth across the Client Runtime landscape. The requirement is architectural: it has been named, the engineering path to building it into runtimes by default is open, and the fact that no runtime ships it today does not make the requirement go away.

14.1: The Structural Limits of Existing Defenses

Each condition is a property of the architectural pattern itself. No amount of operational discipline closes them.

• Structural blindness in existing frameworks: NIST CSF, ISO 27001, MITRE ATT&CK as a defensive vocabulary, and the broader compliance landscape were built against a threat model in which the application was what got reviewed, signed, and shipped. ATG operates after that boundary, on the rendering surface the frameworks do not address. The frameworks are not wrong about the territory they cover. They say nothing about the territory the runtime occupies, and the program documents, audit checklists, and detection vocabularies built from them carry that same gap into daily operations.
• The runtime code injection problem: verification ends before execution. Every meaningful integrity check finishes before delivery, and the runtime executes afterward. Supply Chain Injection names the consequence: malice is delivered into the runtime through the same supply chain the runtime was designed to consume, and the delivery clears every pre-delivery control along the way. Existing defenses operate inside the pre-delivery window. The injection ATG enables happens after that window closes. The structural property holds across every CSR-capable Client Runtime in the deployed landscape (browser, mobile, desktop, vehicle, IoT, AR/VR, productivity-tool host, UGC interactive runtime), even where the pre-delivery defenses available to each host differ.
• The scale problem: defenders cannot enumerate what their applications load at runtime. The requirement to know your suppliers' suppliers at the provider boundary, the structural reasons no one can list the scripts a runtime loads, and the Manifest Illusion each name a different facet of the same observation. Existing defenses presume an inventory that operationally does not exist. The supply chain is too large for any defender to act on it item by item. The frameworks that govern security programs do not see the runtime boundary. The verification regimes that govern delivery end at that boundary. The inventories that would let defenders see past that boundary cannot be assembled at the scale the runtime supply chain reaches. Each of the four major existing defenses runs into one or more of these three problems. The defenses do what they were designed to do. ATG operates outside what they were designed to defend.

14.2: Content Security Policy: Value and Limits

Content Security Policy raises attack cost meaningfully in the browser context. CSP declares an allowlist of URLs the browser runtime may fetch, restricts inline-script execution, and provides structured reporting on policy violations. Three architectural limits sit beyond what the policy constrains.

• Allowlist coverage: CSP constrains URL allowlists, not what those allowed URLs deliver. If a CDN on the allowlist is later bought or compromised, following the four-step CDN acquisition attack model, it delivers adversarial content and the policy still permits it. The runtime fetches from an allowed address; the policy checks the address, not what comes back. CSP cannot evaluate what the trusted source actually serves. One narrow exception is worth stating: Content Security Policy Level 3 permits a hash source expression to match an external script where the script element also carries matching integrity metadata. That is genuine content pinning. It reaches script and style elements only, it requires the integrity metadata alongside it, and it is checked at load like everything else.
• Runtime Anarchy: once allowed code executes inside the page, CSP does not constrain what that code does within the runtime. Privileged-API access, DOM manipulation, storage access, and runtime resource loading all happen with the host application's full permissions regardless of CSP. Once a script is allowed in, it inherits the page's privileges, and the policy has nothing further to say about how it uses them.
• Coverage outside the browser: the policy mechanism is a browser-engine feature. Mobile-application runtimes, hybrid desktop shells, AR/VR scene graphs, smart-TV apps, vehicle infotainment, IoT and OT dashboards, and productivity-tool extension hosts carry no equivalent capability at default. Where browser-engine components are embedded inside non-browser hosts (mobile WebViews, Electron-rendered application surfaces), CSP can apply to the embedded surface; the surrounding runtime carries none of the policy's protection. CSP is necessary and worth deploying within the browser context. It is not sufficient against ATG, and it does not extend beyond the browser to the rest of the CSR-capable Client Runtime landscape.

14.3: Subresource Integrity: Value and Limits

Subresource Integrity provides hash-based verification that a fetched resource matches an expected hash. For a static script or stylesheet fetched from a known URL with a stable content hash, the mechanism is meaningful protection: if whoever serves the file swaps its contents, or something substitutes it in transit, the bytes change, the check fails at fetch time, and the runtime never runs it. SRI was designed for exactly that case: a fixed file that does not change between fetches. Three architectural limits define where the coverage ends.

• Load-time scope: SRI checks the resource as it is fetched. What that resource does once it runs is not covered. The declarative form of the mechanism covers script and link elements. A resource fetched by already-executing code can carry integrity metadata as well, because the Fetch standard gives every request an integrity field and fetch() accepts one, but that verification is opt-in per call, is required by nothing, and is audited by nothing. Supply Chain Injection and the Two-Stage Attack are designed to defeat file-level integrity verification by separating the file that was checked from the behavior that eventually executes. The static script that passes the hash check fetches data, configuration, or further executable content at runtime, and the malice rides in there. SRI does what it does correctly; the attack model relocates the malice to where SRI does not look.
• Hash-stability assumption: SRI requires content addresses to be known and stable in advance. Scripts injected by a tag manager, content generated on the fly, AI inference responses, and CDN content built per request all defeat the assumption. Where the resource a runtime loads is generated, personalized, or otherwise permitted to vary by request, no advance hash exists to verify against. The mechanism cannot apply to content that is not stable in the first place.
• Coverage in non-browser Client Runtimes: SRI is a browser-engine feature. Mobile-application runtimes, hybrid desktop shells, AR/VR scene graphs, vehicle infotainment, IoT and OT dashboards, and productivity-tool extension hosts carry no equivalent default capability. Where browser-engine components are embedded inside non-browser hosts, SRI can apply to the embedded surface; outside the embedded surface, the mechanism does not exist. SRI is correct for what it covers. The coverage is narrower than the ATG attack surface, and what remains outside it is the Detection Blindspot. Static integrity verification of the file as it is fetched is what the Two-Stage Attack defeats. Monitoring how code behaves at the rendering layer while it runs is not.

Subresource Integrity pins file content at fetch, and it needs a hash known in advance, which content generated per request never has. Certificate pinning fixes the identity of an endpoint, so an adversary holding that endpoint satisfies the pin and delivers through it. URL pinning and allowlisting fix which address may be contacted, approving the sender rather than the package. Lockfile pinning fixes what enters the build and says nothing about what running code fetches afterward. Only the first inspects content, and none of the four can hash a response that does not exist until the request is made.

14.4: Zero Trust: Why ATG Operates Beneath It

Zero Trust Architecture is a meaningful security posture against an adversary attempting to gain access to the system. NIST SP 800-207 is guidance rather than a standard, and it sets out seven tenets. Four of them bear on ATG: continuous verification, least privilege at runtime, explicit denial of implicit trust extension, and continuous re-evaluation under changing context. Applied to identity, network, and workload boundaries, the framework raises substantial defensive cost across the access perimeter. ATG operates beneath the Zero Trust boundary because ATG happens after the trust decision has been made.

• Session-scope persistence: Zero Trust decisions establish trust at the session boundary. Once a user is authenticated and a session is granted, the session itself carries persistent trust over the duration of its operation. The check happened when the session was issued; after that, whatever the session loads is what runs.
• Inheritance of trust to fetched content: ATG attacks the content the trusted session loads at runtime. The session is trusted; the supply-chain content delivered into the session is trusted by inheritance. Zero Trust does not re-check each fetched resource against the decision that granted the session, and its policy machinery has no way to judge whether a fetched file is intact.
• Runtime principles structurally absent: continuous verification, least privilege at runtime, explicit denial of implicit trust extension, and continuous re-evaluation under changing context are not part of how client-side rendering works by default. The absence holds across every CSR-capable Client Runtime: browser, mobile, desktop, vehicle, IoT, AR/VR, productivity-tool host. Zero Trust is the right framework at the boundary. ATG is below the boundary, on every CSR-capable Client Runtime on which the session runs.

14.5: Server-Side Rendering as Partial Mitigation

Server-Side Rendering materially reduces ATG exposure. SSR moves the runtime composition out of the client environment: the application is delivered as HTML, and the client does not assemble it at runtime in the way a CSR application does. Several CSR properties are reduced or absent in pure SSR: the App Blueprint assembly becomes a server-side problem, the Manifest Illusion is largely dispelled, and Code That Writes Code at the client is largely absent. Against ATG, SSR is a partial mitigation, and two limits explain why it is only partial.

• Hydration brings exposure back: modern "SSR" applications often hydrate on the client (the client attaches JavaScript behavior to the server-rendered HTML and takes over from there), load additional scripts at runtime, and integrate third-party content. The hydration model brings ATG exposure back to the extent the client takes over composition after the initial render. Pure SSR with no client-side scripting is the strongest mitigation; few real applications meet that bar.
• Browser-context only: SSR is a browser-context mitigation. Most non-browser CSR-capable Client Runtimes (mobile applications, desktop shells, vehicle infotainment, IoT dashboards, productivity-tool extension hosts) have no SSR analog. The runtime composition in these hosts is structurally on the client because the host is the client. SSR does not extend as a mitigation across the rest of the Client Runtime host landscape. SSR materially reduces ATG-class exposure for browser-hosted applications that can bear the user-experience trade-off. For high-assurance browser contexts where modern UX is not the primary requirement, SSR is the strongest defense available today. SSR does not address the non-browser Client Runtime host platforms.

14.6: Defenses Outside the Browser, and the Endemic Flaw

Outside the browser, far less of this defensive machinery exists. CSP, SRI, the Permissions API, Trusted Types, and the surrounding browser-engine primitives are capabilities every modern browser provides, and each has to be switched on by the application that wants it. The other nine CSR-capable Client Runtime host categories carry analogs that range from partial to absent.

That asymmetry points to something deeper: ATG is endemic to client-side rendering. Because the vulnerability arises from the architecture itself, composition at render time and execution on the Glass, it is present, independently, in every runtime that uses the pattern: browser, mobile webview, desktop app, smart TV, kiosk, embedded panel. It is not transmitted between runtimes; each inherits it from the shared design. The Endemic Flaw is that inherited condition: like any endemic condition it cannot be eradicated by treating individual cases, and a per-runtime patch does not reach the pattern that produces it. It is not an infection that spreads, but a pre-existing condition every Client Runtime is born with.

CSR runs in mobile applications, desktop shells, vehicle infotainment, IoT and OT dashboards, AR/VR scene graphs, smart-TV applications, productivity-tool extension hosts, and UGC interactive runtimes. Each is a non-browser CSR-capable Client Runtime. The browser-class defenses do not generally extend to these hosts, even where browser-engine components are embedded inside them. Those hosts are unprotected in proportion to how little of that machinery reaches them, and the amount varies by host rather than being uniformly absent. Where a host embeds a browser engine, that engine's primitives are available to the embedded surface whether or not the host configures them: Electron's own security documentation recommends a Content Security Policy and documents two ways to deliver one. What no host outside the browser provides is a default, and availability is not deployment.

The gap takes a different shape in each platform category.

• Mobile native and hybrid runtimes: over-the-air bundle delivery, where code updates are pulled straight from a server after install without going back through the app store, has no equivalent of a file-integrity check at runtime. Hybrid and cross-platform runtimes (React Native, Capacitor) have no equivalent of CSP for the JavaScript bridge that lets web code call native device functions. Where the host embeds a WebView, browser-engine defenses can apply inside the WebView surface; they do not extend to the surrounding native host.
• Desktop app shells and plugin hosts: Web-technology desktop shells (Electron, Tauri) and the plugin marketplaces of development environments (IntelliJ Platform, VS Code VSIX extensions) carry no consistent analog of CSP or Trusted Types. A loaded plugin runs with the host application's permissions.
• Appliance, IoT, vehicle, and control-system runtimes: smart-TV client-side rendering, IoT dashboards, vehicle infotainment, and the operator screens of industrial control and SCADA systems carry minimal to no equivalent defensive ecosystem at the rendering layer. Well-run industrial control environments compensate with perimeter measures (URL pinning, mutual TLS, network segmentation, hardened runtime engines) that materially narrow the script environment relative to commercial deployments. Those perimeter measures do not reach the supply-chain source of the rendering-layer components, which is where ATG sits. Where these runtimes embed browser engines, the embedded surface can carry browser-class defenses; the surrounding runtime cannot.
• AR/VR, game and UGC, productivity and data-tool runtimes: the AR viewers that open a 3D file straight from a web page (USDZ AR Quick Look), the Roblox and Unity AssetBundle content paths, Jupyter notebook trust models, and the add-ins that run inside Office documents carry no equivalent of browser-class defenses.
• Inference-API consumption: no standard exists for checking an AI inference response against what the application asked it to produce. The data-endpoint trust gap is unaddressed across every CSR-capable Client Runtime that consumes inference output. The Endemic Flaw is the structural convergence point across the language, platform, provider, open-source, and AI layers: the same architectural exposure appears in each, and per-runtime measures do not reach the pattern that produces it. Each layer carries the same architectural requirement: a single source of truth for the resources the runtime actually loads, detection of content swapped at runtime, and protection against tampering with the application's state in memory while it runs.

The architectural patterns translate across runtimes. The implementing code does not.

Inside the browser, the defenses do real work. Outside the browser, the equivalent maturity does not exist as a default capability. The complement that would close the gap, runtime behavioral monitoring at the rendering layer, is not yet a default capability of any Client Runtime in the deployed landscape. Operational maturity reduces how many positions an adversary can occupy and shortens the time between activation and discovery. What it cannot do is establish, at the moment of render, that a permitted source returned what the application expected, because no Client Runtime in the deployed landscape offers an operator that check. The limit sits in what a runtime provides, not in how well an operator runs it.