Erreur 403 sur WordPress : les deux causes possibles et leurs solutions

Ce que veut dire une erreur 403

La norme HTTP, la RFC 9110 publiée en juin 2022 par l'IETF, définit le code 403 en une phrase, section 15.5.4 : il indique que le serveur a compris la requête mais refuse de la satisfaire. Si des identifiants ont été fournis, le serveur les juge insuffisants, et le client ne devrait pas répéter automatiquement la requête avec les mêmes. La norme ajoute une nuance qui explique bien des confusions : un serveur qui veut « cacher » l'existence d'une ressource interdite peut répondre 404 à la place.

Sur un site WordPress, ce refus peut venir de deux endroits complètement séparés. Confondre les deux fait perdre des heures.

	403 du serveur	403 de WordPress
Message typique	« 403 Forbidden », « Access denied », « Vous n'avez pas la permission d'accéder à cette ressource »	« Désolé, vous n'avez pas l'autorisation d'accéder à cette page »
Apparence	Page brute, sans le style du site	Page grise de WordPress, avec un bouton de retour
Qui décide	Apache, nginx, LiteSpeed, mod_security, pare-feu de l'hébergeur	Le cœur de WordPress, après contrôle des capacités du compte
Où chercher	.htaccess, permissions, journaux du serveur, listes de blocage	Table usermeta, préfixe de table, extension de sécurité

Le 403 du serveur : qui vous refuse et pourquoi

Un fichier .htaccess cassé ou trop restrictif

Sur Apache, un fichier .htaccess modifie la configuration répertoire par répertoire. La documentation rappelle que ces fichiers sont lus à chaque requête et que leur portée dépend de la directive AllowOverride. Une directive mal formée, une règle de réécriture copiée depuis un forum, ou un Require all denied hérité d'un dossier parent produisent un refus net. Le module d'autorisation documente les deux formes de base, Require all granted et Require all denied.

Ce fichier est aussi la première cible des extensions de sécurité, des extensions de cache et des scripts malveillants, qui y ajoutent leurs blocs sans toujours les retirer.

Des permissions de fichiers incorrectes

Un fichier que le serveur web n'a pas le droit de lire, ou un dossier qu'il ne peut pas traverser, provoque un 403. La documentation WordPress recommande, sur un mutualisé en suexec, des dossiers en 755 ou 750 et des fichiers en 644 ou 640, avec une exception pour wp-config.php en 440 ou 400. Elle met en garde contre le 777 : un attaquant capable d'y déposer un fichier obtient un contrôle complet du site.

Les permissions dérapent surtout après une migration, une restauration faite en root, ou une manipulation en masse depuis un client FTP.

ModSecurity ou le pare-feu applicatif de l'hébergeur

ModSecurity est un pare-feu applicatif présent chez beaucoup d'hébergeurs mutualisés. Son manuel de référence décrit trois états pour le moteur de règles : On, où les règles sont appliquées et les actions de blocage exécutées, Off, où elles sont ignorées, et DetectionOnly, où elles sont évaluées sans rien bloquer. Une règle qui déclenche renvoie couramment un 403.

Les faux positifs classiques sont un article contenant du code, un formulaire à champ long, une importation de produits. Le symptôme est reconnaissable : la page d'administration se charge, puis l'enregistrement échoue en 403 alors que tout le reste fonctionne. Notre article sur les erreurs 403 causées par mod_security explique comment identifier la règle en cause.

Votre adresse IP est bloquée

Une extension de sécurité, un pare-feu applicatif ou l'hébergeur peuvent avoir mis votre adresse sur liste noire après plusieurs échecs de connexion. Le signe qui ne trompe pas : le site s'affiche depuis un téléphone en 4G, mais reste en 403 depuis votre bureau.

Un dossier sans page d'index

Quand un dossier ne contient pas de fichier d'index et que le listage est désactivé, le serveur répond 403 plutôt que d'exposer la liste des fichiers. Ce n'est pas une panne mais le comportement voulu : la vraie question est pourquoi une URL du site pointe vers un dossier.

Le 403 de WordPress : « Désolé, vous n'avez pas l'autorisation »

