Une page WordPress refuse soudainement l’accès avec le message WordPress erreur 403 ou Forbidden alors que le site fonctionnait quelques minutes plus tôt. La correction la plus rapide consiste à identifier la couche qui refuse la requête, puis à contrôler les permissions, les règles du pare-feu, les cookies et le fichier .htaccess. Un code 403 signifie que le serveur a compris la demande mais refuse de l’autoriser. Il ne faut donc pas commencer par réinstaller WordPress ou vider toute la base de données.

Le blocage peut toucher uniquement /wp-admin/, une image, la REST API ou une seule adresse IP. Cette différence est décisive. Relevez l’URL exacte, l’heure, le navigateur utilisé et le statut renvoyé avant de modifier la configuration.

Que signifie exactement le code 403 Forbidden ?

Le statut HTTP 403 indique un refus d’autorisation. Contrairement au 404, la ressource peut exister. Contrairement au 401, le serveur ne demande pas nécessairement une authentification supplémentaire. Le refus peut venir d’Apache, de LiteSpeed, de Nginx, d’un CDN, d’un WAF, d’un plugin de sécurité ou du code WordPress.

Dans un site WordPress, le navigateur affiche parfois une page très courte, tandis que le journal du serveur donne le nom de la règle déclenchée. Un en-tête comme cf-ray, un identifiant de requête ou un message de ModSecurity permet de distinguer le proxy du serveur d’origine.

curl -sS -D /tmp/wp403-headers.txt -o /tmp/wp403-body.txt \
  --max-time 20 \
  'https://exemple.fr/chemin-qui-echoue'

printf 'Statut et indices :
'
grep -iE '^(HTTP/|server:|content-type:|location:|retry-after:|x-request-id:|cf-ray:)' /tmp/wp403-headers.txt
printf '
Début de la réponse :
'
head -c 800 /tmp/wp403-body.txt

Faites une seule requête de diagnostic, sans boucle rapide. Comparez ensuite une URL qui fonctionne avec celle qui est bloquée.

Commencer par déterminer qui renvoie le refus

Testez la même URL depuis une connexion mobile ou un autre réseau, uniquement si cela ne révèle aucune donnée privée. Si le 403 disparaît depuis une autre adresse IP, le WAF, le CDN ou une règle de limitation est probablement en cause. Si tous les réseaux obtiennent le même résultat, inspectez le serveur, WordPress et les permissions.

Regardez aussi le périmètre du problème. Une seule image bloquée évoque souvent un droit de fichier, une protection contre le hotlinking ou une règle sur l’extension. Tout /wp-admin/ bloqué évoque plutôt une règle de sécurité, un changement d’IP autorisée ou un fichier .htaccess corrompu. Une route /wp-json/ refusée demande un contrôle spécifique de la REST API.

Si le code apparaît juste après l’installation d’un plugin, passez par le mode dépannage ou désactivez temporairement le composant suspect. Ne désactivez pas simultanément la sécurité, le cache et le thème, sinon vous perdrez le signal utile.

Vérifier les permissions des fichiers et des dossiers

Sur un hébergement Linux classique, les dossiers WordPress sont généralement lisibles et traversables par le serveur web, tandis que les fichiers ne doivent pas être ouverts en écriture à tout le monde. Une base raisonnable est souvent 755 pour les dossiers et 644 pour les fichiers, mais l’utilisateur et le groupe du serveur restent propres à l’hébergeur.

# À lancer depuis la racine du site après sauvegarde
find . -type d -not -path './.git/*' -exec chmod 755 {} \;
find . -type f -not -path './.git/*' -exec chmod 644 {} \;
chmod 600 wp-config.php

N’exécutez pas cette commande aveuglément sur un serveur qui utilise des permissions particulières, un lien symbolique ou un déploiement partagé. Vérifiez d’abord l’utilisateur effectif du serveur, le propriétaire des fichiers et les règles de votre hébergeur.

stat -c '%A %U:%G %n' wp-admin index.php wp-config.php .htaccess
namei -l /chemin/absolu/vers/le/fichier-bloque

