Comment gérer les erreurs 403 sur votre hébergement N0C

Introduction

Une erreur 403 signifie que l’accès à une page ou à une ressource de votre site web est interdit. Elle peut survenir pour différentes raisons. Mais rassurez-vous : il est généralement possible de la corriger rapidement.

Dans cet article, nous allons vous montrer comment diagnostiquer et résoudre une erreur 403. Nous emploierons des outils disponibles dans votre panneau de contrôle N0C.

Note : Le glossaire contient  des explications sur de multiples sujets et peut être consulté pour clarifier certains termes.

Prérequis

Saisissez dans votre navigateur Web l’adresse suivante : https://mg.n0c.com/fr/.

Causes possibles d’erreurs 403

Après avoir compris ce qu’est une erreur 403, il est utile d’identifier les causes les plus fréquentes. Cela permet de cibler plus rapidement la source du problème et de choisir les bonnes actions correctives.

• Pare-feu applicatif (WAF). Le WAF peut bloquer certaines requêtes en fonction de règles de sécurité comme des chemins suspects, des comportements anormaux ou des signatures connues d’attaques.
• Permissions de fichiers. Des permissions incorrectes peuvent empêcher l’accès à certains fichiers ou dossiers de votre site.
• Fichiers .htaccess. Une mauvaise configuration ou une règle restrictive dans ces fichiers peut bloquer l’accès à certaines ressources.
• Fonctions logicielles. Une mauvaise utilisation des en-têtes HTTP dans votre code peut également provoquer une erreur 403.
• CSF (ConfigServer Security & Firewall). Ce pare-feu serveur peut bloquer des requêtes selon divers critères (IP, user-agent, etc.).

Pare-feu applicatif (WAF)

Le WAF (Web Application Firewall) protège votre site en bloquant automatiquement les requêtes malveillantes, comme les tentatives d’injection SQL ou de tests d’intrusion (pentesting). Il filtre les requêtes avant qu’elles n’atteignent votre application.

Cependant, il existe des règles qui peuvent parfois bloquer des actions légitimes, notamment avec certains plugins ou modules de CMS comme WordPress ou PrestaShop. Cela peut entraîner des erreurs 403 que l’on qualifie de « faux-positifs ».

Dans ce cas, les outils disponibles dans votre panneau N0C permettent de diagnostiquer précisément la règle en cause et de l’ajuster au besoin, tout en maintenant une bonne sécurité globale.

Marche à suivre

Étape 1 – Générez une erreur 403

Essayez de reproduire l’erreur 403 sur votre site ou votre interface d’administration (ex. : accédez à une page spécifique ou utilisez une fonctionnalité qui déclenche le blocage). Cela permettra de créer une entrée dans les journaux du pare-feu.

Étape 2 – Notez les informations importantes

Immédiatement après avoir reproduit l’erreur, relevez les informations suivantes :

• Date et heure précises, en incluant le fuseau horaire.
• Adresse IP publique, que vous pouvez trouver via votreip.org.

Ces données vous permettront de retrouver plus facilement l’événement exact correspondant dans les journaux.

Étape 3 – Identifiez les blocages via le journal du pare-feu (WAF)

Les journaux du pare-feu sont accessibles depuis votre interface N0C. Ils vous permettent de trouver les règles qui ont provoqué un blocage, souvent liées aux interfaces sensibles comme les back-offices. Veuillez vous référer à l’article Comment configurer le bastion d’application web (WAF) et consulter l’historique du pare-feu pour plus de détails.

Accédez à Sécurité -> Historique de protection du pare-feu. Vous y trouverez le détail de l’événement bloqué : l’URL en cause, le type de requête, l’adresse IP source de l’erreur, et surtout l’ID de la règle ayant déclenché la protection.

Important – Vérifiez bien l’IP source du blocage.

Avant de modifier ou de désactiver une règle WAF, assurez-vous que la requête bloquée provient bien de votre propre adresse IP et non d’un tiers.

