403 sur Vercel : le pare-feu bloque wp-includes

Elementor ne s’initialise plus après une migration vers Vercel

Un 403 avec l’en-tête x-vercel-mitigated: deny sur /wp-includes/ après un export WordPress vers Vercel vient du pare-feu intégré de la plateforme, qui bloque par défaut les chemins historiquement ciblés par les attaques WordPress (wp-includes, wp-login.php, xmlrpc.php), même si le site n’a plus de backend PHP. Le correctif : renommer ces dossiers au build et réécrire les références dans le HTML.

Le symptôme est déroutant parce qu’il ne ressemble pas à une erreur de déploiement classique. Le site répond, les pages s’affichent, mais la mise en page est cassée : polices qui sautent, colonnes qui s’empilent, animations qui ne se déclenchent plus. Le client décrit souvent ça comme « le site sans CSS ». En réalité, une partie seulement des fichiers ne charge pas, et c’est suffisant pour qu’Elementor ne puisse plus initialiser ses scripts.

Rien de cassé côté build, rien de cassé côté DNS. Le blocage vient d’une couche de sécurité que Vercel active en amont de l’application, avant même que la requête n’atteigne les fichiers déployés. C’est un problème connu, documenté, et qui se corrige en quelques minutes une fois identifié.

Pourquoi ça arrive

• Un pare-feu managé cible les chemins WordPress par défaut. Vercel propose un template officiel qui bloque les URL classiques de scan automatisé : wp-admin, wp-login.php, xmlrpc.php, wp-content, wp-includes, wp-signup.php source : Vercel, Block WordPress URLs Firewall Rule. Ce template, ou une règle équivalente définie au niveau du compte, peut rester actif même sur un projet qui n’exécute plus de PHP.
• L’export statique conserve l’arborescence d’origine. Un export WordPress vers Vercel garde souvent les chemins physiques du thème et des plugins, dont Elementor, qui continuent d’appeler /wp-includes/hooks.min.js ou /wp-includes/i18n.min.js dans le HTML généré.
• La règle s’applique avant l’application. Une règle de type deny du WAF (Web Application Firewall) « renvoie un 403 Forbidden et arrête d’évaluer les autres règles : la requête n’atteint jamais l’application » source : Vercel, Protect Sensitive Routes with Vercel WAF. Le fichier existe pourtant bien dans le déploiement.
• Le blocage peut être invisible dans le dashboard. Des retours communautaires documentent des domaines de production bloqués par x-vercel-mitigated: deny sans aucune règle personnalisée visible dans l’interface source : Vercel Community, False Positive thread, ce qui suggère l’intervention d’un ruleset managé au niveau plateforme.
• Le WAF est activé par défaut, pas en option payante. Il est inclus dans le CDN de Vercel, ce qui explique qu’un projet migré rapidement sans audit de configuration hérite de règles pensées pour d’autres cas d’usage source : Vercel, Firewall-mitigated traffic is free.

Un WAF (Web Application Firewall) désigne une couche de filtrage placée devant l’application qui analyse chaque requête et peut la bloquer selon des règles prédéfinies ou personnalisées. Un export statique correspond à la conversion d’un site dynamique (ici WordPress/PHP) en fichiers HTML, CSS et JS fixes, sans exécution de code serveur au moment de la requête.

Ce cas illustre un piège plus large des migrations rapides : ce n’est pas parce qu’un site « build » sans erreur qu’il fonctionne en production. Sur ce point, la checklist de migration WordPress vers Astro couvre d’autres pièges similaires côté URLs et médias.

1. Confirmer que c’est bien le pare-feu, pas le build

Avant de toucher au code, vérifier l’origine exacte du blocage. Ouvrir les DevTools du navigateur, onglet Network, recharger la page et filtrer sur les requêtes en 403. Le détail qui confirme un blocage pare-feu plutôt qu’un fichier manquant : la présence de l’en-tête x-vercel-mitigated: deny dans la réponse. Un fichier réellement absent renverrait un 404, pas un 403 avec cet en-tête.

En ligne de commande, un simple curl -I https://votresite.com/wp-includes/hooks.min.js suffit à voir immédiatement le statut et les en-têtes sans passer par le navigateur.

2. Balayer systématiquement les assets bloqués

