Security: SRI, CSP, and CORS for knitkit

Pin and verify remote modules with Subresource Integrity, configure CSP for federated pages, and set correct CORS headers on remote servers.

Module federation is powerful precisely because it executes code from another origin inside your page at runtime. That power comes with real risk: if an attacker can tamper with a remote module or its manifest, they run arbitrary JavaScript with your page’s full privileges. knitkit addresses this through three complementary layers — Subresource Integrity (SRI) for hash pinning, Content Security Policy (CSP) for origin allowlisting, and CORS for controlling which hosts can fetch your remote assets. Using all three together gives you defense in depth; using none is the default footgun of naive module federation setups.

---

Subresource Integrity (SRI)

knitkit build computes a sha384 hash for each shared asset and records it in the manifest’s integrity field:

{
  "shared": {
    "react": {
      "version": "18.3.1",
      "requiredVersion": "^18.0.0",
      "singleton": true,
      "url": "./shared/react-18.3.1.js",
      "integrity": "sha384-..."
    }
  }
}

How the hash is enforced depends on the environment:

Browser (shared deps)

knitkit injects shared dependencies into the page’s import map using the integrity key, so the browser natively refuses to execute a tampered shared module. This is available in Chrome 127 / Firefox 138 / Safari 18.4 — verify support for your target browsers at ship time.

{
  "imports": {
    "react": "https://cdn.example.com/shared/react-18.3.1.js"
  },
  "integrity": {
    "https://cdn.example.com/shared/react-18.3.1.js": "sha384-..."
  }
}

Node SSR

@knitkit/node verifies the sha384 hash itself before executing any fetched remote module. A mismatch throws a coded KNIT_ERR_SRI_MISMATCH error and the module is never evaluated. This check runs unconditionally on every module fetch, regardless of the browser support matrix.

Limitation: exposed modules in the browser

The browser platform provides no integrity option on a dynamic import(). This means an exposed module loaded by loadRemote in the browser cannot be hash-verified by the platform alone.

Your options:

1. Put exposed modules in the import map with integrity — the browser enforces the hash at the import-map level before the module runs.
2. Rely on @knitkit/node’s server-side verification — which always runs and blocks mismatches before they reach the client.
3. Serve remotes from origins you control over HTTPS — reducing the attack surface to your own infrastructure rather than a third-party CDN.

Manifest signing (verifying the manifest file itself, not just individual assets) is on the knitkit roadmap.

---

Content Security Policy (CSP)

A federated page fetches modules and manifests from one or more remote origins. Your CSP must allow those origins explicitly. Here is a starting-point header — tighten the origin lists to exactly the CDN hostnames you use:

Content-Security-Policy:
  default-src 'self';
  script-src  'self' https://cdn.example.com 'nonce-{RANDOM}';
  connect-src 'self' https://cdn.example.com;
  require-trusted-types-for 'script';

Key points:

• Import map nonce — the import map is a <script type="importmap"> inline tag. Under a strict CSP, allow it with a per-request nonce attribute (e.g. <script type="importmap" nonce="abc123">). This is strongly preferred over 'unsafe-inline', which would defeat inline-script protection for your entire page.
• connect-src — must include every origin from which you fetch a manifest or a module. registerRemotes and loadRemote both use fetch internally; a missing connect-src entry silently blocks the request.
• Prefer an allowlist over wildcards — script-src 'self' https://cdn.example.com is significantly safer than script-src *. Each remote origin you add to script-src is a trust decision; make it explicit.

Generate your CSP nonce server-side on each request and inject it into both the HTTP header and every inline <script> tag. Most meta-framework adapters (Next.js, Nuxt, SvelteKit) have middleware hooks for this.

---

CORS

Remote servers must send Access-Control-Allow-Origin headers for three categories of resources: manifests (knit.manifest.json), exposed module files, and shared asset files. Without CORS headers, cross-origin fetch calls fail silently in the browser.

Configure your remote’s static host (CDN, object storage, or web server) to return:

Access-Control-Allow-Origin: https://your-host.example.com

For fully public assets intended to be used by any host, * is acceptable:

Access-Control-Allow-Origin: *

nginx.conf

location /knit/ {
  add_header Access-Control-Allow-Origin "https://your-host.example.com";
  add_header Access-Control-Allow-Methods "GET, OPTIONS";
}

If a remote returns a 404, is unreachable, or does not include the required CORS headers, registerRemotes and loadRemote fail with a coded KNIT_ERR_LOAD_FAILED error. The error message includes a suggestion pointing at CORS configuration and reachability as the likely cause.

CORS errors in the browser are opaque — the browser’s network tab shows a failed request but does not expose the response body. If you see KNIT_ERR_LOAD_FAILED, open the browser console and check for a CORS policy message alongside the knitkit error.

---

Trust model

Every remote origin you federate into your host executes JavaScript with your page’s full privileges — the same cookies, storage, DOM access, and CSP context as your own first-party code. Keep that in mind when making trust decisions:

• Use HTTPS for all remote assets. HTTP origins are trivially intercepted; never federate over unencrypted connections.
• Pin hashes wherever the platform supports it. SRI on the import map catches CDN compromises and supply-chain attacks for shared dependencies.
• Scope your CSP to the smallest set of origins necessary. Each entry in script-src is an explicit grant of code-execution trust.
• Only federate origins you control or have a contractual relationship with. A third-party CDN that serves one of your remotes is part of your trusted computing base. Vet it accordingly.

VM-based or ShadowRealm-based SSR isolation (to limit a compromised remote’s blast radius on the server) is a roadmap item for @knitkit/node.