# Shared-runtime security and CSP boundary

Use this reference only when a remote in scope handles sensitive data and same-runtime (non-iframe) composition is proposed or already in place. It grounds the CSP trust-boundary collapse risk that makes "we used module federation" an insufficient answer to "is this isolated."

## What people get wrong

The naive story is:

> Module federation loads remote code into my app via a script tag, same as any other bundle-splitting technique. That's just how modern frontend works — it's not a security boundary question.

Wrong. A `<script>`-loaded remote, whether fetched via module federation, dynamic `import()`, or any other non-iframe mechanism, executes in the same JavaScript realm as the host: same `window`, same DOM, same Content-Security-Policy context, same cookies and storage the host can reach. There is no process boundary and no origin boundary unless one is deliberately introduced. "It's just code splitting" is true from a bundler's perspective and false from a trust-boundary perspective — those are different questions with different answers.

## Officially grounded shape

- CSP (per MDN) is enforced per browsing context / document, not per script origin within that document. A single CSP header applies to the entire page — host and every same-runtime remote share it. A remote that needs a looser policy (e.g., to run its own inline styles or connect to its own API) cannot get one without loosening the policy for the host and every sibling remote, unless that remote is isolated into its own document (an iframe with its own CSP).
- An iframe, by contrast, is a separate browsing context with its own document and can carry its own CSP (via the iframe's own response headers, or constrained further by the host's `Content-Security-Policy: frame-src`/`child-src` and the iframe's `sandbox` attribute). This is the mechanism that actually creates an enforceable boundary between host and remote, not module federation's build-time module resolution.
- React's official docs confirm `createRoot` supports mounting multiple independent applications into one page (see `references/../SKILL.md` Context7 Documentation Protocol), which is the mechanism most same-runtime micro-frontend compositions use — this confirms the *mounting* pattern is supported, but says nothing about *security isolation* between those roots, because there is none by default: all roots share one JS realm.

## Non-negotiable design rules

1. **Isolation level is a data-sensitivity decision, not a tooling decision.** Do not let the choice of module federation vs. iframes be driven by developer convenience or performance preference alone when a remote handles data (payment details, PII, credentials, admin actions) that should not be reachable by a compromised or buggy sibling remote. Convenience does not override trust-boundary requirements.

2. **A compromised or buggy same-runtime remote can read/write anything the host can.** This includes DOM access to sibling remotes' rendered output, cookies and localStorage/sessionStorage the host has access to, and any global state or event bus shared across the composition. Treat a same-runtime remote as having the same privilege as the host itself, not a scoped subset of it.

3. **Third-party-owned or externally-built remotes are a stronger case for iframe isolation**, independent of data sensitivity, because the supply-chain trust level of the remote's build pipeline is not controlled by the host team. A remote built and deployed by a team outside the organization's own release process should default to iframe isolation unless there is a specific, documented reason and compensating control (e.g., contractual code-review gate, pinned immutable artifact, subresource integrity) to trust it in the shared runtime.

4. **Shared-dependency version drift is itself a security surface**, not just a stability one. An outdated shared dependency pulled in by version-range negotiation (rather than pinning) can reintroduce a patched vulnerability across the entire composition, and the host team may have no visibility into which remote's dependency requirement caused the downgrade.

## High-risk assumptions to kill

- "Module federation isolates the remote because it's a separate bundle." — False; bundle separation is a build-time concept, not a runtime trust boundary.
- "The remote only touches its own DOM subtree, so it can't affect the rest of the page." — False by default; nothing prevents a same-runtime remote's script from reaching outside its mount point unless the host specifically constrains it (and few do).
- "We trust the other team, so isolation doesn't matter." — Trust in a team does not substitute for isolation against a supply-chain compromise of that team's dependencies or build pipeline.
- "CSP is already strict, so we're covered." — A strict host-level CSP still applies uniformly to every same-runtime remote; it does not give any one remote a tighter or differently-scoped policy than the rest of the page.

## Safe verification targets

- The response headers actually served for the host document — confirm the CSP header text, not a policy described in a design doc.
- Whether any remote requiring isolation is served inside an `<iframe>` with its own `sandbox` attribute and (where relevant) its own CSP header, versus mounted via same-runtime `createRoot`/module federation.
- The federation config's `shared` block or equivalent, to confirm whether shared dependencies are pinned/singleton-enforced or resolved via an unpinned version range.

## When to push back

Push back if the user asks for:

- same-runtime composition for a remote handling payment, auth, or other sensitive data with no isolation mitigation and no documented compensating control,
- trusting a third-party-owned remote in the shared runtime solely because "we trust that vendor," with no supply-chain control (pinning, integrity checks, review gate) backing that trust,
- treating an unpinned shared-dependency version range as acceptable because "it hasn't broken yet."

Those are not pragmatic trade-offs. They are unreviewed risk acceptance dressed up as an architecture decision.

# Review workflow and findings contract

Use this reference for the step-by-step boundary-review procedure and the required output shape for any micro-frontend adoption review, new-remote addition, or existing-composition audit.

## What people get wrong

The common bad assumption is:

> "We're using module federation, so the frontend is already decoupled — this review is a formality."

That is backwards. Module federation (and most non-iframe composition mechanisms) decouple the *build*, not the *runtime*. Host and remotes still share one JavaScript execution context, one CSP context, and — unless explicitly pinned or negotiated — a dependency graph that can silently drift out of compatibility. The review exists precisely because "we already use the right tooling" is not the same claim as "the boundary is safe."

## Step-by-step workflow

1. **Classify the composition mechanism.** Determine whether the architecture uses module federation (Webpack Module Federation, Vite plugin federation, or similar), iframe-based composition, or build-time/server-side composition (e.g., server-side includes, build-time module stitching). Do not proceed with mechanism-specific advice until this is confirmed from config, not assumed from the user's description alone.

2. **Determine the isolation level required per remote.** For each remote in scope, ask: does it render or handle data that should not be visible to, or influenced by, a bug or compromise in a sibling remote? If yes, same-runtime composition is disqualified unless a documented, specific mitigation is in place (e.g., a dedicated CSP frame-ancestors/sandboxed iframe for that one remote, or a Trusted Types policy scoped to it).

3. **Review the shared-dependency contract.** Locate the federation config's `shared` block (or equivalent for build-time composition) and check for: pinned or ranged version requirements, `singleton`/`strictVersion`-style enforcement (tool-specific — verify against that tool's current docs, not assumed from React docs), and whether version mismatches fail the build/fail loudly at runtime or fail silently (multiple copies of a library loaded, or an incompatible version silently used).

