Fix guide · high · service_worker_imports_cross_origin

Service Worker imports JavaScript from a third-party host

Why it matters

The Service Worker spec includes importScripts(url) for loading additional code into the worker scope. Same-origin imports are fine — they're just a code-organisation tool. Cross-origin importScripts is functionally identical to <code>service_worker_cross_origin</code>: a third party gets to ship arbitrary code that the browser executes with full SW privileges on your origin.

Every concern from <code>service_worker_cross_origin</code> applies. The mitigation in the standard Service Worker model — Subresource Integrity for static script tags — does NOT extend to importScripts. The browser fetches the URL, runs whatever comes back, and you have no hash check to validate it.

Common offenders:

• Push-notification SDKs that publish a worker shim and then importScripts their full implementation from their CDN. (OneSignal, Pushwoosh, etc. — read their setup docs carefully.)
• Workbox configurations that load Workbox's CDN bundles via importScripts instead of bundling them.
• Analytics tools that ship a "background sync" worker which imports their batch-upload library cross-origin.

How to fix it

1. Replace importScripts(crossOriginUrl) with same-origin imports. Bundle the imported JavaScript into your build output and serve it from your own origin. This is what every modern SDK should already document; if yours doesn't, file an issue with the vendor.

1. For Workbox specifically, use the bundled distribution instead of the CDN:

``js // Bad importScripts('https://storage.googleapis.com/workbox-cdn/releases/7.0.0/workbox-sw.js'); // Good — bundle Workbox into your own SW build import { precacheAndRoute } from 'workbox-precaching'; precacheAndRoute(self.__WB_MANIFEST); ``

1. Set CSP worker-src 'self' and script-src 'self' to refuse the cross-origin import at the browser level. Note: CSP applied to the page also constrains the worker's importScripts calls.

1. If you genuinely need a cross-origin import (e.g. a vendor SDK with no bundled distribution), at minimum: pin the URL to a specific version (never @latest), monitor it for changes via an integrity hash you check at deploy time, and unregister the worker immediately if the hash drifts.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.