Vercel Logo

Security and Firewall

Security in microfrontends requires understanding which rules apply where. WAF rules on the default app cover all traffic on the shared domain. A child app's rules add a second check for the paths it serves.

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 → Platform-wide firewall → Default app WAF → Microfrontends routing → Child app WAF

This creates a layered security model:

LayerScopeExamples
Platform-wide firewallEvery request, including direct requests to child domainsDDoS mitigation (automatic)
Default app WAFEvery request on the default app's domainsRate limiting, IP blocking, custom rules
Default app deployment protectionEvery request on the default app's domains, child paths includedVercel Authentication
Child app WAFChild app paths, plus direct requests to the child's own domainsAPI-specific rules
Child app deployment protectionDirect requests to the child's own domains onlyPer-app protection

The Key Insight

WAF rules on the default app run for EVERY request on the shared domain. Requests routed to a child app then pass that child project's WAF too (docs).

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 Vercel dashboard:

  1. Go to your default app (marketing) → Settings → Deployment Protection
  2. Enable Vercel 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. Vercel recommends Standard Protection on the default app and protection for all deployments on each child app, so acme-docs and acme-dashboard are only reachable through the marketing domain.

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
acme-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: the Bot Protection and AI Bots managed rulesets, which every plan can turn on. The OWASP Core Ruleset is plan-gated, so check managed ruleset availability before you count on it.

Child app WAF rules:

  • Apply to requests routed to that child app, and to direct requests to the child's own domains
  • 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-marketing.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 Vercel login prompt (if using Vercel 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 server code (layout.tsx, route handlers)App-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 (Bot Protection on any plan, OWASP where your plan includes it)
  • App-specific protections where needed
  • Authentication checks in each protected app's server code
  • HTTPS enforced (Vercel 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.