Il est courant que des attaques automatisées — au moyen d’analyseurs (scanners), de robots (bots), ou encore de tentatives d’exploitation — génèrent des erreurs 403. Débloquer une règle sans vérifier l’IP source peut réduire dangereusement la sécurité de votre site en autorisant des comportements réellement malveillants.

Rappel : tout site web en ligne est constamment soumis à des tentatives d’attaque, même s’il ne présente aucun symptôme visible. Soyez donc vigilant dans l’interprétation des journaux du pare-feu.

Étape 4 – Ajustez les règles de sécurité

Une fois la règle problématique déterminée, vous pouvez la désactiver individuellement.

Pour ce faire, rendez-vous dans : Sécurité -> Pare-feu applicatif Web (WAF) -> Personnaliser les règles

Recherchez la règle par son ID, puis désactivez-la si elle bloque une action légitime de votre site. Il est recommandé de ne désactiver que les règles strictement nécessaires afin de conserver un bon niveau de protection.

Pour plus d’informations, consultez notre article dédié à ce propos : Comment configurer le bastion d’application web (WAF) et consulter l’historique du pare-feu.

Permissions de fichiers

Les erreurs 403 peuvent également être causées par des permissions incorrectes sur les fichiers ou dossiers de votre site. Voici comment diagnostiquer et corriger ce type de problème à l’aide de votre interface N0C.

Étape 1 – Identifiez une erreur 403 liée aux permissions

Dans le navigateur, un message d’erreur comme : « Vous n’êtes pas autorisé à accéder à cette ressource » ou « Le serveur ne peut pas lire le fichier .htaccess, l’accès est refusé par mesure de sécurité » peut indiquer un problème de permissions.

Étape 2 – Faites la différence avec un blocage WAF

Ce type d’erreur n’apparaît pas dans les journaux du WAF, mais uniquement dans les journaux d’accès. Cela permet de confirmer qu’il ne s’agit pas d’un faux positif WAF.

• Journal d’accès : Domaines -> Journal d’accès.
• Journal WAF (à titre comparatif) : Sécurité -> Historique de protection du pare-feu.

Étape 3 – Vérifiez les permissions dans le Gestionnaire de fichiers

Tel qu’expliqué dans l’article Comment utiliser le Gestionnaire de fichiers, ouvrez le Gestionnaire de fichiers depuis Fichiers -> Gestionnaire de fichiers.

Inspectez les permissions du fichier ou du dossier en cause, ainsi que celles de ses dossiers parents.

• Les dossiers contenant des exécutables (comme public_html, wp-content, etc.) doivent généralement avoir les permissions 755.
• Les fichiers (comme .php, .html, .htaccess, etc.) doivent avoir les permissions 644.

Étape 4 – Corrigez les permissions

Dans le Gestionnaire de fichiers :

1. Faites un clic droit sur le fichier ou dossier problématique.
2. Sélectionnez Permissions.
3. Corrigez les valeurs si nécessaire (par exemple 644 pour un fichier, 755 pour un dossier).

Une fois les permissions ajustées, rechargez votre site pour vérifier si l’erreur 403 a été résolue.

Fichiers .htaccess

Une erreur 403 peut également être provoquée par une mauvaise configuration dans un fichier .htaccess. Ces fichiers sont très puissants, mais une simple directive incorrecte peut entraîner le blocage involontaire de certaines ressources ou de visiteurs.

Étape 1 – Identifiez une erreur 403 liée à .htaccess

Le message affiché dans le navigateur sera généralement similaire à : « Interdit – Vous n’êtes pas autorisé à accéder à cette ressource ».

Étape 2 – Différenciez d’un blocage WAF

Comme pour les erreurs de permissions, ce type d’erreur n’apparaît que dans les journaux d’accès, non pas dans les journaux du WAF.

• Journal d’accès : Domaines -> Journal d’accès.
• Journal WAF : Sécurité -> Historique de protection du pare-feu.

Étape 3 – Vérifiez tous les fichiers .htaccess en cause

Utilisez le Gestionnaire de fichiers : Fichiers -> Gestionnaire de fichiers.

Repérez tous les fichiers .htaccess situés entre la racine de documents (visible dans Domaines -> Gestion de domaines) et le répertoire de la page affectée.

