Comment mettre en place un WAF avec Vercel Firewall

Il n'y a rien à installer. Le pare-feu de Vercel est déjà devant votre déploiement, et il fonctionne en deux couches qu'il faut comprendre avant de toucher au moindre réglage :

• Pare-feu à l'échelle de la plateforme (automatique, gratuit, toutes offres) : assure une atténuation DDoS aux couches 3, 4 et 7. Il bloque les volumes de requêtes anormaux ou suspects sans aucune configuration et ne peut pas être désactivé.
• Vercel WAF (configurable) : la couche qui vous appartient. Vous y définissez le blocage d'IP, les règles personnalisées et, selon votre offre, les rulesets managés.

Le pare-feu évalue les règles dans un ordre d'exécution fixe : d'abord l'atténuation DDoS, puis le blocage d'IP du WAF, puis les règles personnalisées du WAF, puis les rulesets managés du WAF. Les règles personnalisées s'exécutent dans l'ordre où vous les disposez ; leur priorité compte donc, et vous pouvez les réordonner.

N'écrivez pas de règles de blocage à l'aveugle. Commencez par regarder le trafic réel afin que vos conditions correspondent à ce qui atteint réellement votre site.

1. Depuis votre tableau de bord, sélectionnez le projet à protéger.
2. Ouvrez Firewall dans la barre latérale du projet.
3. Utilisez la vue de surveillance du trafic et sa fenêtre de trafic en direct pour regrouper les requêtes par paramètre, par exemple par chemin, adresse IP, user agent, JA4 Digest ou pays. C'est la même surface d'observabilité que vous utiliserez pour valider chaque règle que vous écrirez.

Repérez les schémas sur lesquels vous voulez agir : l'IP ou l'ASN d'un scraper, un flot de requêtes vers un chemin d'API, des requêtes vers des fichiers qui ne devraient jamais exister comme .env ou .git, ou du trafic provenant de régions que vous ne desservez pas.

Le blocage d'IP est le contrôle WAF le plus simple et le plus prioritaire ; il s'exécute avant vos règles personnalisées. Utilisez-le pour les adresses malveillantes connues, les scrapers ou les concurrents, mais pas pour des restrictions géographiques (utilisez plutôt une règle personnalisée pour la géographie).

1. Dans Firewall, sélectionnez Configure en haut à droite.
2. Faites défiler jusqu'à la section IP Blocking et sélectionnez + Add IP.
3. Renseignez le champ IP Address Or CIDR et le champ Host. L'hôte est le domaine exact auquel le blocage s'applique, saisi sans le préfixe https, par exemple www.my-site.com. Ajoutez une entrée distincte pour chaque sous-domaine à couvrir.
4. Sélectionnez Create IP Block Rule, puis Review Changes et Publish.

Le blocage d'IP au niveau du projet est plafonné selon l'offre : jusqu'à 3 sur Hobby, jusqu'à 100 sur Pro et jusqu'à 1000 sur Enterprise. Enterprise propose aussi le blocage d'IP au niveau du compte depuis les Team Settings, où les règles CIDR sont limitées à /16 pour IPv4 et /48 pour IPv6.

Les règles personnalisées sont le cœur du Vercel WAF. Chaque règle se compose d'une ou plusieurs conditions If combinées par AND ou OR, plus une action Then. Construisez toujours une nouvelle règle d'abord en mode log pour qu'elle enregistre sans bloquer.

1. Dans Firewall, sélectionnez Configure, puis Add New... > Rule.
2. Nommez la règle de manière à ce que son but reste clair par la suite.
3. Ajoutez des conditions If. Les paramètres disponibles incluent Request Path et Target Path, Request Method, Hostname, IP Address, User Agent, Request Header, Cookie, Query, Geolocation (continent, pays, région, ville), AS Number et l'empreinte TLS JA4 Digest (JA3 est réservé à Enterprise). Les opérateurs incluent equals, not equals, contains, starts with, ends with, matches regex, exists et is in set, et tout opérateur peut être nié.
4. Réglez l'action Then sur Log.
5. Sélectionnez Save Rule, puis Review Changes et Publish.

