Subresource Integrity (SRI) Enforcement in Module Federation 2.0

[kmye]

Objective

Research the best practices and technical feasibility of enforcing Subresource Integrity checks on federated modules.

Acceptance Criteria

• Summarize methods for SRI in federated deployment
• Highlight limitations, caveats, and potential workarounds
• Provide actionable recommendations

Notes

Specific Scenarios SRI Safeguards Against
Hacked Third-Party Dependencies: If a vendor CDN or a federated remote server is breached, your users remain safe because their browsers will block the altered payload.

Malicious ISP Injection: In regions or networks where Internet Service Providers (ISPs) inject tracking scripts or advertisements into web traffic, SRI prevents these modified scripts from running on your site.

Cache Poisoning: If a malicious actor successfully poisons a public CDN cache with a corrupted file, SRI ensures your application rejects the poisoned asset.

[Dng132FEI]

For RSBuild: import SubresourceIntegrityPlugin from @rspack/core and add the security parameter to defineConfig
[Applies to static components only, not federated modules - please see my comment in the latest message]

Example:

Host

import { defineConfig } from "@rsbuild/core";
import { pluginReact } from "@rsbuild/plugin-react";
import { pluginSass } from "@rsbuild/plugin-sass"
import { SubresourceIntegrityPlugin } from "@rspack/core";
import { pluginModuleFederation } from "@module-federation/rsbuild-plugin";

export default defineConfig({
  plugins: [
    pluginReact(),
    pluginSass(),
    pluginModuleFederation({
      name: "host",
      remotes: {
        mfe_frontend: "mfe_frontend@http://localhost:3001/remoteEntry.js",
      },
      shared: {
        react: { singleton: true, requiredVersion: "^19.2.6" },
        "react-dom": { singleton: true, requiredVersion: "^19.2.6" },
        "react-router-dom": { singleton: true, requiredVersion: "^7.15.1" },
      },
    }),
  ],
  tools: {
    rspack: {
      plugins: [new SubresourceIntegrityPlugin()],
      output: { crossOriginLoading: 'anonymous' },
    }
  },
  server: {
    port: 3000,
    historyApiFallback: true,
  },
  source: {
    entry: { index: './src/main.tsx' },
  },
  html: {
    template: "./public/index.html",
  },
  output: {
    assetPrefix: "auto",
  },
  security: {
    sri: {
      enable: true,
    },
  },
});

Remote:

import { defineConfig } from "@rsbuild/core";
import { pluginReact } from "@rsbuild/plugin-react";
import { SubresourceIntegrityPlugin } from "@rspack/core";
import { pluginModuleFederation } from "@module-federation/rsbuild-plugin";

export default defineConfig({
  plugins: [
    pluginReact(),
    pluginModuleFederation({
      name: "mfe_frontend",
      filename: "remoteEntry.js",
      exposes: {
        './MfeFrontend': './src/mfe/MfeFrontend.tsx', // key → import specifier
      },
      shared: {
        react: { singleton: true, requiredVersion: "^19.2.6" },
        "react-dom": { singleton: true, requiredVersion: "^19.2.6" },
        "react-router-dom": { singleton: true, requiredVersion: "^7.15.1" },
      },
    }),
  ],
  tools: {
    rspack: {
      plugins: [new SubresourceIntegrityPlugin()],
      output: { crossOriginLoading: 'anonymous' },
    }
  },
  server: {
    port: 3001,
    headers: { "Access-Control-Allow-Origin": "*" },
    historyApiFallback: true,
  },
  html: {
    template: "./public/index.html",
  },
  output: {
    assetPrefix: "auto",
  },
  security: {
    sri: {
      enable: true,
    },
  },
});

[Dng132FEI]

Hi all, I did further research and investigation into this.

I was wrong yesterday at the meeting. The configs will only implement SRI for static resources like favicon.ico, index.js, index.css, etc. They will not implement SRI for federated modules.

Hence, distributed SRI will become very challenging to implement when remotes deploy independently at different timings, and likely not feasible in our use case. It may be better to rely on other means like internal trusted artifact pipelines, secure deployments, etc to enforce security for federated modules in our case.

[kmye]

From my research, the by enabling SRI config, it will computes the hashes of every output chunks.

How SRI Works:

1. Remote app compile and computes the hash of compiled chunk, assets and entry file and put into mf-manifest.json
2. When Host boots up, it executes init function and fetches the remote manifest file, the host needs to holds a mapping of the remote and hashes
3. When user navigate to the page that needs to load the JS module, MFv2 intercepts the outgoing URL, look up the hash and append the hash and script element to the page before DOM insertion
4. Standard browser security takes over.

Yes, the provided SubresourceIntegrityPlugin does not provide collecting of hash mapping, but it is not entirely unachieveable. We need to explore ways for a secure way to handle this, if we are not doing it what are other protection we can put in place?

[Dng132FEI]

Hi all, I did further research and investigations. I discovered that SRI can be implemented for remote modules using RSBuild! I have yet to figure out how to do it for Vite, though I'll investigate this as well.

I have posted my technical spike onto my own GitHub. The implementation is complex and involves custom plugins, thus please refer to it for implementation details.

https://github.com/Dng132FEI/mfe-sri-demo?tab=readme-ov-file#readme
https://github.com/Dng132FEI/mfe-sri-demo/blob/main/host/README.md
https://github.com/Dng132FEI/mfe-sri-demo/blob/main/remote/README.md