WordPress erreur 401 : corriger Unauthorized

Votre page publique s’ouvre, mais l’éditeur, /wp-json/ ou une intégration affiche soudainement 401 Unauthorized. Pour corriger une WordPress erreur 401, vérifiez d’abord l’identifiant envoyé, l’en-tête Authorization, les cookies de session et la protection HTTP placée devant le site. Le statut 401 signifie que la ressource demande une authentification valide, pas que WordPress est forcément en panne. Dans les 100 premiers mots, la réponse est donc simple : réauthentifiez-vous, identifiez la couche qui renvoie le code, puis testez une requête minimale avant de modifier un plugin ou le serveur.

Le symptôme mérite une méthode précise. Une erreur 401 sur une route privée n’a rien d’anormal sans identifiants. En revanche, un 401 sur une page publique, après une migration ou sur toutes les requêtes de l’éditeur, révèle souvent un cookie invalide, une règle Basic Auth, un mot de passe d’application mal utilisé ou un proxy qui ne transmet plus les en-têtes.

Que signifie exactement une WordPress erreur 401 ?

Le code HTTP 401 Unauthorized indique que la requête ne possède pas d’identifiants valides pour la ressource demandée. La norme HTTP prévoit généralement un en-tête WWW-Authenticate qui indique le mécanisme attendu. Le mot Unauthorized est donc parfois trompeur, car le problème se situe avant la vérification des droits. Une erreur 403 signifie plutôt que l’identité est connue, mais que l’accès est refusé.

Dans WordPress, plusieurs systèmes peuvent produire le même nombre. Le cœur vérifie un cookie de connexion ou un nonce. La REST API attend parfois une authentification pour une opération d’écriture. Apache, LiteSpeed, Nginx, un CDN ou un WAF peuvent demander une authentification distincte. Une extension de sécurité peut enfin intercepter la requête et renvoyer son propre JSON.

Deux indices chiffrés accélèrent le tri. Le statut 401 se distingue du 403 au niveau HTTP, et l’en-tête WWW-Authenticate est le premier élément à relever. Faites un seul test avec les en-têtes, le type de contenu et l’URL complète, sans publier de jeton dans un ticket ou un forum.

curl -sS -D - -o /tmp/reponse.txt 
  --max-time 20 
  'https://exemple.fr/wp-json/'

printf 'nRéponse :n'
head -c 800 /tmp/reponse.txt

Si le serveur renvoie une page HTML de connexion, la protection est probablement en amont de WordPress. Si la réponse est un objet JSON avec un code WordPress, inspectez la REST API, les cookies, les nonces et les extensions.

Commencer par le navigateur, les cookies et la session

Quand 401 apparaît dans wp-admin, rechargez la page puis reconnectez-vous. Testez ensuite la même action dans une fenêtre privée. Ce test ne répare rien, mais il sépare un problème de compte ou de serveur d’une session locale corrompue. Si la fenêtre privée fonctionne, supprimez uniquement les cookies du domaine WordPress, puis reconnectez-vous. Évitez d’effacer tout l’historique par automatisme.

Contrôlez aussi l’URL de connexion. Après une migration, le site peut alterner entre HTTP et HTTPS, avec ou sans www, ou entre deux domaines temporaires. Un cookie posé pour un ancien domaine ne sera pas envoyé au bon hôte. Les valeurs home et siteurl doivent correspondre à l’adresse réellement utilisée, y compris le protocole.

wp option get home
wp option get siteurl
wp user list --fields=ID,user_login,user_email,roles

Avec WP-CLI, lancez ces commandes depuis un compte de serveur autorisé. Ne copiez pas la sortie complète si elle contient une adresse privée. Si les deux URL sont correctes, vérifiez la date et l’heure du serveur. Un décalage important peut invalider une session ou un nonce, surtout derrière plusieurs serveurs.

Tester les identifiants et l’en-tête WWW-Authenticate

Inspectez la réponse avec curl -i. Cherchez le statut, WWW-Authenticate, Server, Content-Type et un éventuel identifiant de requête. Ne déduisez pas la cause à partir du seul message affiché par le navigateur. Une fenêtre « Authentication Required » vient souvent d’Apache ou de Nginx, tandis qu’un JSON rest_not_logged_in vient généralement de WordPress.

curl -i -sS --max-time 20 
  'https://exemple.fr/wp-json/wp/v2/users/me'

