Le code est défini par la RFC 9110, section 15.5.4 : contrairement à une erreur 401, s'identifier ne change rien, le refus tient à la ressource demandée ou à la requête elle-même.
Lire le journal d'erreurs d'abord
Le journal d'Apache donne la raison du refus, avec le chemin du fichier en cause. La documentation de Plesk sur le journal d'erreurs le place dans le gestionnaire de fichiers, dossier logs, fichier error_log. Plesk propose aussi, selon sa configuration, un écran Journaux sous le nom du domaine, qui permet de n'afficher que les erreurs ; les intitulés peuvent varier.
Les messages les plus courants se lisent ainsi :
| Message dans le journal | Cause probable |
|---|---|
| Permission denied | droits du fichier ou du dossier |
| Directory index forbidden by Options directive | aucune page d'index dans le dossier |
| client denied by server configuration | une règle de .htaccess |
| ModSecurity: Access denied | le pare-feu applicatif |
1. Vérifier les droits des fichiers et des dossiers
Le serveur doit pouvoir lire les fichiers et traverser les dossiers. Les valeurs habituelles, celles que recommande la documentation de WordPress sur les droits de fichiers, sont :
| Élément | Droits |
|---|---|
| dossiers | 755 |
| fichiers | 644 |
| .htaccess | 644 |
- Ouvrez le gestionnaire de fichiers de Plesk et placez-vous dans le dossier du site, httpdocs par défaut.
- Repérez la colonne des droits du fichier ou du dossier cité par le journal.
- Remettez 755 sur un dossier, 644 sur un fichier, puis rechargez la page.
Ne mettez jamais 777 pour « débloquer » : ces droits rendent le fichier modifiable par tous les processus du serveur, et ouvrent la porte à une prise de contrôle du site.
2. Vérifier la page d'index
Quand on demande un dossier, le serveur cherche une page d'accueil, index.php ou index.html. S'il n'en trouve pas et que l'affichage du contenu des dossiers est interdit, ce qui est le réglage sûr, il répond 403.
- Ouvrez le dossier httpdocs dans le gestionnaire de fichiers.
- Vérifiez qu'il contient index.php (WordPress) ou index.html.
- Si le site vient d'être transféré, vérifiez que ses fichiers sont bien dans httpdocs et non dans un sous-dossier, une erreur fréquente après un envoi de fichiers.
Pour mettre des fichiers au bon endroit, voir Mettre un site en ligne sur son hébergement.
3. Relire le fichier .htaccess
Les sites passent chez nous par nginx, devant Apache, et Apache lit les fichiers .htaccess. Une ligne Require all denied, Deny from all ou une liste d'adresses autorisées trop courte suffit à bloquer tout le monde.
- Téléchargez une copie du fichier .htaccess.
- Renommez-le en .htaccess_old sur le serveur.
- Rechargez le site. Si la page revient, une règle du fichier est en cause : remettez-le en place et retirez les lignes une à une.
Une extension de sécurité WordPress écrit souvent ses propres règles dans ce fichier. Désactivez-la si le 403 apparaît juste après un de ses réglages.
4. Le pare-feu applicatif
Toutes nos offres d'hébergement sont protégées par un pare-feu applicatif, ModSecurity avec le jeu de règles OWASP CRS. Il refuse en 403 une requête qui ressemble à une attaque : injection dans une adresse, en-tête interdit, robot connu. Il arrive qu'il se trompe sur une action légitime, par exemple un formulaire d'administration d'une extension.
Vous ne pouvez pas régler ce pare-feu vous-même. Notez l'heure exacte, l'adresse de la page et ce que vous faisiez, puis ouvrez une demande depuis votre espace client : le journal du pare-feu dit quelle règle a bloqué, et nous décidons s'il faut une exception.
5. Les autres causes
- Un service en amont refuse. Si votre domaine passe par Cloudflare, le 403 peut venir de ses règles et non du serveur : la page d'erreur porte alors le logo de Cloudflare.
- Le site est suspendu. Un abonnement suspendu pour impayé ne sert plus ses pages ; voir Impayé et suspension.
Questions fréquentes
Une erreur 403 peut-elle venir de mon navigateur ?
Rarement, mais un cookie abîmé ou une extension de navigateur qui modifie les requêtes peut déclencher le pare-feu. Essayez en navigation privée : si la page s'ouvre, videz les cookies du site.
Quelle différence entre une erreur 403 et une erreur 401 ?
La 401 demande une identification, et s'identifier peut lever le refus. La 403 refuse quoi qu'il arrive : le problème tient aux droits, à la configuration ou à la requête.
Mon site WordPress affiche 403 seulement dans l'administration, pourquoi ?
C'est le plus souvent une règle de sécurité, dans le .htaccess d'une extension ou dans le pare-feu applicatif, qui vise une action précise de l'administration. Notez l'heure et la page, puis écrivez-nous.
Articles liés
- Site inaccessible : que faire ?Site inaccessible ou qui ne s'affiche plus : savoir si la panne vient de vous, du domaine, du DNS, du certificat ou du serveur, et quoi faire.
- Erreur 500 : comprendre et corrigerErreur 500 Internal Server Error : ce que dit ce code, où lire le journal d'erreurs dans Plesk, et les causes à écarter, du .htaccess à la mémoire PHP.
- Erreur 503, 502 ou 504 : que faire ?Erreur 503 Service Unavailable, 502 Bad Gateway ou 504 Gateway Timeout : ce que dit chaque code, pourquoi un site les renvoie et comment trouver la cause.