security: iframe sandbox allows same-origin access to parent page

[GeneralJerel]

Description

Severity: P0 — Security

In apps/app/src/components/generative-ui/widget-renderer.tsx:523, the iframe sandbox attribute is:

sandbox="allow-scripts allow-same-origin"

The combination of allow-scripts + allow-same-origin allows the iframe to access window.parent and all parent DOM/cookies. While the CSP mitigates remote script loading, agent-generated HTML with inline scripts has full same-origin access to the host page.

Failure mode

XSS via agent-generated content — malicious or hallucinated HTML could read/modify parent page state, steal cookies, or call CopilotKit APIs.

Suggested fix

Remove allow-same-origin from the sandbox. The iframe only needs allow-scripts. The postMessage bridge already works cross-origin. If allow-same-origin is truly required (e.g., for CDN fetches), tighten CSP connect-src and document the tradeoff.

Open question

Is allow-same-origin intentional? What breaks if it's removed?

From self-review finding F01

[GeneralJerel]

To check if this is actually a feature, e.g. if resolving this would break the renderer

[GeneralJerel]

Update from PR #51: allow-same-origin is currently required for import maps to work in srcdoc iframes. Without it, bare specifiers like import * as THREE from 'three' fail to resolve, breaking Three.js (and potentially gsap/d3/chart.js) ES module renders.

What to investigate

• Can we use a blob: URL instead of srcdoc? Import maps may work without allow-same-origin in blob iframes.
• Can we serve the iframe from a dedicated sandbox subdomain so allow-same-origin doesn't grant parent-page access?
• Is the risk acceptable for a demo/template project with no auth or client-side secrets?

Current mitigation

• CSP restricts script/connect sources
• No auth tokens or session data exposed client-side
• Comment added in code referencing this issue