Ce message n'est pas une image ni un texte décoratif : c'est bien un vrai code HTTP 403, émis par WordPress lui-même. Dans le cœur, le fichier wp-admin/includes/menu.php contient exactement cette ligne, exécutée dès que la fonction user_can_access_admin_page() renvoie faux :

wp_die( __( 'Sorry, you are not allowed to access this page.' ), 403 );

WordPress a donc bien reconnu votre session, mais estime que votre compte n'a pas la capacité requise. Quatre causes expliquent presque tous les cas.

Le rôle ou les capacités de votre compte ont changé

WordPress ne stocke pas un « rôle » sur le compte mais une liste de capacités, dans la table usermeta, sous les clés wp_capabilities et wp_user_level. La documentation officielle rappelle que le rôle définit un ensemble de tâches autorisées et que l'administrateur d'un site simple les possède toutes ; la référence de current_user_can() déconseille de tester un rôle plutôt qu'une capacité, cette pratique pouvant produire des résultats peu fiables.

Une extension de gestion des rôles mal désinstallée, une importation de base partielle ou un script malveillant vident parfois ces deux clés : le compte existe, la connexion réussit, mais il ne peut plus rien faire.

Le préfixe de table ne correspond plus

Les clés de capacités portent le préfixe des tables. Si votre installation utilise wpc_, WordPress cherche wpc_capabilities et wpc_user_level. Après une migration ou un changement de préfixe fait à moitié, la constante $table_prefix de wp-config.php ne correspond plus aux clés présentes en base : WordPress ne trouve aucune capacité et refuse l'accès à tout le monde, y compris à l'administrateur d'origine.

Une extension de sécurité vous a exclu

Restriction par adresse IP, restriction par pays, limitation des rôles autorisés à voir l'administration, verrouillage après tentatives échouées : la plupart des extensions de sécurité savent produire ce message. Elles le font parfois après une simple mise à jour qui réinitialise leurs réglages.

Un jeton de sécurité expiré

WordPress protège ses actions par des jetons à durée de vie limitée. Une page d'administration laissée ouverte une journée, ou un cache qui sert une page d'administration à plusieurs utilisateurs, produisent un refus. Ici, se déconnecter puis se reconnecter suffit.

Diagnostic : dans quel ordre chercher

1. Lisez le message exact et regardez si la page porte le style de WordPress. C'est ce qui décide de la moitié à explorer.
2. Testez depuis un autre réseau, un téléphone en données mobiles : si le site répond, votre adresse IP est bloquée.
3. Testez une URL publique et une URL d'administration. Un 403 sur tout le site n'a pas la même cause qu'un 403 limité à wp-admin.
4. Renommez le fichier .htaccess en htaccess-hs et rechargez. Si l'erreur disparaît, la cause est dedans.
5. Consultez le journal d'erreurs : une règle ModSecurity y laisse une ligne avec son identifiant, ce qui suffit à la faire lever.
6. Désactivez les extensions en renommant wp-content/plugins, en particulier s'il s'agit du 403 de WordPress.
7. Vérifiez les capacités du compte en base si le message est celui de WordPress et que rien de ce qui précède n'a fonctionné.

Corriger un 403 côté serveur

Régénérer le fichier .htaccess

Renommez l'ancien, puis laissez WordPress en écrire un neuf en enregistrant les permaliens depuis Réglages. Si vous n'avez pas accès à l'administration, recréez à la main le bloc standard :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Tout ce qui figurait hors de ce bloc a été ajouté par une extension ou par quelqu'un d'autre : examinez-le avant de le remettre. Notre guide pour sécuriser le .htaccess indique les règles qui méritent d'être conservées.

Remettre des permissions correctes

En SSH, à la racine du site :

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.php

Vérifiez ensuite que le propriétaire des fichiers est bien l'utilisateur du site et non root, sinon le serveur web ne pourra toujours pas les lire. Le détail des valeurs et des cas particuliers est dans notre guide des permissions de fichiers et de dossiers WordPress.

Faire lever une règle du pare-feu

Ne désactivez pas ModSecurity dans son ensemble : c'est une protection réelle. Relevez l'identifiant de la règle dans le journal, puis demandez son exclusion pour votre seul domaine, ou pour la seule URL concernée. Beaucoup d'hébergeurs proposent ce réglage depuis leur panneau.

Débloquer une adresse IP

