WordPress erreur 403 cookies bloqués se corrige généralement en trois temps : supprimer les cookies du domaine, vérifier que l’URL WordPress utilise exactement le même protocole et le même domaine partout, puis désactiver temporairement la règle de sécurité ou le cache qui refuse la requête. Si le message « Les cookies sont bloqués ou non pris en charge » apparaît sur wp-login.php, testez d’abord une fenêtre privée. Si l’erreur 403 persiste, le blocage vient probablement du pare-feu, du fichier .htaccess ou d’un plugin de sécurité.

Ce guide distingue les deux problèmes souvent confondus : le cookie WordPress refusé par le navigateur et la réponse HTTP 403 Forbidden envoyée par le serveur. La méthode permet de récupérer l’accès à l’administration sans supprimer le site ni modifier la base de données à l’aveugle.

WordPress erreur 403 cookies bloqués : comprendre le symptôme

Une erreur 403 signifie que le serveur a compris la requête mais refuse de l’autoriser. Le navigateur reçoit donc une réponse différente d’une erreur 404, qui indique une ressource introuvable, ou d’une erreur 500, qui signale une panne côté application. Dans WordPress, le refus peut toucher /wp-admin/, /wp-login.php, l’API REST ou uniquement une action après la connexion.

Le message sur les cookies est un contrôle de sécurité de WordPress. Après l’envoi du formulaire, WordPress pose un cookie d’authentification. Si ce cookie n’est pas enregistré, n’est pas renvoyé ou est associé à un autre domaine, WordPress considère que la session n’est pas valide. La page de connexion réapparaît, parfois avec le message « Les cookies sont bloqués ou non pris en charge ».

Le diagnostic est important : vider les cookies ne réparera pas un WAF qui bloque votre adresse IP, et modifier wp-config.php ne réparera pas un cookie refusé par le navigateur. Commencez par le test le moins risqué, puis remontez vers la configuration du site et du serveur.

Étape 1 : tester le navigateur et supprimer les cookies WordPress

Ouvrez l’adresse https://votre-domaine.fr/wp-login.php dans une fenêtre privée. Cette action désactive les cookies existants et limite l’influence des extensions. Si la connexion fonctionne en navigation privée, le serveur répond correctement et le problème se trouve dans le profil normal du navigateur.

Dans Chrome ou Edge, ouvrez les paramètres de confidentialité, recherchez les données du site concerné, puis supprimez uniquement les cookies de votre domaine. Dans Firefox, cliquez sur le cadenas à gauche de l’adresse, ouvrez les cookies et les données du site, puis supprimez-les. Sur Safari, la gestion se trouve dans Réglages, Safari, Avancé, Données des sites.

Vérifiez aussi trois blocages fréquents : les cookies tiers désactivés alors que le site passe par un sous-domaine différent, une extension de confidentialité qui bloque wordpress_logged_in_, et une horloge système très décalée qui rend la session incohérente. Autorisez temporairement les cookies pour votre domaine, désactivez une extension à la fois, puis reconnectez-vous.

# Vérifier les en-têtes sans exposer vos identifiants
curl -I https://votre-domaine.fr/wp-login.php

# Suivre la redirection vers l'administration
curl -I -L https://votre-domaine.fr/wp-admin/

Une réponse 200 ou une redirection 302 vers la connexion est normale. Une réponse 403 dès la première requête confirme un refus serveur. Si la commande renvoie 200 mais que le navigateur affiche encore le message sur les cookies, concentrez-vous sur le domaine, le HTTPS et les extensions du navigateur.

Étape 2 : corriger l’URL WordPress, le HTTPS et le domaine

WordPress doit utiliser une URL cohérente dans home et siteurl. Les variantes suivantes ne sont pas équivalentes pour les cookies : http://exemple.fr, https://exemple.fr, https://www.exemple.fr et https://exemple.fr sans sous-domaine. Une migration, un certificat SSL récemment activé ou un proxy inverse peut laisser une ancienne valeur en base.

Si vous avez encore accès à WP-CLI, affichez les deux valeurs :

wp option get home
wp option get siteurl

# Exemple de correction, à adapter à votre domaine
wp option update home 'https://exemple.fr'
wp option update siteurl 'https://exemple.fr'

