SPFx adds Subresource Integrity to a script when the manifest path is { path, integrity }

Symptom

You built a "thin" SPFx package: the web part in the .sppkg only reads which version to run, downloads <version>/manifest.json from your CDN and calls SPComponentLoader.loadComponent. Nothing checks what it downloads. A stolen CDN deploy token, a hijacked DNS record or a compromised CI job is enough to run arbitrary code with the permissions of your app in every customer tenant.

While adding a check you also see confusing test results:

• a manifest with a deliberately wrong integrity still reports "loaded" in the console;
• a second loadComponent on the same page fails even though the manifest is now correct;
• the SHA-384 you computed from the file on disk does not match what the CDN serves.

Cause

1. SRI support is in sp-loader, but only for the object form of path. When a script resource's path is an object, sp-loader resolves it to { path, integrity } and SharePoint adds the integrity and crossorigin="anonymous" attributes to the script tag. A plain string path gets no integrity. On the tenant where this was measured the behaviour sits behind the SharePoint flight SpfxSubresourceIntegrity (60737), which was on. Check a customer tenant with document.querySelectorAll('script[integrity]') on a page that runs your component.
2. SPFx caches components by id + version. If every runtime build shares the manifest version (common when the version lives elsewhere), a second "version" on the same page resolves to the already-loaded module. The SRI check never runs.
3. requirejs caches by script path. A path that failed once stays failed on that page.
4. CRLF in the working copy. A GitHub Pages repository with core.autocrlf=true and no .gitattributes can have CRLF on disk while Pages serves the LF bytes stored in git. A hash computed from disk does not match the served file.

Fix

Inject integrity before loading (the hashes come from a source you trust, not from the CDN response itself):

// manifest bytes were already checked against a trusted sha384 of the manifest file
for (const name of Object.keys(m.loaderConfig.scriptResources)) {
  const r = m.loaderConfig.scriptResources[name];
  if (r.type === 'component') continue;            // host-provided (react, sp-*): leave alone
  if (r.type !== 'path') throw new Error('unsupported resource ' + name);
  const p = typeof r.path === 'string' ? r.path : r.path.path;
  if (/^[a-z]+:|^\/\/|\.\./i.test(p)) throw new Error('bad path ' + name);
  r.path = { path: p, integrity: trustedSri[name] }; // 'sha384-…'
}
// every internalModuleBaseUrls entry must start with your own CDN folder
await SPComponentLoader.loadComponent(m);

Where to keep the trust anchor. A public key or hash list inside a bootstrap served from the same CDN is replaced together with the bootstrap. Pin the bootstrap itself from the .sppkg:

• After the build, copy the web part bundle to an immutable, content-addressed name on the CDN, for example my-app-loader_<contenthash>.js.
• Rewrite the web part manifest in release/manifests (it goes into the .sppkg) to path: { path: "my-app-loader_<contenthash>.js", integrity: "sha384-…" }. package-solution accepts the object form.
• The page now loads the bootstrap from the CDN with integrity taken from the App Catalog. A replaced bootstrap on the CDN does not run.
• Never overwrite or prune that file while any App Catalog may point at it.
• Sign the list of versions and hashes the bootstrap trusts (for example ECDSA P-256 with WebCrypto) and keep only the public key in the bootstrap.

Do not move the bootstrap into the .sppkg if guests use the app. "includeClientSideAssets": true works technically. In SPFx 1.22 (spfx-heft-plugins), heft package-solution --production then:

• packs every file in release/assets into ClientSideAssets/;
• rewrites internalModuleBaseUrls of every manifest in release/manifests to HTTPS://SPCLIENTSIDEASSETLIBRARY/.

SharePoint then serves the files from /sites/appcatalog/ClientSideAssets/<solution id>/. On the tenant where this was measured, that library had exactly two read grants:

• Everyone except external users;
• the read-only tenant admin role.

External (guest) users therefore cannot load the bootstrap, unless the tenant serves client-side assets through the Office 365 public CDN. A test under an admin account will not show it. Check roleassignments of the target library before you move code there.

Hash what the CDN serves: take the bytes from the git index (git cat-file blob :<path>), not from the working copy.

Testing in the console without lying to yourself:

• give each attempt its own manifest version and its own bundle path;
• reload the page after a failed attempt;
• window._spComponentLoader is available on modern pages.

Testing the real bootstrap without touching the CDN: if the bootstrap remembers the highest signed sequence number it has seen in localStorage (rollback protection), set that key to a huge number and reload. The bootstrap must refuse to start the app. Restore the key afterwards.

Measured

SharePoint Online, SPFx 1.22.2, November 2026, our own tenant:

Same tenant, same day, by page type:

Both page types loaded the scripts through RequireJS (data-requiremodule on the tag). Lazy chunks of the library did get integrity on the list page too, because the library's own webpack runtime sets it, not SharePoint.

Gotchas

• List and library pages ignore manifest integrity (measured November 2026). A ListView Command Set there runs unverified by the browser even with a correct { path, integrity } manifest, and so does any library it loads with loadComponent. A tenant-wide Application Customizer on a library view was measured too (November 2026): its entry bundle had no integrity either. Other extension types (Field Customizer, Form Customizer) were not measured — check them the same way before you rely on SRI. Measure on the page where the component actually runs: [...document.scripts].filter(s => s.src.includes('<bundle>')).map(s => s.hasAttribute('integrity')). Use hasAttribute: the integrity property is an empty string when the attribute is missing. For the libraries your extension loads, you can check the bytes yourself first — await fetch(url, { integrity, mode: 'cors' }) rejects on a mismatch — and refuse to call loadComponent when it fails. The extension's own entry bundle stays out of reach, because SharePoint loads it.

• Lazy chunks are not covered. The webpack runtime inside the verified entry bundle creates their script tags. Embed a chunk-hash map in the entry bundle (it is verified with it) and set integrity in the runtime, or avoid lazy chunks in code you load this way.

• Without the flight there is no integrity attribute. You are left with checking the manifest hash, and there is a window between that check and the browser fetching the bundle.

• A bundle already on the page is reused. If an older bootstrap on the same page loaded the same bundle path without integrity, SharePoint will not check it again.

• Changing the bootstrap means a new .sppkg. Keep it minimal and stable, and put everything else in the library on the CDN.

• Scripts your own code loads are not covered either. Vendor libraries injected with <script>, worker code fetched into a blob: URL and importScripts inside a worker bypass both the manifest and the chunk map – see spfx-sri-scripts-your-bundle-loads-itself.md.