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:
| Layer | Scope | Examples |
|---|---|---|
| Platform-wide firewall | Every request, including direct requests to child domains | DDoS mitigation (automatic) |
| Default app WAF | Every request on the default app's domains | Rate limiting, IP blocking, custom rules |
| Default app deployment protection | Every request on the default app's domains, child paths included | Vercel Authentication |
| Child app WAF | Child app paths, plus direct requests to the child's own domains | API-specific rules |
| Child app deployment protection | Direct requests to the child's own domains only | Per-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
/docsand/apptoo - IP blocking on marketing blocks access to all apps
- Custom WAF rules on marketing protect the entire domain
Fast Track
- Enable deployment protection on preview environments
- Add a domain-wide rate limit rule
- 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:
- Go to your default app (marketing) → Settings → Deployment Protection
- Enable Vercel Authentication for preview deployments
- 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:
- Go to marketing project → Firewall in the sidebar
- Select Configure at the top right, then select + New Rule
- Configure:
- Name:
rate-limit-all - Condition: All requests
- Action: Rate limit (100 requests per minute per IP)
- Name:
- 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):
- Go to dashboard project → Firewall in the sidebar → Configure
- Add a rule:
- Name:
strict-api-rate-limit - Condition: Path starts with
/app/api - Action: Rate limit (10 requests per minute per IP)
- Name:
- Save the rule, then Review Changes → Publish
This rule only applies to requests routed to the dashboard.
Part 4: Understand the Security Matrix
| Request | Default App Firewall | Child App Firewall | Protection |
|---|---|---|---|
acme.com/ | ✓ | N/A | Default app rules |
acme.com/docs | ✓ | Docs rules | Both apply |
acme.com/app | ✓ | Dashboard rules | Both apply |
acme-dashboard.vercel.app/app | N/A | Dashboard rules | Child 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/
doneAfter 100 requests, you should see 429 (Too Many Requests).
Test Deployment Protection
- Open an incognito window
- Visit your preview URL
- 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
| Pattern | Where to Configure | Why |
|---|---|---|
| Rate limiting | Default app | Protects all endpoints |
| Bot protection | Default app | Blocks bad traffic early |
| Auth-only areas | Child app server code (layout.tsx, route handlers) | App-specific logic |
| API throttling | Child app firewall | Different limits per API |
| Geo-blocking | Depends on scope | Default 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?