Un dossier parent sans permission de traversée peut produire 403 même si le fichier final possède un mode correct. À l’inverse, rendre toute l’arborescence accessible en écriture crée une faille et ne constitue pas un correctif.

Contrôler le fichier .htaccess sans casser le site

Une règle de refus mal placée est une cause fréquente après une migration, l’activation d’un plugin ou une modification manuelle. Sauvegardez le fichier, désactivez seulement la règle récemment ajoutée et testez. Dans WordPress, vous pouvez régénérer les règles de permaliens depuis Réglages, Permaliens, sans changer la structure, puis enregistrer une fois.

cp .htaccess .htaccess.bak-403
grep -nE 'Deny|Require|RewriteRule|RewriteCond|FilesMatch|Redirect' .htaccess

Sur Apache récent, les directives Require all denied, Deny from all ou une condition qui détecte mal un User Agent peuvent bloquer une page entière. Sur LiteSpeed, les règles Apache sont généralement reconnues, mais le cache et ModSecurity peuvent ajouter un second refus.

Ne remplacez pas un fichier complexe par un modèle trouvé au hasard. Vérifiez la documentation de votre hébergement et conservez la sauvegarde. Après chaque modification, testez la page publique, /wp-login.php et une route REST.

Examiner le WAF, ModSecurity et le CDN

Un pare-feu applicatif peut refuser une requête contenant un mot, un paramètre, un fichier ou un motif jugé dangereux. Les éditeurs, les appels REST et les formulaires sont particulièrement exposés. Le 403 arrive alors avant WordPress, ce qui explique pourquoi le journal WordPress reste vide.

Consultez le journal ModSecurity ou le tableau de bord du CDN avec l’heure exacte et l’identifiant de requête. Cherchez la règle déclenchée, puis créez une exception limitée à la route et au paramètre concernés. Désactiver complètement le WAF est un mauvais compromis, surtout pour une page de connexion ou une API.

curl -sS -o /dev/null -w 'HTTP %{http_code}
' \
  -H 'User-Agent: diagnostic-wp' \
  --max-time 20 'https://exemple.fr/wp-json/'

Répétez le test seulement après avoir modifié la règle. Si le 403 est lié à une adresse IP, vérifiez les listes de blocage, le proxy inverse et l’adresse réellement vue par le serveur. Une mauvaise configuration de REMOTE_ADDR peut faire croire au WAF que tous les visiteurs viennent de la même IP.

Corriger un wp-admin bloqué par un plugin

Les plugins de sécurité peuvent limiter une IP, masquer la connexion, bloquer des pays ou imposer une règle après plusieurs tentatives. Un changement de réseau peut alors déclencher un refus légitime du point de vue du plugin, mais gênant pour l’administrateur.

Si vous avez accès à l’administration, consultez les événements de sécurité et retirez uniquement le blocage correspondant. Sans accès, renommez temporairement le dossier du plugin suspect via le gestionnaire de fichiers ou WP CLI, puis rétablissez son nom après le test.

wp plugin list --status=active --fields=name,status,version
wp plugin deactivate plugin-suspect --skip-plugins --skip-themes
wp option get home
wp option get siteurl

Si aucune extension ne semble responsable, utilisez le mode dépannage avec un compte administrateur de test. Vérifiez aussi les mu plugins et le thème, qui peuvent appliquer une restriction sans apparaître dans la liste normale des plugins.

Résoudre une erreur 403 sur la REST API

Une REST API qui renvoie 403 n’est pas toujours une panne générale du site. Une route peut exiger une permission, un nonce ou une authentification que la requête ne fournit pas. Testez d’abord la racine puis la route précise, avec un compte de test et sans afficher de jeton.

curl -i -sS --max-time 20 'https://exemple.fr/wp-json/'
curl -i -sS --max-time 20 'https://exemple.fr/wp-json/wp/v2/posts?per_page=1'

Si la racine répond 200 et qu’une route privée répond 403, contrôlez le rôle, le nonce, les capacités et le plugin qui déclare la route. Si toutes les routes sont bloquées, inspectez le WAF, les permaliens et les règles serveur. Pour les différences entre authentification et permission, consultez nos guides sur l’erreur 401 de la REST API et l’erreur 404 de la REST API.

