← Retour aux ressources
// technique · sécurité

Rate limiting et protection d’API

Sans limite, une API se fait marteler : brute-force sur le login, scraping, abus involontaire d'un client boguée, ou pic de coût sur tes appels LLM. Voici comment limiter proprement, sans gêner les vrais utilisateurs.

Technique27 juil. 2026~7 min · intermédiaire
rate limitingRedistoken bucketHTTP 429Next.js
// sommaire
01Pourquoi limiter02Le token bucket03Quoi limiter en priorité04Sans casser l’expérience05Sources & ressources
01

Pourquoi limiter

01
Brute-force

Sur le login, un attaquant teste des milliers de mots de passe. Limiter les tentatives casse l'attaque.

02
Scraping & abus

Un bot aspire tes données, ou un client boguée boucle. La limite protège tes ressources.

03
Coût LLM/API

Un endpoint qui appelle un LLM sans limite, c'est une facture ouverte. Un plafond par user la borne.

04
Équité

Un gros consommateur ne doit pas dégrader le service des autres. La limite garde le partage juste.

02

Le token bucket

L'algo le plus simple et le plus courant : chaque clé (IP ou user) a un compteur qui se remplit sur une fenêtre de temps. Au-delà de la limite, on renvoie un 429. Redis est parfait pour ça — atomique et partagé entre toutes tes instances.

rate-limit.tscopier
// token bucket avec Redis : simple, distribue, rapide
import { Redis } from "@upstash/redis";
const redis = Redis.fromEnv();
async function allow(key, limit, windowSec) {
  const count = await redis.incr(key);         // +1 sur la fenetre courante
  if (count === 1) await redis.expire(key, windowSec);
  return count <= limit;                         // false = on bloque
}
// dans une route : 10 requetes / 10s par IP
if (!(await allow(`rl:${ip}`, 10, 10))) {
  return new Response("Too Many Requests", { status: 429 });
}
!

Limite par user connecté quand tu peux, pas seulement par IP : derrière un NAT d'entreprise, des centaines d'utilisateurs partagent la même IP.

03

Quoi limiter en priorité

loginstrict : 5 tentatives / minute / IP + compte
signup / resetstrict : bloque la création de comptes en masse
endpoints coûteuxLLM, export, upload : plafond par user
API publiquequota par clé, avec en-têtes X-RateLimit-*
04

Sans casser l’expérience

renvoie un 429 clair avec un en-tête Retry-After, pas une erreur muette ;
des limites généreuses pour l'usage normal, serrées pour les routes sensibles ;
logue les blocages : un pic de 429 révèle une attaque ou un bug client ;
côté front, gère le 429 avec un backoff, pas une boucle de retry agressive.
i

Surveiller les 429, c'est de l'observabilité : je couvre logs et alertes dans monitoring : logs, alertes, uptime.

05

Sources & ressources

01MDN — 429 Too Many RequestsLa référence sur le code 429 et l’en-tête Retry-After qui l’accompagne.↗02MDN — Retry-AfterSyntaxe exacte de l’en-tête : delta en secondes ou date HTTP.↗03Redis — INCR : pattern rate limiterLe pattern INCR + EXPIRE, avec la race condition à corriger via un script Lua.↗04Upstash Ratelimit — algorithmesFixed window, sliding window et token bucket comparés, avec le SDK TypeScript.↗05Cloudflare — How we built rate limiting capable of scaling to millions of domainsPourquoi le sliding window : deux compteurs par clé, et ça tient des milliards de requêtes.↗06OWASP API Security Top 10 — API4:2023 Unrestricted Resource ConsumptionL’absence de limites vue comme une vulnérabilité, avec les contre-mesures recommandées.↗07Vercel — WAF Rate LimitingLimiter au bord avant même d’atteindre ton code : clés, fenêtres, action 429 ou challenge.↗

Le rate limiting est une des protections au meilleur rapport effort/gain : quelques lignes avec Redis, et tu fermes la porte au brute-force, au scraping et aux dérives de coût. Limite serré là où ça compte, généreux ailleurs, et rends toujours un 429 poli.