L’en-tête Authorization WordPress est absent ou supprimé
L’hébergement, le proxy inverse, une redirection ou le WAF supprime l’en-tête Authorization avant son arrivée dans WordPress.
Vérifiez au moyen de preuves serveur assainies que l’en-tête Authorization atteint WordPress.
Causes probables
- L’hébergement, le proxy inverse, une redirection ou le WAF supprime l’en-tête Authorization avant son arrivée dans WordPress.
- Un WAF ou une règle de sécurité bloque le chemin REST, la méthode, la charge utile ou le modèle d’authentification.
- Une redirection change le schéma, l’hôte ou le chemin et peut aussi supprimer les en-têtes d’authentification.
- Le proxy ne transmet pas l’information de schéma dont WordPress a besoin pour reconnaître HTTPS.
- Le client appelle le mauvais domaine, chemin de base, point de terminaison REST ou point de terminaison MCP.
Séquence de diagnostic
- Vérifiez au moyen de preuves serveur assainies que l’en-tête Authorization atteint WordPress.
- Suivez chaque redirection et vérifiez la conservation du schéma, de l’hôte, du chemin et de l’en-tête Authorization.
- Examinez l’événement exact du WAF ou de l’extension de sécurité, y compris la route, la méthode et l’identifiant de règle.
- Consignez les versions de WordPress, de l’extension, du client, du connecteur et du serveur avant toute modification.
- Utilisez un contrôle d’identité authentifié minimal pour confirmer l’utilisateur WordPress représenté par la requête.
- Confirmez le schéma, l’hôte, le chemin de base et le point de terminaison exacts configurés dans le client.
Appliquer le correctif minimal
- Configurez le chemin serveur ou proxy approuvé pour transmettre l’en-tête Authorization à WordPress.
- Ajustez seulement la règle, la route ou la méthode du faux positif confirmé au lieu de désactiver globalement la protection.
- Supprimez ou corrigez la redirection qui modifie la requête authentifiée de manière inattendue.
- Corrigez le point de terminaison, le transport, le nom d’outil ou la référence d’identifiant sans élargir les permissions WordPress.
- Transmettez des preuves assainies et versionnées au soutien lorsque le comportement demeure propre à l’extension.
Vérifier le résultat
- Les preuves serveur assainies confirment que l’en-tête Authorization atteint WordPress.
- La requête authentifiée correspond à l’utilisateur WordPress dédié prévu.
- La lecture étroite approuvée réussit avec une réponse reproductible.
- La requête authentifiée atteint le point de terminaison canonique sans redirection inattendue.
Ce qu’il ne faut pas faire
- Ne désactivez pas globalement le WAF ou l’extension de sécurité pour contourner une seule requête.
- Ne placez jamais un mot de passe d’application, un en-tête Authorization, un jeton ou un témoin dans une invite, un billet, un extrait de journal ou une capture.
- N’exposez pas publiquement les journaux de débogage ou les points de terminaison de diagnostic.
- N’ajoutez pas un contournement permanent et non vérifié du proxy avant de confirmer le chemin approuvé de la requête.
- N’accordez pas un accès administrateur uniquement pour réussir un test de connexion.
Guides connexes
- Un mot de passe d’application WordPress renvoie 401 Unauthorized
- Une extension de sécurité ou un WAF bloque l’API REST WordPress
- Boucle de redirection d’une connexion IA WordPress : contrôles HTTP, HTTPS et URL canonique
- Mots de passe d’application WordPress pour les connexions IA
- Résoudre les problèmes d’accès de Claude Code ou Codex à WordPress
Sources et vérification
Cette page a été vérifiée à partir des sources primaires suivantes. Dernière révision des sources: .
- Application Passwords · WordPress Developer Resources
- wp_authenticate_application_password() · WordPress Developer Resources
- RFC 9110: HTTP Semantics · RFC Editor
- REST API Handbook · WordPress Developer Resources