Cas des cookies, du hotlinking et des images

Un 403 sur une image ou une feuille de style peut venir d’une protection contre le hotlinking, d’un domaine non autorisé ou d’un cookie de session refusé. Vérifiez l’onglet Réseau du navigateur et la valeur de l’en-tête Referer. Pour un problème de connexion, notre guide WordPress erreur 403 liée aux cookies traite ce cas séparément.

Après une migration, contrôlez les URLs du site, le certificat, le domaine avec et sans www et les règles du CDN. Purgez uniquement le cache de l’asset concerné. Le fait de rendre le dossier uploads entièrement public ou d’autoriser tous les referers masque parfois le symptôme tout en élargissant inutilement l’exposition.

Lire les journaux et activer le debug avec prudence

Si le refus est généré par WordPress, le journal PHP ou debug.log peut révéler le plugin fautif. Activez le debug temporairement, sans afficher les erreurs aux visiteurs et sans laisser le fichier accessible.

// wp-config.php, temporairement en environnement contrôlé
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Reproduisez une seule fois, consultez le journal, puis désactivez le mode debug si le site est en production. Les logs peuvent contenir des URLs privées, des chemins et des données de requête. Traitez-les comme des informations sensibles.

Éviter les faux correctifs et sécuriser le retour à la normale

Réinstaller WordPress, désactiver tous les contrôles ou passer les permissions en 777 ne sont pas des méthodes de diagnostic. Elles peuvent supprimer la cause visible tout en créant une vulnérabilité ou en effaçant des indices. Préférez une sauvegarde, un changement isolé et un test mesuré.

Après correction, testez depuis deux réseaux, vérifiez la page publique, la connexion, une image, la REST API et l’action qui échouait. Contrôlez que le cache ne sert pas l’ancienne réponse 403. Notez la règle modifiée, l’heure et l’identifiant de l’incident dans la documentation du site.

Checklist rapide pour WordPress erreur 403

  • Noter l’URL, la méthode, l’heure et le réseau concernés.
  • Comparer les en-têtes d’une URL saine et de l’URL bloquée.
  • Identifier le serveur, le CDN, le WAF, le plugin ou WordPress comme émetteur.
  • Vérifier propriétaire, groupe, permissions et traversée des dossiers.
  • Contrôler .htaccess et les règles de permaliens après sauvegarde.
  • Examiner ModSecurity, les listes IP, les cookies et le hotlinking.
  • Tester la REST API avec une route publique et une route protégée.
  • Rejouer l’action une fois, puis surveiller les logs et le cache.

FAQ WordPress erreur 403

Pourquoi WordPress affiche-t-il Forbidden ?

Le serveur ou une couche de sécurité refuse l’autorisation de la requête. La cause peut être une permission, une règle .htaccess, un WAF, un plugin, un cookie ou une route REST protégée.

Comment corriger une erreur 403 sur wp-admin ?

Vérifiez d’abord le WAF et les plugins de sécurité, puis les permissions et les règles serveur. Faites une sauvegarde avant de renommer un plugin ou de modifier .htaccess.

Faut-il mettre les permissions WordPress en 777 ?

Non. Le mode 777 donne trop de droits et ne constitue pas un correctif sûr. Contrôlez le propriétaire, le groupe et les modes adaptés à votre hébergeur.

Pourquoi seule la REST API renvoie-t-elle 403 ?

La route peut exiger un nonce, un rôle ou une capacité absente. Si la racine répond 200, le cœur du site fonctionne probablement et le diagnostic doit viser la route ou le plugin concerné.

Un CDN peut-il créer une erreur 403 WordPress ?

Oui. Un CDN ou un WAF peut bloquer une IP, un paramètre, un referer ou un motif de requête avant que WordPress ne reçoive l’appel. Le journal du fournisseur permet d’identifier la règle.

Sources officielles

WP Admin Lab
· Chef de la rédaction

La rédaction de WP Admin Lab réunit des praticiens WordPress, sécurité et développement web. Nous publions des guides testés en conditions réelles, vérifiés en production et régulièrement mis à jour, sans jargon inutile. Chaque procédure est relue avant publication.

mastodon