Sans accès à l’administration, ouvrez wp-config.php via FTP ou le gestionnaire de fichiers de votre hébergeur. Ajoutez temporairement ces constantes avant la ligne qui indique de ne plus modifier le fichier :

define( 'WP_HOME', 'https://exemple.fr' );
define( 'WP_SITEURL', 'https://exemple.fr' );

Remplacez le domaine par l’adresse réellement utilisée par vos visiteurs. Ne gardez pas une version avec www si le serveur redirige vers la version sans www. Après la correction, supprimez les anciens cookies, fermez tous les onglets du domaine et reconnectez-vous.

Un proxy comme Cloudflare peut également transmettre une requête HTTPS au serveur en HTTP. Dans ce cas, WordPress croit que la connexion n’est pas sécurisée et peut produire des redirections ou des cookies incompatibles. Si votre hébergeur utilise un proxy SSL, vérifiez la configuration du protocole transmis avant d’ajouter FORCE_SSL_ADMIN. Une constante HTTPS mal placée peut créer une boucle au lieu de résoudre le problème.

Étape 3 : identifier un fichier .htaccess ou un WAF responsable du 403

Si la fenêtre privée et les URLs sont correctes, examinez les règles du serveur. Une règle .htaccess qui interdit wp-login.php, une restriction par adresse IP ou un module de sécurité peut renvoyer 403 avant même que WordPress ne soit chargé.

Faites une sauvegarde du fichier, puis renommez temporairement le .htaccess de la racine en .htaccess.test. Testez uniquement la page de connexion. Si le 403 disparaît, le fichier contient la règle fautive. Ne laissez pas le site sans règles de réécriture : restaurez un fichier WordPress minimal après le test.

# .htaccess WordPress minimal sur Apache
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Un WAF peut aussi bloquer votre IP après plusieurs tentatives de connexion, une règle anti-bot trop stricte ou un formulaire contenant un mot jugé dangereux. Consultez les journaux dans cPanel, Cloudflare ou votre hébergeur. Cherchez l’heure exacte du test, le code 403, votre adresse IP et le nom de la règle déclenchée.

Pour confirmer le rôle d’un plugin de sécurité, désactivez temporairement les extensions sans passer par wp-admin. Via FTP, renommez wp-content/plugins en plugins.pause, testez la connexion, puis remettez immédiatement le nom original. Si l’accès revient, renommez le dossier, réactivez les plugins un par un et examinez les réglages de limitation d’IP, de protection de login et de blocage XML-RPC.

Cette procédure reprend le principe de diagnostic détaillé dans notre guide pour wp-admin qui ne fonctionne pas. Pour un écran qui devient blanc ou une erreur PHP après la connexion, consultez plutôt notre méthode pour corriger l’erreur critique WordPress.

Cas particulier : cookies, CDN, sous-domaines et reverse proxy

Les installations modernes empilent parfois plusieurs couches : navigateur, CDN, proxy, serveur web et WordPress. Un cookie posé pour www.exemple.fr ne sera pas nécessairement envoyé à exemple.fr. Un cookie marqué Secure ne sera pas envoyé sur HTTP. Un cookie avec un chemin trop restrictif ne sera pas envoyé à /wp-admin/.

Ouvrez les outils de développement du navigateur, onglet Application ou Stockage, puis Cookies. Après une tentative de connexion, cherchez les cookies wordpress_test_cookie et wordpress_logged_in_. Si le premier n’apparaît pas, le navigateur ou une politique de contenu empêche sa création. S’il apparaît puis disparaît immédiatement, vérifiez le domaine, le chemin, le HTTPS et la date d’expiration.

# Afficher les en-têtes de réponse et les cookies proposés
curl -s -D - -o /dev/null https://exemple.fr/wp-login.php | grep -iE 'HTTP/|location:|set-cookie:'

Ne copiez jamais une valeur de session complète dans un ticket public ou un forum. Les cookies d’authentification donnent potentiellement accès à votre compte. Pour un domaine multilingue ou une administration sur un sous-domaine, choisissez une seule URL canonique pour la connexion et vérifiez les redirections avant de tester.

