MCP server Fenced Frames security — CSP bypass, navigate-to restriction circumvention, and size-constraint timing oracle

What the Fenced Frames element provides

<!-- Fenced Frame HTML element — Chrome 116+ -->
<!-- Unlike an iframe, the parent cannot inspect frame.contentDocument or frame.src -->
<fencedframe id="ad-frame"></fencedframe>

<script>
// Navigate a Fenced Frame to a URL selected by a Shared Storage worklet
// The parent cannot read which URL was chosen — that's the privacy model

await window.sharedStorage.worklet.addModule('/worklet.js');
const config = await window.sharedStorage.selectURL(
  'select-ad',
  [
    { url: 'https://cdn.example/ad-a.html' },   // URL index 0
    { url: 'https://attacker.example/track.html' } // URL index 1
  ],
  { data: {} }
);
// config is a FencedFrameConfig — opaque to the parent, navigates to selected URL
document.getElementById('ad-frame').config = config;
// The Fenced Frame now loads the selected URL; parent cannot read which one
</script>

Attack surface 1: worklet-controlled navigate-to URL

The critical insight: the Fenced Frame's URL is determined by the Shared Storage worklet's selectURL() return value — which the attacker controls through the worklet code. An attacker who can inject worklet code, or who can influence the stored values the worklet reads, controls where the Fenced Frame navigates.

• Worklet code injection via sharedStorage.run(). If the MCP tool output calls sharedStorage.worklet.addModule() with an attacker-controlled URL, the worklet code is attacker-provided. The worklet can read all stored keys for the attacker's origin and return any URL index — including one pointing to https://attacker.example/collect?data=....
• Stored value manipulation. If the tool output can write to shared storage (sharedStorage.set()) before the worklet runs, the attacker can influence which URL the worklet selects by controlling the stored values the worklet logic reads.
• URL list control. The URL list is passed by the calling page — controlled by the MCP tool output. Even if the worklet is legitimate, the tool output chooses which URLs are in the list.

Attack surface 2: size-constraint timing oracle

Fenced Frames have constrained dimensions: the parent sets allowed size options, and the selected URL must render within those constraints. The time it takes for the Fenced Frame to reach a stable layout is measurable from the parent via PerformanceObserver:

• URL A (e.g. a small ad image) renders in ~50ms.
• URL B (e.g. a heavy tracking page) renders in ~300ms.
• The parent measures load time via PerformanceObserver on the fencedframe element and infers which URL was selected — a binary oracle that leaks the worklet's decision.

This timing channel undermines the fundamental privacy guarantee of Fenced Frames: the parent is supposed to be blind to which URL was selected, but timing measurement partially defeats this.

Attack surface 3: Fenced Frame CSP is self-scoped, not inherited

Browser availability and Permissions-Policy

Fenced Frames ship in Chrome 116+ with the Privacy Sandbox feature flags. They are not available in Firefox or Safari. There is no Permissions-Policy directive to disable Fenced Frames globally — but disabling Shared Storage (Permissions-Policy: shared-storage=()) prevents selectURL() calls that create Fenced Frame configs, effectively neutralizing the worklet-navigation attack.

Defenses

Findings SkillAudit reports

Related guides: Shared Storage API security, Attribution Reporting API, Topics API.