Des erreurs fréquentes incluent :

• Une règle mal formée (syntaxe incorrecte).
• Un blocage par IP (Deny from / Require not).

• Un filtrage de user-agent.

• Une directive de redirection incorrecte.

Vous trouverez dans notre article Utiliser .htaccess pour filtrer les robots et requêtes malveillants un guide plus détaillé sur la gestion des blocages par .htaccess.

Étape 4 – Modifiez ou retirez les règles problématiques

Dans le Gestionnaire de fichiers :

1. Faites un clic droit sur le fichier .htaccess suspect.
2. Sélectionnez Éditer le fichier.
3. Déterminez quelles sont les règles pouvant causer une erreur 403, puis corrigez ou commentez-les temporairement (# en début de ligne).

Pensez à sauvegarder vos modifications.

Étape 5 — Videz la cache LSCache

Pour que les règles prennent effet, il peut être nécessaire dans N0C de vider la cache pour le domaine en question (voir l’article Comment utiliser LSCache).

Étape 6 — Rechargez la page et vérifiez le résultat

Une fois les règles modifiées et la cache vidée, rafraîchissez la page en cause dans votre navigateur pour voir si l’erreur 403 a disparu.

Si l’erreur persiste :

• Révisez à nouveau les fichiers .htaccess plus en amont dans l’arborescence.
• Vérifiez qu’aucune autre directive (ou cache navigateur) ne continue d’interférer.

Fonctions logicielles

Certaines erreurs 403 ne sont pas causées par le serveur ou les règles de sécurité, mais sont générées directement par le code de votre site. Par exemple, une condition dans un fichier PHP peut décider de bloquer l’accès à une ressource selon une logique métier ou un état inattendu (comme header() en PHP).

Étape 1 – Activez l’affichage des erreurs PHP

Pour faciliter le diagnostic, commencez par activer l’affichage des erreurs dans votre code. Cela peut-être fait selon l’une ou l’autre des méthodes suivantes.

• En activant l’affichage dans N0C -> Langages -> PHP -> Options -> display_errors pour afficher les erreurs directement dans la page.

• En activant la journalisation des erreurs dans un fichier via N0C -> Langages -> PHP -> Options -> log_errors et en choisissant un fichier de journal dans N0C -> Langages -> PHP -> Options -> error_log.

• En plaçant ces lignes en haut de votre fichier d’entrée (souvent index.php) ou dans un point d’exécution stratégique :

ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);

Cela permettra de repérer plus facilement des erreurs de logique ou des comportements inattendus.

Étape 2 – Tracez l’exécution du code

Ajoutez des instructions temporaires (echo, var_dump(), die(), etc.) à différents endroits dans votre code pour suivre le flux d’exécution, depuis le point d’entrée jusqu’à l’endroit où l’erreur est générée.

Par exemple :

echo 'Checkpoint 1';
...
echo 'Checkpoint 2';

Continuez ainsi de fonction en fonction, jusqu’au dernier point où le code s’exécute normalement.

Étape 3 – Identifiez l’origine de la réponse 403

Vous finirez souvent par trouver une condition qui déclenche un blocage volontaire, telle que :

if ($sky === 'blue') {
    http_response_code(403);
    exit;
}

Ces instructions sont parfois ajoutées par un développeur ou une extension pour contrôler l’accès à certaines ressources ou en faisant des tests.

Étape 4 – Corrigez ou ajustez la logique applicative

Une fois le blocage localisé :

• corrigez la condition si elle est trop restrictive ou inadaptée;
• ajoutez des journaux (logs) pour mieux comprendre le contexte; et
• vérifiez les permissions et rôles d’utilisateur si la logique repose sur ceux-ci.

Étape 5 – Nettoyez le code après correction

Une fois l’origine du blocage déterminée et corrigée, n’oubliez pas de retirer tous les éléments de déboggage ajoutés au moment du diagnostic :

