Security Best Practices

Security Risks in Federated Architectures¶

Micro frontends introduce unique security challenges due to their decentralized nature. Key risks include:
- Cross-Origin Vulnerabilities: Federated modules may load from different origins, increasing exposure to XSS (cross-site scripting) or CSRF (cross-site request forgery) attacks.
- Untrusted Module Execution: Dynamically loaded modules could contain malicious code if not validated, leading to code injection or data exfiltration.
- Shared State Exposure: Sensitive data (e.g., auth tokens) may leak if modules improperly access shared state or communication channels.
- Insecure Communication: Poorly configured module-to-module communication could allow interception of sensitive payloads.

Mitigation: Content Security Policy (CSP)¶

A Content Security Policy (CSP) header restricts the sources from which scripts, styles, and other resources can load, mitigating XSS and data theft.

Example CSP Header¶

Content-Security-Policy: \
  default-src 'self'; \
  script-src 'self' https://trusted-cdn.com; \
  style-src 'self' https://trusted-cdn.com; \
  img-src 'self' data:; \
  connect-src 'self' https://api.example.com; \
  frame-src 'none';

Key Directives:
- script-src: Limits script execution to trusted origins.
- connect-src: Restricts API calls to authorized endpoints.
- frame-src 'none': Prevents embedding in iframes (defending against clickjacking).

Implementation: Enforce CSP via HTTP headers or <meta> tags in HTML. Use tools like CSP Evaluator to test policies.

Mitigation: Module Validation & Integrity Checks¶

Validate federated modules to ensure they originate from trusted sources and haven’t been tampered with.

1. Integrity Hashes¶

Use cryptographic hashes (e.g., SHA-256) to verify module integrity.

# Example: Validate a module using Webpack's integrity hash
webpack --mode production --output-integrity

<!-- Load module with integrity check -->
<script src="https://example.com/module.js" integrity="sha384-abc123..." crossorigin="anonymous"></script>

2. Secure Module Loading¶

Use secure contexts (HTTPS) for all module loads.
Whitelist module origins in a central registry (e.g., a config file or API).
Reject modules that don’t match expected hashes or origins.

Mitigation: Secure Communication Between Modules¶

Use secure, scoped communication between federated modules:
- PostMessage with Encryption: Encrypt payloads using AES or Web Crypto API.

// Parent module
window.postMessage({ data: "secure_payload", token: "auth_token" }, "https://trusted-origin.com");

// Child module
window.addEventListener("message", (e) => {
  if (e.origin !== "https://trusted-origin.com") return;
  // Process encrypted payload
});

- Shared State with Secure Contexts: Use a centralized auth service (e.g., OAuth 2.0) to manage token distribution and scope access.

Mitigation: Sandboxing & Isolation¶

Isolate modules to limit their access to system resources:
- Iframe Sandboxing: Use sandbox attributes to restrict iframe capabilities.

<iframe src="https://trusted-module.com" sandbox="allow-scripts allow-same-origin"></iframe>

- Web Workers: Offload sensitive processing to workers with restricted permissions.

Key takeaways¶

Enforce CSP headers to block XSS and unauthorized resource loading.
Validate module integrity using hashes and origin whitelists.
Secure inter-module communication with encryption and scoped contexts.
Isolate modules via sandboxing and secure execution environments.
Regularly audit federated dependencies and update policies to address new threats.