Micro-frontend security: what changes and what to do

A micro-frontend platform loads code from several places into one page. That changes the trust model, the Content Security Policy, the handling of tokens and the supply chain.

The trust model

One fact shapes everything else. Remotes loaded through Module Federation, Native Federation, import maps or custom elements run in the same document as the host. They share the same origin, the same DOM, the same storage and the same JavaScript environment.

The browser gives no isolation between them. A remote can read anything the host can read and do anything the host can do. If one remote is compromised, the whole application is compromised.

So every remote is fully trusted code, and the platform is as secure as its weakest pipeline. The only isolation the browser offers for UI code is an iframe on a different origin, ideally with the sandbox attribute. Use it for code you do not control, such as a vendor's widget. See iframes vs web components vs federation.

Loading code from several origins

The host decides which URLs remotes are loaded from. That decision is a security control.

• The manifest is sensitive. Whoever can change the manifest can make every user load arbitrary code. Serve it from infrastructure you control, restrict write access to the pipeline and log every change.
• Never build a remote URL from user input. A remote address taken from a query parameter or from browser storage is a direct path to script injection. Override mechanisms for developers must be disabled in production.
• Prefer few, well-known origins. Serving all remotes over HTTPS under one domain you own, with a path per remote, simplifies everything that follows.
• Protect the storage. The bucket or CDN that holds the remote files needs strict write permissions. Each team's pipeline should write only to its own path.

Content Security Policy

A Content Security Policy tells the browser which sources of code are allowed. With micro-frontends it needs explicit design.

• script-src must list the exact origins that serve remotes. Avoid wildcards. A strict example: script-src 'self' https://static.example.com.
• connect-src must cover the APIs of every remote and the location of the manifest.
• Avoid unsafe-inline and unsafe-eval. Verify that the production output of your build tool runs without them. Angular adds component styles to the page as inline style elements; since Angular 16 it can mark them with a nonce (ngCspNonce), so style-src does not need unsafe-inline either. Legacy AngularJS code has an ng-csp mode for running without unsafe-eval.

The policy belongs to the host, so the platform team owns it. Every new remote origin or API is a policy change. Run the policy in report-only mode first and review the violations before enforcing it.

Subresource Integrity checks a file against a hash. It works well for classic script tags with fixed content. For dynamically loaded modules, browser support is more limited, so check it before you rely on it. Angular also supports Trusted Types, which reduce the risk of DOM-based injection.

Token exposure

Any script in the page can read localStorage, sessionStorage and any variable it can reach. With more teams and more dependencies in one page, the chance that some script misbehaves grows.

• Prefer tokens that JavaScript cannot read. A backend-for-frontend that keeps tokens on the server and gives the browser a session cookie marked HttpOnly, Secure and SameSite removes the token from the page. It requires protection against cross-site request forgery.
• If tokens live in the browser, keep them in memory inside the host, give remotes a function that returns a valid token and keep lifetimes short. This limits accidental leaks. A malicious remote can still call the same function.
• Scope tokens narrowly. Least privilege on the backend limits what a stolen token can do.
• Keep tokens out of URLs, logs and events exchanged between remotes.

The patterns are in shared authentication.

Dependency supply chain

Each remote has its own dependency tree and its own pipeline. The third-party code that ends up in the page is the sum of all of them.

• Commit lockfiles and install from them in the pipeline.
• Scan dependencies in every remote's pipeline and fail on known critical vulnerabilities.
• Automate updates with a tool such as Renovate or Dependabot, so patches arrive everywhere.
• Separate deployment credentials per team. A leaked credential should reach one remote's path only.

Permissions per area

Authorisation has three layers, and only one of them is a security boundary.

1. The host hides what the user cannot use. Navigation entries and routes are filtered by role. This is user experience.
2. The remote checks again. A route guard prevents rendering a screen from a direct URL. This is also user experience.
3. The backend enforces. Every API verifies the user's permissions on every request. This is the security boundary.

Code that reaches the browser can be read and modified by the user. Treat permissions in the frontend as a convenience, and never ship secrets in a remote.

More in this section

• Local development with micro-frontends
• What are micro-frontends? A plain guide for decision makers
• When micro-frontends are worth it, and when they are not
• Module Federation vs Native Federation for Angular