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

  1. Vérifiez au moyen de preuves serveur assainies que l’en-tête Authorization atteint WordPress.
  2. Suivez chaque redirection et vérifiez la conservation du schéma, de l’hôte, du chemin et de l’en-tête Authorization.
  3. 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.
  4. Consignez les versions de WordPress, de l’extension, du client, du connecteur et du serveur avant toute modification.
  5. Utilisez un contrôle d’identité authentifié minimal pour confirmer l’utilisateur WordPress représenté par la requête.
  6. 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

  1. Configurez le chemin serveur ou proxy approuvé pour transmettre l’en-tête Authorization à WordPress.
  2. Ajustez seulement la règle, la route ou la méthode du faux positif confirmé au lieu de désactiver globalement la protection.
  3. Supprimez ou corrigez la redirection qui modifie la requête authentifiée de manière inattendue.
  4. Corrigez le point de terminaison, le transport, le nom d’outil ou la référence d’identifiant sans élargir les permissions WordPress.
  5. 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

Sources et vérification

Cette page a été vérifiée à partir des sources primaires suivantes. Dernière révision des sources: .