4. **Confirm ownership is unambiguous.** Every remote must map to exactly one owning team with clear on-call responsibility. A remote with co-ownership, no documented owner, or an owner that is "whoever last touched it" is a blocking finding, not a note.

5. **Assess blast radius.** For each remote, determine what happens to the host and sibling remotes if this remote throws an uncaught error, fails to load, or ships a broken bundle. Look for an error boundary (or equivalent isolation mechanism) around each remote's mount point, and confirm each remote has an independent deployment and rollback path that does not require a host-wide release.

6. **Check same-runtime multi-root hygiene, if applicable.** If the composition mounts multiple independent applications into one page (e.g., multiple `createRoot` calls, one per remote), confirm each root passes a distinct `identifierPrefix` to prevent `useId`-generated identifier collisions across independently-owned code — this is a concrete, checkable defect per official React docs, not a stylistic nit.

7. **Issue a verdict** using the response-minimum contract below.

## Required output shape

Every response to a micro-frontend boundary review must include:

- **Composition mechanism** — module federation / iframes / build-time-server-side, and whether this was confirmed from config or asserted by the user.
- **Isolation verdict per remote** — matched explicitly against that remote's data sensitivity; state which remotes require iframe-or-equivalent isolation and whether that mitigation exists.
- **Shared-dependency policy status** — present or absent; if present, its mechanism (pinned versions, `singleton`, `strictVersion`, or equivalent) and whether mismatches fail loudly or silently.
- **Blast-radius and ownership status per remote** — error-boundary/isolation mitigation present, independent deploy/rollback path present, owning team named.
- **Ranked findings** — file:line or config-key evidence where applicable, risk class (isolation gap, versioning gap, ownership gap, blast-radius gap), and a concrete fix.
- **Verdict** — approve / approve-with-notes / block.
- **Evidence level** — `live evidence` (read from actual config/source), `user-provided evidence` (asserted by the user without config to confirm), `documentation-based` (React/CSP/tooling docs grounding a claim), or `documentation-based, unconfirmed` (a claim the official docs do not explicitly confirm, e.g. cross-major-version React compatibility across remotes) — plus open questions the proposer must answer before the boundary can be considered fully reviewed.

## Verification targets

- The federation config's `shared` block (or build-time composition manifest) — the source of truth for the version-compatibility policy, not the proposer's verbal description of it.
- The mount-point code for each remote — to confirm an error boundary or equivalent isolation wraps it, not just that one exists "somewhere."
- The deployment pipeline configuration — to confirm each remote's independent deploy/rollback path actually exists as a distinct pipeline stage or repository, not merely as an intention.