New CS proposal: Micro Frontend Security Cheat Sheet

What is the proposed Cheat Sheet about?

Securing applications built using micro-frontend architectures (such as Webpack Module Federation, Web Components/Shadow DOM, iframe-based composites, or custom single-spa orchestrators). The focus is on the multi-app runtime's own trust boundaries — shared global execution contexts, cross-application event buses and postMessage channels, dynamic remote module loading, shared storage (localStorage/sessionStorage), and the host-shell-to-remote-app authorization split.

These are multi-app orchestration constructs with no direct analogue in a standard monolithic Single Page Application (SPA). Each has a documented failure mode where the developer's mental model ("this micro-app is sandboxed", "this remote module is trusted", "events are only internal") does not match what the browser actually exposes at runtime. Micro-frontends are increasingly adopted in large enterprise ecosystems, and that multi-team runtime mismatch is where most of their real-world data leaks, DOM clobbering, and privilege escalations come from.

What security issues are commonly encountered related to this area?

• Middleware / Host Shell Authorization Treated as Sufficient for Remotes — CWE-863, CWE-306. The host application or edge gateway handles initial authentication, but individual remote micro-frontends assume they are protected and fail to perform independent validation on their own localized API requests or state changes.
• Insecure Cross-App Communication (postMessage & Event Buses) — CWE-345, CWE-20. Micro-frontends frequently use window.postMessage or shared global event emitters to pass state or trigger actions across teams without strictly validating the event.origin or sanitizing payloads, allowing malicious scripts or rogue sub-apps to inject arbitrary commands or steal data.
• Global Scope Contamination and DOM Clobbering — CWE-829, CWE-79. Because multiple micro-frontends share the same global window and document context, a vulnerable or compromised remote module can overwrite shared prototypes, mutate global variables, or manipulate DOM elements belonging to the host shell or other teams.
• Token and Session Leakage via Shared Storage — CWE-922, CWE-200. Storing sensitive user tokens or session data in globally accessible storage (localStorage, sessionStorage, or shared cookies without strict path/domain scopes) allows any third-party or untrusted micro-frontend loaded on the page to read or exfiltrate them.
• Supply Chain and Dynamic Remote Code Loading Risks — CWE-829, CWE-506. Dynamically fetching remote entry scripts or JavaScript bundles at runtime (e.g., via Module Federation CDNs) without strict Subresource Integrity (SRI) or rigid Content Security Policies (CSP) opens the architecture to malicious code injection if a remote CDN or repository is compromised.
• State Pollution and Context Bleed — CWE-471. Improperly isolated state management stores (like Redux or Zustand instances shared across remotes) leading to unintended mutation or reading of cross-tenant or cross-role data between independently developed features.

What is the objective of the Cheat Sheet?

A concise, architecture-first checklist that a developer, architect, or security reviewer can apply to a micro-frontend codebase: where the multi-app runtime's real trust boundaries are, and the design rule for each — for example, "never rely on shared global scope for isolation; enforce strict origin checks on all inter-app messaging."

Deliberately out of scope, to keep it architecture-specific and concise: anything generically applicable to standard monolithic SPAs, basic XSS prevention, general OAuth/JWT token issuance, or backend API security. Those are already covered by existing cheat sheets (such as Cross Site Scripting Prevention Cheat Sheet, Authentication Cheat Sheet, etc.) and will be cross-referenced rather than restated.

What other resources exist in this area?

• Existing OWASP cheat sheets. Web Frontend Security, Cross Site Scripting Prevention, DOM-based XSS Prevention, Secrets Management, and Software Supply Chain Security cover the general vulnerability classes. This sheet would link to them for the general case and only document what is specific to multi-app micro-frontend runtimes.
• Relationship to other framework/frontend sheets. This sheet owns runtime multi-app integration boundaries (Module Federation, cross-app messaging, shared state/storage isolation, and host-remote trust boundaries).
• Why not a section in the Web Frontend Security cheat sheet? Micro-frontend orchestrations introduce completely distinct architectural patterns (runtime assembly, dynamic script remotes, multi-team CI/CD isolation, cross-app eventing) that deserve dedicated structural guidance beyond what a single subsection can provide.
• Third-party resources. Framework documentation covers setup and module federation configuration (e.g., Module Federation docs, single-spa guides), but it is shaped as feature and build documentation rather than a consolidated security hardening checklist.
• Testing Guide fit. This is design, architecture, and build-time guidance, so the Cheat Sheet Series is the correct home, though the Web Security Testing Guide (WSTG) could cross-reference it.

I am willing to author this and can start on a draft once the proposal is reviewed and approved.

Disclosure, per CONTRIBUTING.md: I used an AI assistant to help structure and research this proposal—identifying the gap analysis against existing cheat sheets and mapping out micro-frontend specific threat vectors (Module Federation, postMessage, global scope pollution). Every claim above was checked against standard multi-frontend security principles, and the scope decisions are mine. Any AI assistance in the eventual pull request will be declared there as well.