Erreur 403 WordPress sur un chemin public : retrouver la règle qui bloque

Confirmez que le chemin doit réellement être public

L’accueil fonctionne, mais une page, une image ou un téléchargement renvoie 403 Forbidden. Ce statut signifie que la requête a été comprise et refusée. Il ne prouve pas à lui seul qu’un fichier manque, qu’un mot de passe est faux ou qu’un pirate a été détecté. Le refus peut venir de l’application, du serveur ou d’une protection placée devant lui.

Commencez par nommer la ressource qui doit être accessible et à qui. Une page publiée destinée aux visiteurs ne se traite pas comme un export privé ou le dossier des fichiers techniques. Un répertoire peut volontairement refuser son affichage alors que les fichiers publics qu’il contient restent lisibles. Faire disparaître chaque 403 n’est donc pas un objectif suffisant.

Ce guide vise un chemin dont l’accès public a été confirmé par le responsable. Il propose trois parcours sans nouvelle extension : vérifier l’accès applicatif, réparer la configuration de service du chemin ou corriger une règle de sécurité précise. Si le refus touche uniquement une action administrative après connexion, poursuivez avec le guide des droits plutôt qu’en ouvrant ce chemin au public.

Préparez un relevé et un retour adaptés à l’intervention

Gardez une copie privée de l’adresse exacte, du message et de l’heure avec son fuseau. Retirez les jetons et les données personnelles de la version destinée au support. Notez la dernière modification connue : migration, ajout d’une règle, changement d’accès ou transfert de fichiers. Choisissez aussi un chemin public proche qui fonctionne ; il servira de comparaison.

La lecture d’une page n’exige pas de sauvegarde complète préalable. Avant de changer une règle ou une permission, relevez sa valeur et conservez le fichier concerné hors du répertoire public. Si une restauration plus large peut devenir nécessaire, vérifiez que la sauvegarde couvre fichiers et base, et comment préserver les données récentes.

Les procédures ci-dessous distinguent les accès : éditeur autorisé pour une page, compte d’hébergement pour un fichier, administrateur de sécurité pour le pare-feu. N’exécutez pas un parcours dont vous ne possédez pas l’accès prévu. Cela n’empêche pas de réaliser les observations dans votre navigateur puis de transmettre une demande ciblée.

Lisez la requête refusée dans le navigateur

Accès requis : un navigateur avec ses outils de développement, sans compte technique. Le résultat recherché est l’URL qui reçoit réellement 403. Une page affichée correctement peut contenir une image ou un appel d’API refusé ; corriger la page principale serait alors inutile. Ne reproduisez pas une commande ou un paiement pour obtenir cette preuve : observez la requête déjà enregistrée.

Si la lecture réussit en navigation privée mais échoue dans votre session, gardez cette différence pour le diagnostic. Ne supprimez pas tous les cookies à ce stade. Ce parcours est en lecture seule : fermez les outils pour revenir à votre affichage habituel.

1. Ouvrez la page concernée, puis les outils de développement par le menu du navigateur ou F12 selon votre appareil.
2. Sélectionnez Réseau, videz seulement la liste affichée des requêtes si nécessaire, puis rechargez une fois la page de lecture.
3. Repérez la ligne portant le statut 403. Ouvrez-la et relevez Request URL, Request Method et Status Code dans les en-têtes.
4. Notez la destination d’une éventuelle redirection et l’identifiant de requête affiché. Ne copiez pas Cookie ou Authorization.
5. Ouvrez le chemin témoin, puis comparez le même chemin refusé dans une fenêtre privée. Conservez les deux résultats.

Contrôlez une lecture avec curl si vous disposez d’un terminal

Ce contrôle facultatif convient à un lecteur qui possède déjà curl. Il ne nécessite ni SSH ni installation d’une extension. Sur une copie autorisée, remplacez l’adresse fictive par l’URL du chemin public de test, puis exécutez seulement la ligne correspondant à votre système. La commande effectue une lecture GET, affiche les en-têtes et jette le corps ; elle ne modifie pas les fichiers du site.

Le résultat attendu est une première ligne portant le statut HTTP. Si vous obtenez 301 ou 302, regardez Location avant de tester séparément cette destination connue. L’absence de suivi automatique aide à conserver le premier refus. curl et un navigateur peuvent être traités différemment par les protections : une divergence est un indice à transmettre, pas une preuve que le pare-feu doit être désactivé.

