--- title: "Rate Limiting and DDoS Protection for Modern Web Applications" description: "How to implement layered rate limiting and DDoS protection using Cloudflare, Vercel middleware, and application-level controls. Protect your infrastructure without blocking real users." --- A DDoS attack against an unprotected web application can take it offline in minutes. Rate limiting that is too aggressive blocks legitimate users and destroys conversion rates. Getting the balance right requires understanding both the threat landscape and the tools available to defend against it. Modern web applications built on Vercel and Cloudflare have access to excellent protection mechanisms at every layer. The challenge is configuring them correctly.
The Threat Landscape
Volumetric Attacks
Traditional DDoS attacks flood network infrastructure with traffic volume. These are largely handled by infrastructure providers. Cloudflare absorbs volumetric attacks at the network edge before they ever reach your application.
If your application sits behind Cloudflare, you are already protected against most volumetric attacks without any configuration.
Application Layer Attacks (Layer 7)
More sophisticated attacks target your application directly with HTTP requests that look legitimate at the network layer. These include request floods against specific endpoints, credential stuffing against login forms, inventory hoarding against e-commerce endpoints, and scraping attacks against data-rich pages.
These require application-aware protection because volumetric filtering alone does not stop them.
Slow Attacks
Slowloris and similar attacks hold connections open as long as possible without completing requests, exhausting your connection pool. Web Application Firewalls and connection timeout configuration handle most of these.
Layer 1: Cloudflare
Cloudflare is the outermost protection layer. Configure it before worrying about application-level controls.
WAF Rules
Enable the Cloudflare managed ruleset for your zone. These rules block known attack patterns, vulnerability scanners, and malicious user agents based on Cloudflare's threat intelligence across their entire network.
Create custom WAF rules for application-specific patterns: blocking requests to admin paths from non-authorized IP ranges, requiring specific headers that only your legitimate clients send, and blocking user agents associated with bad bots.
Rate Limiting at the Edge
Cloudflare's rate limiting evaluates requests at the edge before they reach your origin. Configure rate limiting rules for your most attack-prone endpoints: login, registration, API authentication, and checkout.
For login endpoints, a threshold of 5 requests per minute per IP is reasonable. For general API endpoints, the right threshold depends on your legitimate usage patterns. Instrument your traffic first to understand the distribution before setting limits.
Layer 2: Vercel Middleware and Edge Functions
For applications deployed on Vercel, middleware runs at the edge before your page code executes. This is an ideal place to implement application-aware rate limiting.
Use an Upstash Redis edge-compatible store to track request counts per IP and user ID. Middleware can check and increment counters in sub-millisecond time at the edge without adding latency to legitimate requests.
```typescript
// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis/edge';
const ratelimit = new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(30, '1 m'),
});
export async function middleware(request: NextRequest) {
const ip = request.headers.get('x-forwarded-for') ?? '127.0.0.1';
const { success } = await ratelimit.limit(ip);
if (!success) {
return new NextResponse('Too Many Requests', { status: 429 });
}
return NextResponse.next();
}
```
Apply different rate limits to different route patterns. API routes warrant tighter limits than page routes. Authentication endpoints warrant the tightest limits of all.
Layer 3: Application-Level Controls
At the application layer, implement per-user rate limiting for authenticated endpoints. Per-IP rate limiting protects unauthenticated endpoints, but once a user is authenticated, rate limit by user ID to handle compromised accounts and API abuse.
For endpoints with high business value — checkout, account creation, data export — require CAPTCHA challenges when rate limiting thresholds are approached. This allows legitimate users to continue while stopping automated attacks.
Monitoring and Alerting
Configure alerts for rate limiting trigger rates. A sudden spike in 429 responses indicates an active attack. Investigating quickly lets you tighten rules before the attack causes user impact.
Cloudflare's analytics dashboard provides real-time visibility into traffic patterns, rule triggers, and threat scores. Review it during and after any incident to understand the attack vector and refine your rules.
Log all rate-limited requests with enough context to distinguish legitimate traffic being accidentally blocked from actual attacks. The worst outcome of rate limiting is blocking a real user in a high-intent moment.
Testing Your Protection
Test your rate limiting configuration in staging before applying it to production. Use tools like locust or k6 to simulate traffic patterns and verify that your thresholds behave as expected.
Test that legitimate high-volume use cases like batch API operations, authenticated bulk exports, and monitoring tools are properly excluded from the rate limits that protect your public endpoints. Legitimate automation needs to be able to work.
