Le code 401 Unauthorized signifie que la ressource exige une authentification et que la requête n’en apporte pas une qui soit acceptée. Le nom prête à confusion : il s’agit d’identifiants, pas d’un refus de permission une fois la personne reconnue. La spécification demande au serveur qui produit un 401 d’envoyer l’en-tête WWW-Authenticate, avec au moins un schéma (Basic, Bearer, Digest).
Un proxy qui exigerait ses propres identifiants répondrait 407 avec Proxy-Authenticate. Ce n’est pas le même cas.
Ce qui produit un 401
Les causes tiennent à la preuve d’identité, pas au fichier sur le disque.
- L’en-tête
Authorizationest absent. L’appel API part sans jeton, souvent après un copier-coller qui a oublié l’en-tête. - Le jeton Bearer ou JWT est expiré, révoqué, ou signé avec la mauvaise clé. Un décalage d’horloge de quelques minutes suffit à rejeter un jeton dont la date
nbfouexpest contrôlée. - Le Basic Auth du serveur (fichier htpasswd devant une préproduction ou un dossier) ne connaît pas l’utilisateur, ou le mot de passe a été régénéré.
- Un mot de passe d’application WordPress a été révoqué, alors que le script d’import l’utilise encore.
- Le cookie de session n’est pas envoyé : mauvais domaine, attribut
Securealors que la page est appelée en HTTP, ouSameSitequi bloque le cookie sur une navigation cross-site. La route protégée voit une requête anonyme et répond 401.
Un visiteur connecté dans le navigateur peut voir la page, pendant qu’un outil qui n’envoie pas le cookie reçoit 401. Les deux résultats sont cohérents.
Confirmer avant de changer les droits
Comparez trois requêtes vers la même URL.
- Sans aucun identifiant. Vous devez obtenir 401 et, dans les en-têtes,
WWW-Authenticate. - Avec les identifiants prévus (
Authorization: BasicouBearer). Un 200 indique que le contrôle d’identité fonctionne. - Depuis le navigateur où vous êtes connecté, puis dans une fenêtre privée. Si seule la session connectée passe, le problème est le cookie, pas le compte.
Le test d’URL montre le code vu de l’extérieur, sans le cookie de votre session d’administration. C’est le bon angle pour une page qui ne devrait pas exiger d’identifiant : un 401 public est alors une protection restée en place, pas une panne du contenu.
Regardez aussi l’horloge du serveur si seuls les jetons signés échouent. Un NTP arrêté fabrique des 401 en série juste après un redémarrage.
Corriger selon le canal
| Canal | Correction |
|---|---|
| API Bearer | Émettre un jeton neuf, vérifier l’issuer, la clé et l’heure du serveur |
| Basic Auth | Mettre à jour htpasswd et les mots de passe stockés dans les outils |
| Session web | Aligner le domaine du cookie, Secure et SameSite avec l’URL réelle |
| Mot de passe d’application | En créer un nouveau, révoquer l’ancien dans le profil |
| Page publique en 401 | Retirer la règle qui protège l’URL, pas le compte du visiteur |
Après correction, refaites la requête sans identifiant si la page doit être publique, et avec identifiant si elle doit rester fermée. Les deux contrôles ont un résultat attendu différent.
Ce qu’il ne faut pas faire
Ne traitez pas un 401 comme un problème de permissions de fichiers. Changer un dossier en écriture ouverte ne fournit pas l’en-tête Authorization manquant. Ne désactivez pas l’authentification de toute l’API pour « débloquer » un script. Ne confondez pas avec un 403 : si WWW-Authenticate est présent et que des identifiants neufs rétablissent l’accès, vous étiez bien sur un échec d’identité.
Une page qui répond 401 alors qu’elle est liée depuis le site public empêche aussi l’exploration de cette URL. Vérifiez le périmètre réel avec la même méthode que pour tester si un site répond vraiment : code, URL finale, et présence ou absence attendue d’une demande d’identifiants.