Cette commande ne reproduit pas un formulaire POST, une session connectée ou une validation JavaScript. N’y ajoutez pas de mot de passe ni de cookie copié. Gardez les en-têtes privés, notamment Set-Cookie. Aucun retour arrière n’est nécessaire ; si curl manque, utilisez le navigateur de la section précédente.

# macOS ou Linux : une seule lecture publique
curl -sS -D - -o /dev/null "https://site.example.test/guide-public/"
# Windows PowerShell : choisir cette ligne à la place
curl.exe -sS -D - -o NUL "https://site.example.test/guide-public/"

Choisissez l’un des trois parcours selon les preuves

Le premier parcours examine l’application lorsque le refus dépend d’un contenu, d’un statut public ou d’une route déclarée par un composant. Il convient notamment lorsqu’un administrateur peut afficher la ressource, mais pas les visiteurs. Confirmez le réglage attendu avant de toucher à une règle serveur.

Le deuxième parcours examine le serveur lorsque les journaux signalent un index absent, une permission de fichier, un propriétaire incorrect ou une règle d’accès. Il doit viser le chemin précis et la configuration réellement utilisée. Le fait que l’accueil fonctionne n’exclut pas une restriction héritée dans un sous-dossier.

Le troisième parcours traite un événement de sécurité corrélé à la requête légitime. Il demande d’identifier la règle et de réduire seulement sa portée erronée. L’attribution à une règle demande une preuve supplémentaire au-delà du seul statut 403. Si les preuves se contredisent, gardez le dossier d’observation et faites préciser la cause avant de combiner les trois types de modification.

Approche 1 : remettez une page dans sa visibilité autorisée

Choisissez ce parcours si une page précise est destinée à tous mais reste réservée à certains utilisateurs. Accès requis : droit de modifier et publier ce contenu. Le résultat attendu est la bonne page visible sans connexion, avec une réponse normale ; les états privés ou protégés ne renvoient pas toujours 403, d’où l’importance de confirmer le réglage réel.

Si la page est déjà publiée publiquement et reste refusée, ne changez pas son slug ni sa date. Passez au composant ou à la couche identifiée dans les journaux. Retour arrière : remettez le statut et la protection relevés avant l’essai, puis enregistrez. La publication ne doit concerner qu’un contenu dont l’ouverture est effectivement autorisée.

1. Ouvrez Pages, puis Toutes les pages, recherchez le titre et cliquez sur Modifier. Pour un article, utilisez Articles.
2. Dans l’éditeur à blocs, ouvrez les Réglages en haut à droite, puis l’onglet Page ou Article plutôt que Bloc.
3. Notez le statut actuel. Ouvrez Statut ; selon la version, ce groupe peut s’appeler État et visibilité. Choisissez l’état publié et public prévu, en retirant seulement une protection erronée.
4. Cliquez sur Enregistrer, Mettre à jour ou Publier selon l’état initial et confirmez si demandé. Avec l’éditeur classique, le réglage se trouve dans le bloc Publier, à côté de Visibilité.
5. Copiez le lien publié et ouvrez-le dans une fenêtre privée. Comparez le statut et le contenu avec le relevé initial.

Si un composant protège la page, corrigez sa règle plutôt que toute l’API

Une page publique peut rester bloquée par une règle d’adhésion, de téléchargement ou de sécurité ajoutée par un composant. Accès requis : ses réglages ou une copie de test administrable. Dans Extensions, puis Extensions installées, identifiez l’outil qui fournit réellement le chemin ; utilisez son lien Réglages et recherchez l’affectation de la page ou du contenu. Relevez la règle avant de modifier uniquement cette affectation.

Le résultat attendu est l’accès au contenu public choisi, tandis qu’un contenu réservé reste protégé. Si l’outil ne permet pas de limiter proprement ce changement, reproduisez sur une copie et utilisez sa documentation actuelle plutôt que de désactiver toutes les extensions en production. Remettez l’affectation d’origine si le refus persiste.

Pour une route REST, transmettez au mainteneur l’URL et la méthode relevées. Il doit corriger le client ou le contrôle de permission de cette route ; une page publique peut appeler une opération qui exige une identité. Remplacer tous les contrôles par une autorisation générale exposerait d’autres actions sans résoudre correctement la cause.

Approche 2 : retrouvez le dossier et réparez le point d’entrée prévu

