How to Stop a DDoS Attack on Your Next.js App

Yes, you can stop a DDoS attack on a Next.js app: a recent flood that sent roughly 200,000 requests in 3 minutes at Loveyuu, a micro SaaS for couples, was absorbed by Vercel's built-in mitigation. This article explains how the attack unfolded, what kept the site up, and five route-level defenses worth adding.

What Happened: A 200k-Request DDoS Attack on a Next.js App

In November 2024, Loveyuu, a micro SaaS for couples built with Next.js, absorbed a bot-driven DDoS attack that generated roughly 200,000 requests in about 3 minutes. The developer, André Elias, discovered it only after opening his analytics dashboard, where a sharp spike of 'checkout created' events revealed that someone had automated calls to his checkout route in an attempt to take the service offline.

A distributed denial-of-service attack works by sending an overwhelming volume of requests to a target in a short window, hoping to exhaust the server and knock it offline. In this case the target was a single API route responsible for creating checkouts. No data was leaked, because the route only created checkout sessions and triggered an analytics event; it did not expose user information.

The incident is a useful case study for anyone shipping a small SaaS on a platform like Vercel, the deployment platform behind Next.js. The platform absorbed the blast, but the application code itself had no defenses. That gap is what the rest of this article addresses.

How the Attack Was Detected Without Any Alerts

The attack was found by hand, not by an alert. No email, monitoring notification, or incident page appeared; the developer simply opened the analytics dashboard to review conversion rates and saw an abnormal spike of checkout-created events. More than 200 API call events were registered during the short window.

This detection path matters because it reveals a common blind spot for solo founders. The attack metric was visible only in product analytics, not in an alerting system. If the spike had coincided with real traffic, it could have polluted conversion data or burned third-party API quota before anyone noticed.

The practical takeaway: tie an alert to your most sensitive events. A sudden volume of 'checkout created' or signup events is one of the cheapest early-warning signals a small SaaS can have, and it requires no new infrastructure beyond the analytics you already collect.

Why Vercel's DDoS Mitigation Kept the Site Online

The site stayed up, and the most likely reason is hosting-layer protection. Vercel, the platform serving the app, includes automatic DDoS mitigation, and the developer stated he was not certain but believed Vercel identified and blocked the abusive requests. The attack lasted only about 3 minutes.

Vercel also offers a manual Attack Challenge Mode that forces every visitor to pass a challenge, but it must be switched on by a human who is watching. In this incident nobody was online to enable it, so it played no role. Automatic mitigation did the heavy lifting; the manual mode is a break-glass tool, not a standing defense.

The honest caveat from the developer himself: he cannot prove with certainty that Vercel blocked the attack, only that the site never went down and the window was short. For a small product, that is still a strong argument for choosing a host with managed network-layer protection rather than a bare server you have to harden yourself.

Five Ways to Protect Your Next.js API Routes

Five defenses would have made this DDoS attack on a Next.js app far harder to execute, and all of them can be added incrementally. Ranked roughly from cheapest to most architectural, they are input validation, rate limiting, authentication, IP blocking, and a protective proxy in front of the app. Each addresses a different part of the problem: validation stops malformed abuse, rate limiting caps volume, authentication filters anonymous callers, and a proxy filters traffic before it ever reaches your code.

### Validate every input on server routes

The exposed checkout route performed no validation at all on the parameters it received, so any request, valid or not, executed the full handler and fired the checkout-created event. Validating fields with a schema library, or with built-in helpers from the Next.js route handlers documentation, rejects malformed traffic before expensive work happens.

The developer noted the limitation himself: validation is not perfect. An attacker can open the browser's network tab and replay exactly the fields a real request sends. Validation reduces noise and accidental breakage, but it cannot by itself distinguish a bot from a real user.

### Add rate limiting per identity

Rate limiting caps how many requests a single caller can make in a window, for example 10 requests per minute. When a caller exceeds the cap, the backend blocks further requests. A normal user of a couples app will rarely approach that ceiling, so aggressive overflow is a clear abuse signal.

The developer said rate limiting was at the top of his list to adopt. On serverless platforms a common pattern is a store-backed limiter such as @upstash/ratelimit, which counts requests per IP or per user token in a managed Redis-compatible store. It is one of the first topics covered in any systems-design course because it is simple and effective against exactly this kind of flood.