# Test de Basic Auth, uniquement sur un environnement autorisé
curl -i -sS --user 'utilisateur:mot-de-passe' 
  'https://exemple.fr/espace-protege/'

Ne placez jamais un vrai mot de passe dans l’historique d’un terminal partagé. Utilisez une variable temporaire, un gestionnaire de secrets ou un mot de passe d’application. Le second test ne sert qu’à diagnostiquer une protection HTTP que vous administrez. Il ne remplace pas l’authentification WordPress.

Si la réponse contient WWW-Authenticate: Basic, contrôlez le fichier de mots de passe et la règle qui protège le chemin. Si elle mentionne Bearer, vérifiez le jeton, sa date d’expiration et sa transmission par le proxy. Si aucun en-tête d’authentification n’est renvoyé, examinez les journaux et la réponse JSON du logiciel qui a généré le 401.

Corriger la REST API WordPress

La REST API est publique pour certaines lectures et protégée pour les opérations sensibles. Une requête GET vers une route publique ne devrait pas être testée avec les mêmes hypothèses qu’une création de contenu. Pour vérifier la base, comparez la racine REST, une liste publique et l’identité courante.

curl -i -sS 'https://exemple.fr/wp-json/'
curl -i -sS 'https://exemple.fr/wp-json/wp/v2/posts?per_page=1'
curl -i -sS 'https://exemple.fr/wp-json/wp/v2/users/me'

Dans wp-admin, une erreur 401 sur l’éditeur peut venir d’un cookie non transmis, d’un nonce expiré ou d’un changement de domaine. Rechargez l’éditeur après connexion. Vérifiez dans l’onglet Réseau que la requête part vers le même hôte et le même protocole que la page. Si le site utilise un CDN, désactivez uniquement la mise en cache de l’administration et des routes API selon la documentation du fournisseur.

Pour une intégration externe, les mots de passe d’application WordPress sont généralement plus sûrs qu’un mot de passe principal. Créez un secret dédié, limitez son usage à un service, stockez-le hors du dépôt, puis révoquez-le à la moindre suspicion. Une authentification réussie suivie d’un 403 indique ensuite un problème de capacité, pas un 401.

export WP_APP_PASSWORD='secret-temporaire'
export WP_USER='api-user'

curl -sS -u "$WP_USER:$WP_APP_PASSWORD" 
  'https://exemple.fr/wp-json/wp/v2/users/me'

unset WP_APP_PASSWORD WP_USER

Le mot de passe d’application ne doit pas être envoyé dans une URL. Utilisez HTTPS et vérifiez que le proxy conserve l’en-tête d’autorisation. Certains relais suppriment Authorization par défaut, ce qui transforme une requête correctement construite en 401 côté WordPress.

Vérifier Apache, LiteSpeed, Nginx, CDN et WAF

Un 401 produit avant WordPress se repère souvent à une page HTML standard, à un en-tête serveur différent ou à l’absence de traces dans debug.log. Contrôlez les règles de réécriture, les fichiers .htaccess, la configuration du reverse proxy et les règles de zone protégée. Une protection oubliée sur /wp-json/ peut casser l’éditeur, les applications mobiles et les outils de supervision.

Sur Apache ou LiteSpeed, cherchez les directives de type AuthType, Require valid-user et les inclusions héritées. Sur Nginx, contrôlez auth_basic, les blocs location et la transmission vers PHP. Le bon correctif est ciblé. Ne retirez pas toute l’authentification parce qu’une seule route est mal configurée.

# Exemple Nginx, à adapter puis à valider avant rechargement
location /wp-json/ {
    try_files $uri $uri/ /index.php?$args;
    proxy_set_header Authorization $http_authorization;
}

# Vérifier la configuration avant un rechargement
nginx -t

Un CDN ou un WAF peut aussi mettre en cache une réponse 401. Purgez uniquement la route concernée, puis contrôlez les règles de cache et les en-têtes transmis à l’origine. Si un fournisseur ajoute une authentification, documentez le chemin exact, le domaine et le mécanisme. Une protection d’aperçu ne doit pas toucher les pages publiques ni les robots si ce n’est pas volontaire.

Isoler une extension ou un thème sans exposer le site

Une extension de sécurité, de cache, de connexion sociale ou d’API peut intercepter l’authentification. Un changement récent est un indice, jamais une preuve. Utilisez le mode dépannage sur votre session d’administrateur lorsque c’est possible. Ce mécanisme évite de désactiver les extensions pour tous les visiteurs. Réactivez ensuite les composants un par un et reproduisez une seule action à chaque étape.