Exemples d'objectifs que vous pouvez exprimer directement : refuser les requêtes dont le chemin se termine par .php, .env ou .git ; défier les requêtes dont le user agent contient curl ou wget ; ou refuser le trafic des pays que vous ne desservez pas.

C'est l'étape que la plupart des gens sautent et regrettent. La règle étant active en mode log, observez son comportement face au trafic réel avant de la laisser bloquer quoi que ce soit.

1. Sur la page de vue d'ensemble du pare-feu, sélectionnez votre règle dans la liste déroulante de regroupement du trafic et choisissez les paramètres liés à vos conditions.
2. Observez environ 10 minutes de trafic en direct. Confirmez que la règle correspond bien aux requêtes abusives visées et n'attrape pas d'utilisateurs légitimes.
3. Si l'ensemble des correspondances est incorrect, modifiez les conditions et observez de nouveau.
4. Une fois satisfait, sélectionnez Configure, ouvrez la règle et changez l'action Then en Challenge, Deny ou Bypass selon le cas. Enregistrez, révisez et publiez.

Sachez ce que fait chaque action : Deny renvoie 403 Forbidden et la requête n'atteint jamais votre application (et n'est pas facturée comme Edge Request ni comme Fast Data Transfer). Challenge sert un Vercel Security Checkpoint que seul un vrai navigateur capable d'exécuter du JavaScript peut franchir, créant une session d'une heure. Bypass laisse le trafic de confiance sauter les règles restantes.

La limitation de débit est une règle personnalisée dont l'action est Rate Limit. Utilisez-la pour plafonner les requêtes d'une même source vers un endpoint, ce qui protège les API et les formulaires de connexion et aide à maîtriser les coûts d'usage.

1. Créez une nouvelle règle et ajoutez des conditions If qui en délimitent la portée, par exemple Request Path commence par /api ou est égal à /auth/login.
2. Réglez l'action Then sur Rate Limit.
3. Choisissez la stratégie de limitation : Fixed Window (toutes offres) ou Token Bucket (Enterprise).
4. Définissez la Time Window (60 s par défaut) et la Request Limit (100 requêtes par fenêtre par défaut).
5. Choisissez la ou les clés de comptage : IP et JA4 Digest sont disponibles sur toutes les offres ; User Agent et les clés Header arbitraires sont réservés à Enterprise.
6. Choisissez l'action lorsque la limite est dépassée : conservez la réponse Default (429), ou sélectionnez Log, Deny ou Challenge. Enregistrez, révisez et publiez.

Les fenêtres vont d'un minimum de 10 s à un maximum de 10 minutes sur Hobby et Pro, et jusqu'à 1 heure sur Enterprise. Le nombre de règles de limitation de débit est plafonné par offre : 1 règle sur Hobby, 40 sur Pro et 1000 sur Enterprise.

Une règle deny ou challenge classique n'agit que sur les requêtes qui satisfont sa condition. Un client qui déclenche la règle une fois peut toujours envoyer d'autres requêtes qui ne correspondent pas. Les actions persistantes comblent cette faille en ajoutant un blocage d'IP à durée déterminée.

1. Modifiez (ou créez) une règle personnalisée dont l'action est Challenge, Deny ou Rate Limit.
2. Dans la ligne d'action, utilisez la liste déroulante de durée for (qui vaut 1 minute par défaut) pour choisir la durée de blocage du client fautif.
3. Enregistrez, révisez et publiez.

Lorsque la règle correspond, l'IP du client est stockée dans le pare-feu à l'échelle de la plateforme et bloquée pour la durée choisie. Comme ce blocage intervient avant que le pare-feu ne traite les requêtes suivantes, le trafic bloqué ne compte pas dans votre usage CDN et trafic. C'est idéal pour la protection contre le bruteforce, par exemple en limitant POST /auth/login à 10 requêtes par minute et par IP, puis en refusant pendant 15 minutes.

