Rate limiting is one of those things that doesn't feel urgent—until someone hammers your login endpoint at 3am and you wake up to a flooded database and a locked-out user base.
I added this to my Nuxt base layer after realising I'd shipped several projects with zero protection on auth routes.
Not great.
This post walks through the exact setup I now use: Redis-backed, an in-memory fallback when Redis is down, named presets for different sensitivity levels, and a page that shows a live countdown instead of just dying on the user.
The structure Three pieces, each with one job: — a factory that builds the limiter, using Redis with an in-memory fallback — what you call inside handlers to enforce a limit — global middleware so every route gets a baseline for free
1.
Install does the heavy lifting: sliding windows, Redis integration, and the insurance fallback pattern we'll use.
2.
The factory Create : Two things I want to highlight here: Lazy initialization: the limiter builds itself on the first request, not at import time.
This avoids initialization-order problems in environments where configuration or services may not be ready when modules are first loaded.
Fail open: when Redis throws something unexpected, the request goes through.
I would rather have a temporarily unprotected endpoint than have a limiter bug take down the whole application for every user.
For an especially sensitive system, you may decide to fail closed instead.
3.
Presets Not all routes deserve the same treatment.
A page view and a password-reset request are very different risks.
Add named presets at the bottom of the same file: All limits are overridable through environment variables.
You do not need to change the application code to tighten them in production.
4.
The helper Create : The IP-resolution order matters when your Nuxt application is behind Cloudflare, nginx, or another reverse proxy. may contain only your proxy's IP, not the actual client's address.
The helper checks common forwarding headers in priority order and falls back to .
Only trust these headers when requests can reach your application through infrastructure you control.
Otherwise, clients may be able to spoof them.
The parameter lets you limit requests using something other than an IP address when necessary.
5.
Global middleware Create : Every route now gets a baseline limit without touching its individual handler.
Static assets and Nuxt internals are skipped.
Page limiting applies only to and requests.
6.
Layering limits on sensitive routes The global middleware is your floor.
For sensitive endpoints, stack a second, tighter limit on top.
Both limits count down independently, so a request has to pass both.
For password resets and similar endpoints, I key the limiter by email rather than IP.
An attacker can rotate IP addresses, but the target email remains the same: You can also combine the email address and IP: The correct key depends on what you are protecting.
7.
The page Inside , pull from the error data and show a countdown that reloads the page when it reaches zero: There is nothing else the user needs to do.
When the request window resets, the page reloads automatically.
8.
Environment variables Summary File Responsibility Factory and named presets Per-request enforcement, IP extraction, and headers Global baseline protection experience with countdown and automatic reload The defaults here are conservative.
Tune them according to your actual traffic.
The in-memory fallback means you can ship this before adding Redis and upgrade later without changing the API used throughout your application.
That is why I keep this implementation in my reusable Nuxt base layer: every new project starts with basic protection already available, instead of waiting until the first abusive request arrives.
I originally published this tutorial on my personal blog, where I write about Nuxt, TypeScript, infrastructure, and engineering decisions taken from real projects: Read the original Nuxt rate-limitin