• Supprimez tous les echo, var_dump(), ou die().
• Réinitialisez les paramètres d’affichage d’erreurs si vous les aviez modifiés tel ini_set('display_errors', '0').
• Si vous avez modifié des fichiers sensibles, pensez à vider la cache.

Cela évitera d’exposer des informations techniques en production ou de perturber le fonctionnement normal du site.

Remarque — Si vous utilisez un framework ou un CMS

De nombreux environnements de développement (frameworks comme Laravel ou Symfony) ou des systèmes de gestion de contenu (CMS comme WordPress, PrestaShop) utilisent des gestionnaires d’erreurs personnalisés, des logiciels intermédiaires (middlewares), ou des systèmes de contrôle d’accès internes. Dans ces cas :

• La fonction header() peut être encapsulée ou masquée.
• Les erreurs 403 peuvent être renvoyées par un composant comme un routeur (router), un pare-feu (firewall) interne, ou un contrôleur (controller).

Dans ces contextes, il est recommandé d’activer les logs de débogage natifs du système en question (ex. : APP_DEBUG=true dans Laravel .env, WP_DEBUG dans WordPress, etc.) et d’utiliser les outils fournis par le framework pour tracer le comportement (monolog, debugbar, etc.).

CSF

Sur notre infrastructure N0C, un des pare-feux CSF (ConfigServer Security & Firewall) est utilisé pour protéger les serveurs contre des comportements considérés comme abusifs ou suspects. Entre autres choses, un trop grand nombre de tentatives de connexions qui ont échoué (exemple : tentatives répétées de connexion IMAP, POP, SMTP, SSH, FTP ou même via l’interface N0C).

Dans ces cas, l’adresse IP de l’utilisateur peut être bloquée par CSF, ce qui entraîne une erreur 403 sur toutes les tentatives d’accès aux serveurs, y compris aux sites web, aux messages par courriels et à l’espace client.

Heureusement, N0C propose une fonction d’auto-déblocage simple à utiliser.

Étape 1 – Vous êtes témoin d’un blocage 403

Vous constatez une erreur 403 sur votre site, en plus d’une impossibilité soudaine d’accéder au compte de messagerie (webmail), de synchroniser vos courriels, FTP ou interface N0C? Cela peut être dû à un blocage de votre IP par CSF. Veuillez vous référer à l’article Comment accéder à un compte de messagerie Roundcube pour davantage de détails.

Étape 2 – Différenciez d’un blocage WAF

Comme pour les erreurs de permissions, les blocages par CSF n’apparaissent pas dans le journal du WAF, mais uniquement dans les journaux d’accès.

• Journal d’accès : Domaines -> Journal d’accès.
• Journal du WAF : Sécurité -> Historique de protection du pare-feu.

Étape 3 – Vérifiez la messagerie (webmail) pour un message d’auto-déblocage

Rendez-vous à l’adresse suivante : https://[votredomaine.com]/webmail.

Si votre IP est bloquée par CSF, une page d’erreur personnalisée y sera affichée avec un message d’information et un formulaire d’auto-déblocage via un CAPTCHA.

Étape 4 – Remplissez le formulaire d’auto-déblocage

Suivez les instructions sur la page pour confirmer que vous êtes un utilisateur humain légitime via un simple CAPTCHA. Une fois le formulaire envoyé, votre IP sera débloquée immédiatement si la demande est conforme.

Conclusion

Les erreurs 403 peuvent avoir plusieurs origines : une restriction imposée par le pare-feu applicatif (WAF), un blocage de sécurité par CSF, des permissions de fichiers incorrectes, une règle .htaccess mal formulée ou encore un comportement défini dans le code de votre application.

Les outils de diagnostic disponibles dans votre panneau de contrôle N0C aidant (journaux d’accès, journaux WAF, gestionnaire de fichiers et outils de déblocage), vous disposez de toutes les ressources nécessaires pour identifier rapidement la cause et appliquer les actions correctives appropriées et ce, tout en conservant un bon niveau de sécurité.

En cas de doute ou de difficulté persistante, n’hésitez pas à consulter la documentation complémentaire disponible ailleurs dans la base de connaissances ou à contacter le support technique.