Relax script-src and worker-src to 'self' so Code Apps can use code-splitting and Web Workers

[Craig-Humphrey]

[Apologies for the AI created content, but Claude and I have been working on this together]

Summary

The CSP applied to deployed Code Apps currently forces every line of JS into a single monolithic bundle and forbids Web Workers entirely. As Code Apps grow beyond simple data-entry forms, this is becoming a real ceiling on what's practical to build. Two small CSP relaxations - both to 'self' only, no third-party origins - would unlock standard React/Vite patterns (React.lazy, route-based code-splitting, Web Workers) without weakening the security posture.

The constraints today

When npx power-apps push deploys a Code App, the served page enforces (relevant directives only):

Directive	Value	What it blocks
script-src	restricted (no 'self' for dynamic scripts)	Rollup-emitted chunk files loaded via runtime <script> injection - i.e. React.lazy(), import(), manualChunks
worker-src	'none'	new Worker(url), new Worker(blobUrl), Service Workers, Shared Workers
frame-src	'self' plus a fixed list	blob: URLs in iframes (e.g. PDF preview via <iframe src=blobUrl>)
connect-src	restricted	Direct fetch to Dataverse Web API (correctly routed via SDK proxy - not the issue here)

The first two are the painful ones for bundle size and library compatibility.

Concrete case: pdf.js in a real app

We're building a vehicle-leasing Code App (React 19 + Vite 7 + Fluent UI v9) that needs to render PDFs (vehicle fitout specs uploaded to Dataverse). pdf.js is the standard choice. None of the documented integration paths work under the current CSP:

1. ❌ new pdfjsLib.GlobalWorkerOptions.workerSrc = '/pdf.worker.js' then new Worker(url) - blocked by worker-src 'none'
2. ❌ ?raw import + blob URL Worker - blob: also blocked by worker-src 'none'
3. ❌ workerSrc = '' (run on main thread officially) - pdf.js v5 throws No GlobalWorkerOptions.workerSrc specified
4. ❌ Dynamic import() fallback from the pdf.js library itself - blocked by script-src

The only thing that works is a static ES module import of the worker file so Vite inlines it into the main bundle:

import * as pdfjsLib from 'pdfjs-dist';
import 'pdfjs-dist/build/pdf.worker.min.mjs'; // statically bundled into main JS

pdf.js detects globalThis.pdfjsWorker and falls back to a LoopbackPort that runs everything on the main thread. Cost: ~1.5 MB added to the main bundle, plus no worker isolation = main thread blocked while rendering pages.

Our app's current dist/assets/index-*.js is 2.37 MB minified (≈700 KB gzipped). Vite's default 500 KB warning fires on every build. The app still runs fine, but:

• First paint is delayed by parsing 2+ MB of JS even on routes that don't render PDFs
• The TTI cost is paid by every user, even ones who never open a lease detail page
• Mobile / slow-network performance degrades faster than it should
• We can't lazy-load anything else either (charts, rich-text editors, CSV parsers, etc.)

What we tried (and why each was a dead-end)

Approach	Result
vite-plugin-pwa to push the worker to a Service Worker	worker-src 'none' blocks it
React.lazy(() => import('./pages/LeaseDetail')) with route-based splitting	Built chunks 404 or get CSP-blocked at runtime - Rollup emits chunks as separate JS files loaded via dynamic import() which compiles to a runtime <script> injection
build.rollupOptions.output.manualChunks to split vendor bundles	Same problem - any chunk that's not the entry point needs to be loaded at runtime
Building everything as one IIFE (format: 'iife')	Works but defeats the purpose - bundle is even bigger
Lazy-loading via fetched JS evaluated with Function() / eval()	Hostile to CSP and we don't want to ship that
assetsInlineLimit cranked up for images (per workaround in #316)	Helps with binary upload corruption but makes the bundle bigger, not smaller

The fundamental issue: Rollup's code-splitting, React.lazy, and Web Workers all depend on the browser being allowed to load additional JS from 'self' after page load. The CSP forbids exactly that.

Proposed changes

Two minimal relaxations, both same-origin only:

1. script-src should allow 'self' for additional chunks

The Vite build output is uploaded to the same *.powerplatformusercontent.com origin as the main HTML. Allowing 'self' for script-src lets the browser load Rollup-generated chunk files, which unlocks:

• React.lazy() for route-based code-splitting
• import() for on-demand library loading (e.g. only load pdf.js when a PDF is actually shown)
• manualChunks for vendor/framework separation and better cache hit rates

Security impact: minimal. Same-origin scripts are already trusted - the main bundle is loaded from 'self' today.

2. worker-src should allow 'self' (and blob: if practical)

This lets standard libraries use Web Workers as designed:

• pdf.js - render off the main thread, keep UI responsive
• monaco-editor, sql.js, comlink, ffmpeg.wasm, @tensorflow/tfjs, ONNX Runtime Web, ag-Grid, etc.
• Service Workers → unlocks the PWA / offline-mode requests in [Feature] Add PWA Support #255 and Offline Mode #299

Security impact: minimal. Workers run in their own context and have no DOM access; allowing same-origin workers is industry standard.

Alternative / interim option

If the above is too big a change, even a per-app opt-in in power.config.json would be valuable:

{
  "csp": {
    "allowSelfScripts": true,    // enable code-splitting
    "allowSelfWorkers": true     // enable Web Workers
  }
}

Makers who want the stricter default get it; makers who need bundle-size relief or worker libraries can opt in knowingly.

Why this is worth doing now

Code Apps GA'd in late 2025. Most apps in flight today are small enough not to hit the 500 KB threshold yet, which is probably why this hasn't been raised before - I checked existing issues/discussions and found nothing on lazy, chunk, code split, dynamic import, or bundle size (only #316, which is the related binary-asset CLI bug with the same assetsInlineLimit workaround). But:

• Real apps using mainstream React/Fluent UI patterns hit ~500 KB very quickly (Fluent UI v9 alone is substantial)
• Any app using PDFs, charts, rich text editors, maps, or offline support hits 1-3 MB
• Mobile users (relevant for field workforces, who are a natural Code Apps audience - see [Feature Inquiry] Support for running Code Apps in Power Apps Mobile #286) get the worst of it
• The workaround (assetsInlineLimit) doesn't scale, as @eschavez confirmed in [Bug] Static binary assets (images) corrupted by storageproxy after deployment #316
• Related ideas in the backlog ([Feature] Add PWA Support #255 PWA Support, Offline Mode #299 Offline Mode) also depend on worker-src relaxation

Related

• [Bug] Static binary assets (images) corrupted by storageproxy after deployment #316 - storageproxy corrupts binary assets (same assetsInlineLimit workaround)
• [Feature] Add PWA Support #255 - PWA Support (blocked by worker-src 'none')
• Offline Mode #299 - Offline Mode (same)
• [Feature Inquiry] Support for running Code Apps in Power Apps Mobile #286 - Code Apps in Power Apps Mobile (bundle size matters more on mobile)

Happy to provide a minimal reproducible Code App showing the React.lazy / pdf.js / Worker failures under the current CSP if that would help.