Cherchez votre adresse dans la liste de blocage de l'extension de sécurité, dans le panneau de l'hébergeur et dans le service de protection éventuel, puis ajoutez-la en liste d'autorisation si elle est fixe.

Corriger un 403 côté WordPress

Rendre les droits d'administrateur en base

Dans phpMyAdmin ou en ligne de commande, remplacez wp_ par votre préfixe réel et 1 par l'identifiant de votre compte :

SELECT meta_key, meta_value FROM wp_usermeta
  WHERE user_id = 1 AND meta_key IN ('wp_capabilities', 'wp_user_level');

UPDATE wp_usermeta SET meta_value = 'a:1:{s:13:"administrator";b:1;}'
  WHERE user_id = 1 AND meta_key = 'wp_capabilities';

UPDATE wp_usermeta SET meta_value = '10'
  WHERE user_id = 1 AND meta_key = 'wp_user_level';

Avec WP-CLI, plus court et moins risqué :

wp user list --field=user_login --role=administrator
wp user add-role 1 administrator
wp role reset administrator

Si vous avez perdu tout accès à l'administration, notre page backoffice perdu reprend les voies de récupération une par une.

Vérifier le préfixe de table

Comparez $table_prefix dans wp-config.php avec le préfixe réel des tables. Les deux doivent être identiques, et les clés de usermeta doivent porter ce même préfixe. C'est le premier contrôle après une migration.

Neutraliser l'extension de sécurité sans accès

Renommez son dossier dans wp-content/plugins : WordPress la désactive au chargement suivant, ce qui lève ses restrictions sans perdre ses réglages. Reconnectez-vous, corrigez la règle fautive, remettez le dossier. Pour savoir quel rôle doit voir quoi, voyez notre guide des rôles et permissions utilisateurs.

Quand un 403 est le signe d'une compromission

Trois situations doivent vous faire penser à une intrusion plutôt qu'à une panne :

• Vos droits d'administrateur ont disparu sans que personne n'ait touché aux comptes, et un autre compte administrateur que vous ne connaissez pas figure dans la liste.
• Un .htaccess a été réécrit avec des règles que vous n'avez pas posées, souvent dans wp-admin ou wp-content/uploads.
• Le 403 alterne avec des redirections vers un autre site, ou n'apparaît que pour certains visiteurs.

Rétablir l'accès ne suffit alors pas : tant que la porte d'entrée reste ouverte, le blocage reviendra. Notre service de suppression de virus WordPress traite les deux problèmes ensemble, le symptôme et la cause.

Éviter les 403 à l'avenir

• Gardez hors du serveur une copie du .htaccess qui fonctionne.
• Ne modifiez pas les permissions en masse depuis un client FTP sans savoir ce que vous changez.
• Conservez un second compte administrateur, avec une autre adresse de courriel et une authentification à deux facteurs.
• Notez le préfixe de vos tables : il coûte cher à retrouver dans l'urgence.
• Avant chaque migration, exportez la table usermeta à part.

Quand faire appel à nous

Un 403 qui résiste au .htaccess, aux permissions et à la désactivation des extensions demande un accès aux journaux du serveur et à la base. Sécurité WP répare des sites WordPress depuis 2016 : diagnostic gratuit sous 12 heures, réparation à prix fixe de 350 euros annoncée avant intervention et remboursée si elle échoue, site traité sous 48 heures. Notre page de correction de l'erreur 403 décrit l'intervention, et nous répondons au +33 7 56 81 94 38. Pour identifier une autre panne, partez du panorama des problèmes WordPress les plus fréquents.

Sources

• RFC 9110, HTTP Semantics, section 15.5.4 « 403 Forbidden », IETF, juin 2022.
• Code source de wp-admin/includes/menu.php, WordPress, consulté le 7 septembre 2026.
• Roles and Capabilities, documentation WordPress, mise à jour du 2 septembre 2026.
• Référence de current_user_can(), WordPress, 7 septembre 2026.
• Changing File Permissions, WordPress, 7 septembre 2026.
• Tutorial: .htaccess files et mod_authz_core, directive Require, Apache Software Foundation, 7 septembre 2026.
• ModSecurity Reference Manual v2.x, OWASP, 7 septembre 2026.