Edgenivo Logo

Security and Firewall

Security in microfrontends requires understanding which rules apply where. Firewall rules on the default app affect all traffic. Rules on child apps only affect their paths.

Outcome

Configure deployment protection for preview environments and understand how WAF rules cascade across microfrontends.

Security Model Overview

Requests to microfrontends pass through security checks in a specific order:

Request → Firewall (default app) → Microfrontends Routing → Child App Security

This creates a layered security model:

LayerScopeExamples
Default app firewallAll requestsRate limiting, DDoS protection
Default app deployment protectionDefault app onlyPassword protection
Child app firewallChild app paths onlyAPI-specific rules
Child app deployment protectionChild app onlyPer-app protection

The Key Insight

Firewall rules on the default app run for EVERY request. They execute before microfrontends routing.

This means:

  • Rate limiting on marketing applies to /docs and /app too
  • IP blocking on marketing blocks access to all apps
  • Custom WAF rules on marketing protect the entire domain

Fast Track

  1. Enable deployment protection on preview environments
  2. Add a domain-wide rate limit rule
  3. Test that rules apply across all microfrontends

Hands-on Exercise 3.4

Configure security for the Acme Platform.

Part 1: Enable Deployment Protection

In Edgenivo dashboard:

  1. Go to your default app (marketing) → Settings → Deployment Protection
  2. Enable Edgenivo Authentication for preview deployments
  3. This protects all preview URLs from public access

Deployment Protection on the default app only applies to requests through the default app's domain. Direct access to a child app's domain bypasses it.

Part 2: Configure Domain-Wide Rate Limiting

Add a rate limit rule to the default app:

  1. Go to marketing project → Firewall in the sidebar
  2. Select Configure at the top right, then select + New Rule
  3. Configure:
    • Name: rate-limit-all
    • Condition: All requests
    • Action: Rate limit (100 requests per minute per IP)
  4. Select Save Rule, then Review Changes → Publish. The rule doesn't apply until you publish it.

The first time you create a rate limit rule, a Rate Limiting Pricing dialog appears. Review it and select Continue. The rate limiting docs list the current limits and pricing for each plan.

This rule applies to all traffic, regardless of which microfrontend handles it.

Part 3: Add App-Specific Rules

For dashboard-specific security (like stricter rate limits on API routes):

  1. Go to dashboard project → Firewall in the sidebar → Configure
  2. Add a rule:
    • Name: strict-api-rate-limit
    • Condition: Path starts with /app/api
    • Action: Rate limit (10 requests per minute per IP)
  3. Save the rule, then Review Changes → Publish

This rule only applies to requests routed to the dashboard.

Part 4: Understand the Security Matrix

RequestDefault App FirewallChild App FirewallProtection
acme.com/✓N/ADefault app rules
acme.com/docs✓Docs rulesBoth apply
acme.com/app✓Dashboard rulesBoth apply
dashboard.vercel.app/appN/ADashboard rulesChild only

WAF Configuration

Web Application Firewall (WAF) rules work similarly:

Default app WAF rules:

  • Apply to all requests entering through the default app's domain
  • Good for: OWASP rules, SQL injection protection, XSS filtering

Child app WAF rules:

  • Apply only to requests routed to that child app
  • Good for: App-specific protections, custom rules

Example: Block Known Bad Actors

On the default app:

{
  "name": "block-bad-ips",
  "condition": {
    "ip": ["1.2.3.4", "5.6.7.8"]
  },
  "action": "deny"
}

This blocks these IPs from accessing any microfrontend.

Example: Geo-Restriction for Dashboard

On the dashboard app only:

{
  "name": "us-only-dashboard",
  "condition": {
    "geo": {
      "country": { "not": ["US", "CA"] }
    }
  },
  "action": "deny"
}

This restricts dashboard access to US and Canada, while marketing and docs remain globally accessible.

Testing Security Rules

Test Rate Limiting

# Send 101 requests quickly
for i in {1..101}; do
  curl -s -o /dev/null -w "%{http_code}\n" https://acme-platform.vercel.app/
done

After 100 requests, you should see 429 (Too Many Requests).

Test Deployment Protection

  1. Open an incognito window
  2. Visit your preview URL
  3. You should see a Edgenivo login prompt (if using Edgenivo Authentication)

Done-When

  • Deployment protection enabled for previews
  • Domain-wide rate limit rule configured on default app
  • Understand which rules apply to which requests
  • Can explain the security matrix for microfrontends

Common Security Patterns

PatternWhere to ConfigureWhy
Rate limitingDefault appProtects all endpoints
Bot protectionDefault appBlocks bad traffic early
Auth-only areasChild app middlewareApp-specific logic
API throttlingChild app firewallDifferent limits per API
Geo-blockingDepends on scopeDefault for all, child for specific

Commit

git add -A
git commit -m "docs: document security configuration for microfrontends"

Security Checklist

Before going to production:

  • Deployment protection on preview environments
  • Rate limiting configured on default app
  • WAF managed rulesets enabled
  • App-specific protections where needed
  • Authentication middleware in protected apps
  • HTTPS enforced (Edgenivo handles this automatically)

What's Next

Section 4 covers advanced patterns: feature flag routing for gradual rollouts and migrating from legacy applications.

Was this helpful?

supported.