Avec Cloudflare, commencez par passer temporairement le niveau de sécurité sur une valeur modérée, sans désactiver durablement la protection. Vérifiez ensuite les règles WAF personnalisées et les règles de défi JavaScript. Si le 403 apparaît uniquement derrière le CDN, l’origine WordPress n’est probablement pas responsable.

Réparer sans empirer : ordre d’intervention recommandé

La bonne méthode évite les modifications simultanées. Notez d’abord l’URL exacte, l’heure, le navigateur et le code HTTP. Faites une capture des en-têtes avec curl, puis testez en navigation privée. Cette séquence sépare rapidement un problème local d’un refus serveur.

  1. Tester /wp-login.php en fenêtre privée et depuis un autre réseau.
  2. Supprimer les cookies du seul domaine WordPress, puis autoriser temporairement les cookies.
  3. Comparer home, siteurl, le HTTPS et la présence de www.
  4. Contrôler le certificat, le proxy et les en-têtes Set-Cookie.
  5. Renommer temporairement .htaccess, puis les plugins, avec une sauvegarde.
  6. Lire les logs du serveur ou du WAF avant de modifier une règle de sécurité.

Ne supprimez pas la base de données, ne réinstallez pas WordPress et ne désactivez pas toutes les protections en production sans test. Une erreur 403 est souvent réversible en quelques minutes quand le diagnostic reste ciblé. Pour comprendre un refus qui s’accompagne d’une erreur de base de données, consultez aussi notre article sur l’erreur de connexion à la base de données WordPress.

Prévenir les erreurs 403 et les cookies refusés

Conservez une URL canonique, forcez le HTTPS au niveau du serveur et testez la connexion après chaque migration. Documentez les règles WAF et les adresses IP autorisées. Une restriction IP sur wp-admin est efficace, mais elle doit prévoir une méthode de récupération lorsque l’adresse du bureau change.

Évitez d’empiler plusieurs plugins de sécurité qui appliquent chacun une limite de tentatives. Activez la double authentification, utilisez un mot de passe unique et gardez une sauvegarde du fichier .htaccess. Testez régulièrement une session privée afin de repérer une régression avant qu’elle ne bloque toute l’équipe.

Le résultat attendu est simple : wp-login.php répond, le navigateur accepte wordpress_test_cookie, le formulaire crée une session et /wp-admin/ renvoie le tableau de bord. Si l’un de ces quatre points échoue, le code HTTP et les journaux indiquent généralement la couche à corriger.

FAQ : WordPress erreur 403 cookies bloqués

Pourquoi WordPress affiche-t-il « les cookies sont bloqués » ?

WordPress affiche ce message quand le cookie de test ou le cookie d’authentification n’est pas enregistré ou n’est pas renvoyé par le navigateur. Les causes les plus courantes sont des cookies supprimés par une extension, une URL avec HTTP au lieu de HTTPS, une différence entre www et le domaine nu, ou un proxy mal configuré.

Comment corriger une erreur 403 sur wp-login.php ?

Testez d’abord la page en navigation privée, puis contrôlez le fichier .htaccess, les plugins de sécurité et les règles du WAF. Une réponse 403 dans les en-têtes confirme un blocage serveur. Les journaux doivent ensuite préciser si le refus vient d’une restriction IP, d’un pare-feu ou d’une règle de réécriture.

Vider les cookies suffit-il à réparer une erreur 403 WordPress ?

Vider les cookies suffit uniquement lorsque le problème est limité à une session locale périmée ou à une extension du navigateur. Si le serveur renvoie 403 avant le chargement de WordPress, il faut corriger la règle .htaccess, le WAF, le CDN ou le plugin qui bloque la requête.

Comment vérifier que WordPress utilise la bonne URL ?

Affichez les options home et siteurl avec WP-CLI, ou contrôlez les constantes WP_HOME et WP_SITEURL dans wp-config.php. Les deux valeurs doivent utiliser le même domaine et le même protocole que l’adresse visible dans le navigateur.

Que faire si wp-admin reste bloqué après ces étapes ?

Renommez temporairement le dossier des plugins via FTP, restaurez un .htaccess WordPress minimal et consultez les logs du serveur. Si le 403 persiste sans plugin ni règle locale, demandez à l’hébergeur quelle règle WAF ou quelle restriction IP refuse votre adresse.

Sources

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.