Ce parcours convient lorsqu’un journal indique un index absent ou un dossier inattendu. Accès requis : le panneau du domaine et son gestionnaire de fichiers. Un dossier sans index peut refuser son listing tout en servant correctement ses fichiers publics. L’objectif est de servir la page prévue, sans activer l’affichage de tous les fichiers.

Résultat attendu : l’URL d’accueil ou de page atteint son vrai point d’entrée. Si le dossier appartient à une autre application, ne le remplacez pas : faites corriger l’association du domaine ou préparer le remplacement. Retour arrière : rétablissez le chemin de destination ou le seul fichier restauré, depuis sa copie privée.

1. Dans le panneau d’hébergement, ouvrez le domaine exact et relevez son dossier racine. Ne déduisez pas ce dossier depuis le nom public du site.
2. Ouvrez ce dossier dans le gestionnaire et cherchez le fichier d’index prévu, généralement index.php pour une installation WordPress standard.
3. Si l’index a disparu après une intervention identifiée, restaurez ce seul fichier depuis une sauvegarde fiable de la même installation. Pour une installation standard, une archive officielle correspondant à la version installée peut fournir l’original ; préservez tout fichier actuel avant remplacement.
4. Si le cœur est séparé dans un sous-dossier, utilisez sa procédure spécifique : l’index racine doit charger ce cœur. Ne copiez pas un index standard sans adapter son chemin.
5. Rouvrez le chemin dans le navigateur. Si seul le répertoire technique reste interdit mais les fichiers publics fonctionnent, conservez cette protection.

Corrigez les permissions d’un fichier public dans cPanel

Accès requis : cPanel et File Manager, sur des fichiers que vous êtes autorisé à gérer. Choisissez ce parcours si le journal confirme un problème de permissions après un transfert. Il ne répare ni une règle WAF ni un propriétaire incorrect. Sur un site déployé par Git ou un système automatisé, corrigez l’artefact ou la procédure de déploiement plutôt que son résultat à la main.

Exemple limité : une image publique est en 0600 alors que la politique de cet hébergement prévoit 0644 pour ce type de fichier, avec le bon propriétaire. Les valeurs attendues doivent être établies avant modification ; 0644 n’est pas une prescription pour tous les fichiers ou dossiers. Résultat attendu : cette image devient lisible par le serveur. Si cela échoue, remettez l’ancienne valeur et examinez propriétaire ou règle d’accès.

1. Dans cPanel, ouvrez Files, puis File Manager. Allez au dossier du fichier dont l’URL reçoit 403.
2. Sélectionnez uniquement ce fichier, puis Permissions dans la barre d’outils. Notez la valeur affichée.
3. Saisissez la valeur attendue par la configuration, par exemple 0644 dans le cas limité décrit, puis cliquez sur Change Permissions.
4. Rechargez l’URL exacte de l’image et contrôlez son statut. Ne vous contentez pas de l’aperçu dans le gestionnaire.
5. N’appliquez ni 777 ni une opération récursive. Pour annuler l’essai, sélectionnez le même fichier et remettez sa valeur relevée.

Vérifiez quelle règle du serveur protège le chemin

Si le journal d’Apache indique une restriction pour le PDF public, demandez au mainteneur autorisé de retrouver la règle effectivement appliquée à son dossier et à ce nom de fichier. Le fichier .htaccess est une source possible. Un réglage du serveur ou un outil de déploiement peut également produire le refus. Comparez le chemin résolu sur le disque et l’URL demandée. Relevez le fichier de configuration ou la source de déploiement et le contexte de la règle, sans republier une copie qui contiendrait des secrets.

L’équipe doit confirmer que le PDF est destiné au public et déterminer pourquoi la règle le classe dans le périmètre réservé. Sur une copie, elle peut corriger cette classification dans la configuration qui fait autorité, en gardant une version datée de l’état initial. Vérifiez que le document demandé redevient lisible et qu’un document voisin dont l’accès doit rester réservé conserve son contrôle. Si le résultat est différent, faites revenir la configuration à sa version de départ avant un nouvel essai.

Approche 3 : identifiez la règle Cloudflare qui a bloqué la lecture

Accès requis : consultation des événements de sécurité du domaine dans Cloudflare. Utilisez ce parcours si le site passe effectivement par ce service. Résultat attendu : une règle et une action associées à votre essai précis. Le statut ou le logo seul ne suffit pas. Certains refus précoces peuvent aussi échapper à cette vue ; conservez les journaux de l’origine pour compléter.