Les rulesets managés sont des collections prédéfinies que vous activez au lieu de les rédiger, et ils s'exécutent après vos règles personnalisées dans l'ordre d'exécution. L'OWASP Core Ruleset requiert Enterprise, tandis que le ruleset managé Bot Protection est disponible sur toutes les offres sans coût supplémentaire. La documentation de Vercel n'est pas parfaitement cohérente sur ce point (le tableau des limites du WAF indique toujours que les rulesets managés sont indisponibles sur Hobby et Pro, alors que l'annonce de disponibilité générale de Bot Protection dit toutes les offres), et le palier du ruleset AI Bots est moins clairement documenté, donc vérifiez ce que votre offre inclut avant de vous y fier.

• OWASP Core Ruleset : des règles fondées sur l'OWASP Top Ten. Activez l'ensemble complet, ou ouvrez Configure pour basculer des règles individuelles et régler chacune sur Log ou Deny.
• Bot Protection Managed Ruleset : inactif par défaut (affiché comme Off). Réglez-le sur Log ou Challenge ; en mode challenge, le WAF sert un défi JavaScript au trafic peu susceptible d'être un navigateur.
• AI Bots Managed Ruleset : inactif par défaut (affiché comme Allow). Réglez-le sur Log ou Deny pour surveiller ou bloquer le trafic identifié comme crawlers d'IA.

Activez et configurez ces éléments depuis Firewall > Rules dans la barre latérale du projet, puis révisez et publiez. Comme pour les règles personnalisées, démarrez chacun en Log et observez le trafic en direct avant de passer en Challenge ou Deny.

L'Attack Mode est un interrupteur d'urgence pour les attaques très ciblées. Une fois activé, chaque visiteur avec navigateur doit franchir un défi de sécurité avant d'atteindre votre site, tandis que les bots légitimes connus (moteurs de recherche, fournisseurs de webhooks) et votre propre trafic interne Function et Cron sont autorisés automatiquement.

1. Ouvrez Firewall dans la barre latérale du projet.
2. Cliquez sur Bot Management.
3. Sous Attack Mode, sélectionnez Enable.
4. Quand l'attaque se calme, revenez ici et sélectionnez Disable.

L'Attack Mode est gratuit sur toutes les offres, et les requêtes qu'il bloque ne comptent pas dans votre usage. Il ne nuit pas au référencement, puisque les crawlers comme Googlebot sont autorisés. Comme la plateforme atténue déjà le DDoS automatiquement, réservez l'Attack Mode aux incidents actifs et ciblés plutôt que de le laisser activé en permanence.

Les modifications dans le tableau de bord sont instantanées et ne requièrent aucun déploiement, mais vous pouvez aussi versionner les règles du pare-feu avec votre base de code. Dans vercel.json, utilisez la propriété routes avec des conditions has ou missing et une action mitigate :

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "routes": [
    {
      "src": "/(.*)",
      "has": [
        { "type": "header", "key": "x-react-router-prerender-data" }
      ],
      "mitigate": { "action": "deny" }
    }
  ]
}

Seules les actions challenge et deny sont prises en charge dans vercel.json ; les actions log, bypass et redirect ne sont disponibles que dans le tableau de bord. Notez le compromis : les règles vercel.json partent avec un déploiement, tandis que les règles du tableau de bord s'appliquent globalement en moins de 300 ms sans redéploiement. Pour une gestion scriptée ou pilotée par CI, l'API Firewall (via les exemples @vercel/sdk, avec la méthode vercel.security.updateFirewallConfig) permet de créer et de mettre à jour des règles par programmation.

Quelle que soit la voie choisie, vous pouvez récupérer vite : ouvrez le menu à points de suspension sur la vue d'ensemble du pare-feu, choisissez View Audit Log, sélectionnez une version antérieure par date et heure, et sélectionnez Restore pour revenir instantanément à cette configuration.