Si vous n’avez plus accès à wp-admin, WP-CLI permet de désactiver temporairement une extension depuis le serveur. Faites une sauvegarde et notez l’état initial avant l’opération. Ne renommez pas au hasard des dizaines de dossiers, car vous compliqueriez le retour arrière et le diagnostic.

wp plugin list --status=active --fields=name,status,version
wp plugin deactivate nom-du-plugin --skip-plugins --skip-themes
wp plugin activate nom-du-plugin --skip-plugins --skip-themes

Consultez ensuite les journaux du plugin et de WordPress. Activez la journalisation sans afficher les erreurs aux visiteurs. Si rien n’est écrit alors que le navigateur reçoit 401, la requête est probablement arrêtée par le serveur, le CDN ou le WAF avant d’atteindre PHP.

Ne pas confondre 401, 403, 404 et 500

Le diagnostic change selon le statut. 401 signifie qu’une authentification valide manque. 403 signifie que l’accès est interdit malgré une identité reconnue. 404 indique que la route ou la ressource n’est pas trouvée. 500 révèle une erreur interne. Une REST API qui passe de 401 à 403 après l’ajout d’un identifiant a progressé dans le diagnostic, même si l’accès n’est pas encore autorisé.

Pour une erreur 403 liée aux permissions, consultez notre guide REST API erreur 403. Si la route disparaît après une modification des permaliens, voyez le guide REST API erreur 404. Pour les problèmes de validation dans une requête authentifiée, WordPress erreur 422 donne une méthode complémentaire.

Cette comparaison évite les faux correctifs. Augmenter la mémoire PHP ne réparera pas un en-tête supprimé. Vider le cache ne donnera pas à un utilisateur une capacité absente. Modifier .htaccess ne corrigera pas un mot de passe d’application révoqué.

Checklist finale contre WordPress erreur 401

Commencez par noter l’URL, l’heure, le navigateur, le statut et l’en-tête WWW-Authenticate. Testez une fenêtre privée. Vérifiez home et siteurl. Comparez la page publique, /wp-json/ et la route qui échoue. Identifiez la couche qui répond. Contrôlez les cookies, les nonces, le mot de passe d’application et l’en-tête Authorization. Inspectez les règles du proxy, du CDN et du WAF. Isolez une extension en mode dépannage. Révoquez les secrets de test après le diagnostic.

Après correction, testez une lecture publique, une lecture privée et l’action réellement bloquée. Vérifiez les journaux, le cache et les intégrations. Si le support de l’hébergeur intervient, envoyez une heure UTC, une URL, les en-têtes non sensibles et un identifiant de requête. Ne transmettez ni cookie, ni mot de passe, ni jeton complet.

FAQ sur WordPress erreur 401

Pourquoi WordPress affiche-t-il 401 Unauthorized ?

La requête ne présente pas d’identifiants valides pour la ressource. La cause peut être un cookie expiré, un mot de passe incorrect, un jeton révoqué, une protection Basic Auth ou un en-tête supprimé par un proxy.

Comment corriger une erreur 401 dans la REST API ?

Comparez la racine REST et la route fautive, reconnectez-vous, vérifiez l’en-tête Authorization et utilisez un mot de passe d’application dédié pour une intégration. Contrôlez ensuite le CDN et les extensions.

Une erreur 401 vient-elle toujours de WordPress ?

Non. Apache, LiteSpeed, Nginx, un CDN ou un WAF peuvent répondre avant le cœur. Le type de contenu, l’en-tête serveur et la présence d’une trace dans les journaux permettent de distinguer les couches.

Quelle différence entre 401 et 403 ?

Le 401 indique qu’une authentification valide manque ou échoue. Le 403 indique que l’identité est connue, mais que la ressource refuse l’accès à cause des permissions ou d’une règle.

Faut-il désactiver le pare-feu pour corriger un 401 ?

Non. Identifiez d’abord la règle et créez, si nécessaire, une exception limitée à la route concernée. Une désactivation globale augmente le risque et masque la cause réelle.

Sources et références

• RFC 9110, définition officielle du statut HTTP 401
• MDN, référence HTTP 401 Unauthorized
• Documentation WordPress sur l’authentification REST API
• Documentation WordPress sur les mots de passe d’application
• Documentation officielle WordPress sur l’utilisation de la REST API
• Documentation Apache sur l’authentification et l’autorisation
• Documentation Nginx sur les en-têtes transmis au proxy