Cette consultation est en lecture seule et ne demande aucun retour de configuration. Si rien ne correspond, vérifiez période, domaine et filtres : des logs sont échantillonnés et les événements ne représentent pas toutes les requêtes. L’attribution reste à confirmer faute de ligne visible.

1. Sélectionnez le domaine concerné dans Cloudflare. Ouvrez Analytics, puis l’onglet Events selon l’interface actuelle.
2. Placez la période autour de l’heure relevée. Utilisez Add filter pour limiter au chemin, à l’hôte ou à l’identifiant disponible, puis Apply.
3. Ouvrez l’événement correspondant et relevez l’action, le produit, le ruleset et l’identifiant de règle.
4. Confirmez que le chemin, la méthode et le contexte correspondent à la lecture légitime. Une autre requête au même moment n’est pas une preuve.
5. Transmettez le relevé à l’équipe autorisée à modifier la règle. Elle peut confirmer sa portée avant de préparer une correction sur copie.

Faites corriger la règle trop large par l’équipe autorisée

Préparez un ticket avec l’URL publique, la méthode de lecture, l’heure avec fuseau et l’identifiant de la requête. Ajoutez l’événement corrélé, le produit qui l’a émis, l’action observée et l’identifiant de règle lorsqu’il est disponible. Indiquez qui a confirmé que la ressource est publique. Donnez un chemin témoin qui fonctionne et un chemin dont la protection doit rester active. Si le journal ne permet pas de relier le 403 à la règle, demandez d’abord à l’équipe de confirmer l’attribution.

Demandez au propriétaire de la configuration de vérifier l’intention et le périmètre de la règle. Pour une règle personnalisée, l’équipe peut corriger le critère qui inclut à tort une ressource publique. Pour une règle gérée, transmettez les éléments au responsable de la protection ou à l’éditeur pour faire qualifier le faux positif et choisir la correction prise en charge. Faites vérifier la modification sur copie avant toute décision d’application. Le contrôle doit couvrir le chemin public attendu et les ressources qui restent réservées.

Convenez du résultat à relire avec l’équipe : réponse normale sur le chemin public, contenu attendu, maintien du contrôle sur le chemin réservé et journaux cohérents. Gardez la configuration précédente dans le circuit de changements. Si un témoin échoue, l’équipe rétablit la dernière version validée et reprend l’attribution. Ce parcours permet de réparer la règle au niveau qui en est responsable.

Vérifiez la réponse actuelle avant de purger les caches

Après correction, distinguez une réponse nouvelle d’un ancien affichage. Rechargez dans une session adaptée, regardez le statut et la destination, puis demandez au prestataire s’il retrouve la nouvelle requête et son résultat. Un navigateur qui conserve une ancienne page n’apporte pas la même preuve qu’un refus encore produit par le serveur.

N’attribuez pas automatiquement un 403 au cache de Cloudflare : ce statut ne fait pas partie des réponses mises en cache par défaut. Des règles personnalisées ou d’autres couches peuvent toutefois modifier le comportement. Examinez la politique effective, les en-têtes et les caches présents avant de décider qu’une purge est utile.

Si une ancienne réponse est effectivement conservée, purgez le chemin ou la couche concernée, puis recommencez la même lecture. Une purge générale répétée ne répare pas une permission ou une règle qui refuse toujours la requête. Si seule une session connectée fonctionne, reprenez les différences de contexte et les règles d’accès au lieu de considérer la réparation comme acquise. Documentez le niveau auquel le résultat a changé.

Sur WordPress.com ou un réseau, utilisez les réglages disponibles

Sur WordPress.com, un administrateur peut ouvrir Réglages, puis Lecture et la section Visibilité du site. Notez l’état Public, Privé ou En préparation. Si le lancement public a été autorisé et que l’état est erroné, choisissez Public puis Enregistrer les modifications. Vérifiez ensuite une fenêtre privée. Pour revenir, remettez l’état relevé ; n’ouvrez pas un site confidentiel dans le seul but de retirer un message.

Ce réglage global ne répare pas nécessairement un fichier public isolé. Si seul celui-ci reçoit 403, transmettez sa requête au support de l’environnement géré. Les règles Apache ou Cloudflare ne sont modifiables que si vous gérez effectivement ces couches.