Un seul fichier en 403 peut cacher les trois ou quatre autres qui font le même effet cumulé sur la mise en page. Sur un projet migré chez Peechy le 15 mai 2026, quatre fichiers exactement renvoyaient ce 403 : hooks.min.js, i18n.min.js, wp-emoji-loader.min.js sous /wp-includes/, et classic-themes.min.css. Tout le contenu sous /wp-content/ passait sans problème, ce qui a d’abord fait penser à un souci de cache ou de CDN plutôt qu’à une règle de pare-feu ciblée sur un seul dossier.

Le plus efficace : lister toutes les URL d’assets référencées dans le HTML exporté (via un grep sur les fichiers .html ou un crawler léger), puis tester chacune avec curl -I. Toute occurrence de x-vercel-mitigated: deny va sur la liste à corriger.

3. Comprendre pourquoi précisément wp-includes est visé

Le chemin /wp-includes/ fait partie d’un groupe de routes historiquement exploitées pour des attaques automatisées sur WordPress : énumération d’utilisateurs, injection via xmlrpc.php, ou reconnaissance de version via des fichiers JS versionnés. Vercel documente une règle regex prête à l’emploi couvrant exactement ces chemins, wp-admin, wp-login.php, xmlrpc.php, wp-content, wp-includes entre autres source : Vercel, Firewall Terraform Configuration. Cette règle peut être définie une seule fois puis réutilisée sur plusieurs projets d’un même compte, ce qui explique qu’elle reste active même après une migration où le site n’a plus rien de dynamique.

4. Correctif rapide : une exception ciblée dans vercel.json

Depuis juillet 2025, Vercel permet de déclarer les règles de pare-feu directement dans vercel.json, de façon déclarative et versionnée avec le code source : Vercel, Web Application Firewall control now available with vercel.json. Ça permet d’ajouter une exception (system bypass rule) qui autorise précisément les quatre ou cinq chemins nécessaires à Elementor, sans désactiver toute la protection du WAF sur le reste du site. Les changements de règles se propagent en moins de 300 millisecondes, sans nouveau déploiement complet [source : Vercel, Web Application Firewall](https://vercel.com/security/web-application-firewall].

Ce correctif est rapide mais fragile : il faut le documenter, sinon la prochaine personne qui touche au projet ne comprendra pas pourquoi une règle censée protéger contre WordPress laisse justement passer des chemins WordPress.

5. Correctif durable : renommer et réécrire les références

La solution la plus propre reste de sortir complètement des chemins historiquement ciblés. Sur le projet du 15 mai 2026, le correctif retenu a été de renommer le dossier wp-includes en wp-inc au moment du build, puis de réécrire toutes les références correspondantes dans le HTML généré (scripts, feuilles de style, attributs src et href). Une fois ce renommage fait, plus aucune requête ne touche un chemin surveillé par le pare-feu, et la règle de blocage devient sans effet sur le site, sans qu’il soit nécessaire d’y toucher.

Cette approche demande un script de post-traitement au build (recherche-remplacement ciblée sur les chemins connus), mais elle évite toute dépendance à une exception de pare-feu qui pourrait disparaître lors d’un futur changement de configuration côté hébergeur.

6. Vérifier après déploiement

Une fois le correctif appliqué, repasser le même test qu’à l’étape 1 sur chacun des fichiers concernés : plus aucun 403, plus aucun x-vercel-mitigated: deny. Vérifier aussi visuellement que Elementor s’initialise (menus interactifs, animations au scroll) et que la CSS classique du thème charge correctement.

Pour aller plus loin sur le choix de la plateforme de déploiement elle-même, le comparatif Netlify ou Vercel détaille les différences de gestion du edge et des règles de sécurité entre les deux. Si le déploiement échoue plus largement, la checklist problème de déploiement Vercel couvre d’autres causes fréquentes.

FAQ

Quand passer la main à un pro

Ce type de blocage se règle en une session si on sait où chercher : l’en-tête x-vercel-mitigated: deny est le signal qui évite des heures à soupçonner le cache, le CDN ou le build. Mais dès qu’une migration touche plusieurs environnements, des règles de pare-feu personnalisées existantes, ou un export avec des centaines de références à réécrire, l’intervention manuelle devient risquée sans script de post-traitement fiabilisé et testé. Si le site reste cassé après ces six étapes, ou si la migration s’accompagne d’un changement d’hébergeur plus large, mieux vaut faire auditer l’ensemble par quelqu’un qui a déjà porté ce type de projet en production.