Next.js

@zarex/next fonctionne dans les route handlers et dans le fichier qui intercepte toutes les requêtes (proxy.ts à partir de Next.js 16, middleware.ts avant). Il n'utilise que les objets Request et Response standard.

InstallationCopier le lien de la section

npm install @zarex/next

Ajoutez votre clé dans .env.local (sans préfixe NEXT_PUBLIC_) :

ZAREX_KEY=zarex_test_...

Protéger un route handlerCopier le lien de la section

import { withZarex, shield, rateLimit } from "@zarex/next";

export const GET = withZarex(
  {
    key: process.env.ZAREX_KEY!,
    ipSource: "vercel",
    rules: [shield(), rateLimit({ max: 100, window: "1m" })],
  },
  async () => Response.json({ produits: [] })
);

Une requête refusée reçoit automatiquement 403, ou 429 avec Retry-After, sans que votre handler soit appelé.

Protéger toutes les routesCopier le lien de la section

import { NextResponse } from "next/server";
import { zarexNext, shield, rateLimit } from "@zarex/next";

const guard = zarexNext({
  key: process.env.ZAREX_KEY!,
  ipSource: "vercel",
  rules: [shield(), rateLimit({ max: 100, window: "1m" })],
});

export async function proxy(request: Request) {
  return (await guard(request)) ?? guard.finalize(NextResponse.next(), request);
}

guard(request) renvoie la réponse de refus, ou null si la requête peut continuer.

L'adresse IP du visiteurCopier le lien de la section

Next.js ne donne jamais l'adresse de la connexion : Zarex la lit dans un en-tête écrit par votre hébergeur ou par votre proxy.

Ailleurs, sans ipSource, l'application refuse de démarrer plutôt que de deviner.

En localCopier le lien de la section

next dev ne fournit aucun en-tête d'adresse : sans précaution, les requêtes passent sans être vérifiées (un avertissement l'indique dans les logs). Avec ipSource: { header: "x-real-ip" }, testez en ajoutant l'en-tête vous-même :

curl -H "X-Real-IP: 41.0.0.1" "http://localhost:3000/api/produits?id=1%27%20OR%20%271%27=%271"

Données de formulaireCopier le lien de la section

withZarex lit la requête avant votre handler : pour valider un e-mail, un téléphone ou un texte saisi dans un formulaire, utilisez plutôt createZarex et appelez protect vous-même, avec les données déjà lues.

"use server";
import { headers } from "next/headers";
import { createZarex, emailValidation, rateLimit } from "@zarex/next";

const zarex = createZarex({
  key: process.env.ZAREX_KEY!,
  ipSource: "vercel",
  rules: [rateLimit({ max: 5, window: "10m" }), emailValidation()],
});

export async function inscrire(email: string) {
  const h = await headers();
  const decision = await zarex.protect(
    { method: "POST", path: "/inscription", headers: h },
    { email }
  );
  if (decision.denied) return { ok: false };
  // … créer le compte
  return { ok: true };
}

Personnaliser le refusCopier le lien de la section

withZarex(
  {
    key: process.env.ZAREX_KEY!,
    rules: [shield()],
    onDeny: (request, decision) =>
      Response.json({ erreur: "Requête refusée", id: decision.id }, { status: 403 }),
  },
  handler
);

onDeny reçoit la décision complète et doit toujours renvoyer une Response : c'est elle qui est envoyée au visiteur à la place de votre handler. Si elle n'en renvoie pas (un return oublié, par exemple), le SDK envoie la réponse de refus par défaut et le signale dans vos logs : la requête reste bloquée (depuis la version 0.1.4). onDegraded(request, decision) est appelé quand Zarex n'a pas pu décider et que la requête a été laissée passer.

Pour aller plus loinCopier le lien de la section

• Toutes les options du SDK
• Toutes les protections