### Require authentication on sensitive routes

The checkout route accepted anonymous requests, which is why a bot could hammer it freely. Checking for a valid session or token before running the handler blocks unauthenticated traffic outright. If the caller has no valid session, the request is rejected before any database or payment work occurs.

There is a design tension here: some flows, like guest checkout, are legitimately public. When a route must stay open, pair it with rate limiting and validation instead. The developer's own SaaS template ships with authentication, a database, and payment integration through Stripe and Pix, precisely so these checks are present from the first line of code.

### Block abusive IPs and put a proxy in front

IP blocking works alongside rate limiting: once one address exceeds a threshold, it is denied entirely. It is a blunt instrument because attackers rotate addresses, but it removes the noisiest offenders cheaply.

The more durable option is a reverse proxy or middleware layer between the client and your server that filters suspicious traffic before it reaches your code. The developer named Cloudflare as the service people recommend most, citing its free plan, and said he plans to test it. He also expects these attacks to become more common for anyone with a visible, successful product on the internet.

Comparison of the Five Defenses

The five defenses differ in cost, scope, and what kind of attacker they stop. The table below compares them so you can decide what to add first to a small Next.js deployment.

Defense	What it stops	Effort	Limitation
Input validation	Malformed, junk requests	Low	Replay attacks with valid fields pass
Rate limiting	High-volume floods per caller	Low	Distributed bots spread across IPs
Authentication	All anonymous callers	Medium	Only works on routes that can require login
IP blocking	Repeat offenders	Low	Attackers rotate addresses
Proxy such as Cloudflare	Traffic before it reaches your app	Medium	Third-party dependency in the request path

For a solo founder, the order that emerged from this incident is practical: validate first, rate-limit second, and evaluate a proxy once the product has real traffic worth protecting.

Lessons for Small SaaS Founders

Three lessons stand out from this incident. First, platform-level mitigation is not optional: hosting on a provider with automatic DDoS protection is what kept Loveyuu online without anyone watching. Second, application-layer defenses still matter, because a flood that reaches your code burns analytics events, third-party quota, and your time even when nothing goes down.

Third, visibility is a feature. The attack surfaced only through an analytics spike, which means the developer was both the detector and the responder. Wiring a simple alert on sensitive event volume closes that gap for nearly zero cost.

The developer's closing attitude is worth keeping: no anger, just iteration. Building on the internet means exposure, and exposure means occasional abuse; treating each incident as a checklist item rather than a crisis is what keeps shipping sustainable.

FAQ

• What is a DDoS attack in simple terms? A distributed denial-of-service attack floods a website with far more requests than it can handle, usually using automated bots, with the goal of taking it offline. Defense combines network-level filtering at the hosting or proxy layer with application-level limits in your own code.

• Does Vercel protect against DDoS attacks automatically? Vercel includes automatic DDoS mitigation as part of its platform, and it also offers a manual Attack Challenge Mode you can enable during an active incident. In the Loveyuu incident, the developer believed the platform's automatic mitigation blocked the attack, though he could not confirm it with certainty.

• How do I rate limit an API route in Next.js? You check an identifier such as the request IP or a session token against a counter store, and reject requests once a caller exceeds a quota like 10 per minute. On serverless hosting, managed stores such as Upstash Redis are commonly used because serverless functions do not keep in-memory state between invocations.

• Was any data leaked in this attack? No. The targeted route only created checkout sessions and logged an analytics event, so the flood generated noise and event volume but did not expose user data.

• Is Cloudflare's free plan enough for a small SaaS? The developer cited community reports that Cloudflare's free plan is solid for basic proxying and attack filtering, and planned to test it himself. Exact suitability depends on your traffic and features you need, so evaluate it against your own requirements before relying on it.

From One Developer's Incident to Your Own Write-Ups

This whole article exists because one developer noticed a strange spike in his analytics and decided to turn a bad afternoon into a public lesson. If you have the same kind of knowledge sitting inside your own videos — whether it is an incident post-mortem recorded in 2024, a tutorial from 2025, or an interview — you can turn it into a written article without starting from a blank page. Visit Skala Blog, paste a YouTube URL, and the video is transcribed and shaped into a publishable article, so the lessons you talk about become lessons people can search for and read.

Source video