En multisite, précisez au super administrateur le site et le chemin concernés. Une règle du réseau peut dépasser votre périmètre. L’utilisateur qui peut modifier sa page conserve cette manipulation locale ; la modification d’une règle commune doit être réalisée dans le contexte réseau prévu.

Validez la correction et annulez seulement le changement fautif

Reprenez l’URL, la méthode et le contexte relevés au départ. Le succès consiste à obtenir le bon contenu pour le public voulu ; une redirection générale vers l’accueil ne remplace pas ce contenu. Pour un formulaire, utilisez un cas de test prévu qui ne déclenche pas de paiement ou d’envoi réel involontaire.

Si le contrôle échoue ou ouvre trop largement l’accès, remettez le statut WordPress, la permission ou le fichier initial, ou demandez au responsable de restaurer sa configuration précédente selon le parcours effectué. N’enchaînez pas d’autres modifications avant ce retour.

1. Ouvrez la ressource en visiteur déconnecté et vérifiez son statut dans Réseau.
2. Ouvrez le chemin public témoin et une ressource nécessaire à la page ; confirmez leur fonctionnement.
3. Avec le responsable, contrôlez un cas préparé qui doit rester protégé, sans chercher à afficher de vraies données privées.
4. Après correction d’une règle, retrouvez la nouvelle requête dans les journaux disponibles et confirmez le comportement attendu.
5. Conservez l’heure, le réglage changé et les résultats. Une restauration globale de base exige un plan distinct préservant les nouvelles commandes et inscriptions.

Quand les accès manquent, transmettez une demande exploitable

Fournissez au responsable le domaine, le chemin, la méthode, l’heure et l’identifiant de requête disponibles. Ajoutez le chemin témoin qui fonctionne et la différence observée entre visiteur et compte connecté. Demandez une vérification ciblée : propriétaire et permission du fichier, point d’entrée du dossier ou identifiant de règle déclenchée.

Cette escalade devient utile après les manipulations accessibles, ou lorsque les journaux et réglages nécessaires ne sont pas à votre disposition. Elle ne remplace pas la lecture de Réseau, le contrôle de visibilité ou la correction d’un fichier que vous pouvez réellement gérer. Envoyez seulement les extraits nettoyés dans le canal privé approprié.

Conservez ensuite le motif confirmé et sa correction. Si une règle ou une permission revient après chaque déploiement, corrigez sa source dans ce déploiement. Refaire le même ajustement manuel sans examiner ce qui le recrée laisserait la panne prête à revenir.

Reconstituez un refus à partir de deux journaux fictifs

Sur une copie, préparez trois chemins dont le rôle est connu. Dans la recette, /guide-public/ doit être lisible, /aide/ sert de témoin public et /guide-public/interne/ doit rester réservé. Relevez le premier statut HTTP de chaque lecture, puis cherchez l’événement correspondant dans le journal de la couche qui l’a produit. Ici, la référence REC-001 dans la réponse relie le premier 403 à la règle fictive REGLE-LECTURE-042. Le chemin réservé répond lui aussi 403, avec un événement applicatif différent. Les deux refus demandent donc deux décisions différentes.

Dans vos journaux autorisés, commencez par l’identifiant disponible, puis confirmez l’heure, l’hôte, la méthode et le chemin. Si le journal de protection a l’événement mais que la requête manque dans le journal de l’origine, elle a pu être bloquée avant d’atteindre le serveur. Vérifiez aussi la couverture de ces journaux avant de conclure. Un statut, un logo ou une ligne prise à la même minute ne désigne pas à lui seul la règle responsable. Sur le site en service, partez des requêtes déjà observées et des relevés existants.

Confirmez sur copie la correction et le contrôle qui reste actif

Dans la recette, la configuration fictive a été corrigée au niveau qui classait le chemin public à tort. Une lecture du même chemin a donné 200. Le témoin public a gardé sa réponse 200 et le chemin réservé est resté en 403 avec le même motif applicatif. Le rétablissement de la configuration initiale a reproduit le premier 403. Aucune règle d’un service réel n’a été modifiée.

Faites convenir de ces vérifications avant le changement. Le succès doit porter sur la réponse et le contenu légitime attendus, ainsi que sur le contrôle qui doit rester en place. Si la page s’ouvre mais que le témoin réservé devient visible, arrêtez l’essai et demandez le retour à la configuration conservée. Si les journaux ne concordent pas après modification, gardez les nouveaux identifiants et reprenez l’attribution avec l’équipe responsable.