Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

Les droits de fichiers mal réglés sur un hébergement mutualisé

Un dossier ou un fichier trop ouvert sur un serveur partagé par des dizaines d’autres sites peut suffire à propager une infection d’un site à l’autre, sans qu’aucun mot de passe n’ait été compromis.

Décrire mon problème Discuter sur WhatsApp

Ce que sont les permissions de fichiers

Chaque fichier et chaque dossier sur un serveur a des permissions qui définissent qui peut le lire, le modifier ou l’exécuter : le propriétaire du fichier, un groupe d’utilisateurs, et tous les autres utilisateurs du serveur. Ces permissions s’expriment sous forme de trois chiffres, par exemple 644 ou 755, chacun combinant les droits de lecture, d’écriture et d’exécution pour ces trois catégories.

Sur un serveur dédié à un seul site, une permission trop ouverte reste un risque, mais limité. Sur un hébergement mutualisé, plusieurs comptes clients différents partagent souvent le même serveur physique. Si les permissions de fichiers sont trop permissives, un script exécuté sous un autre compte du même serveur peut, selon la configuration de l’hébergeur, lire ou écrire dans les fichiers d’un site voisin. C’est ce qu’on appelle une compromission « cross-site » ou « cross-account » : un site négligé peut devenir la voie d’entrée vers un site parfaitement à jour hébergé juste à côté.

Les valeurs recommandées pour WordPress

La documentation officielle de WordPress recommande des dossiers en 755 (ou 750 si le serveur le permet), des fichiers en 644 (ou 640), et un cas particulier pour wp-config.php : 440 ou 400, pour empêcher les autres utilisateurs du serveur de simplement le lire, puisqu’il contient les identifiants de connexion à la base de données. Aucun dossier ne devrait jamais être en 777, y compris les dossiers d’upload, souvent laissés trop ouverts pour éviter des erreurs d’écriture lors d’un envoi de fichier.

exemple de permission correcte
chmod 440 wp-config.php   # 644 laisse le fichier lisible par les autres comptes du serveur

Les valeurs recommandées pour PrestaShop

La documentation officielle et les guides communautaires de PrestaShop recommandent 644 pour les fichiers et 755 pour les dossiers. Certains hébergeurs demandent temporairement du 777 sur certains dossiers pendant la phase d’installation, pour que l’installateur puisse écrire sans erreur. Une fois l’installation terminée, il faut revenir à des permissions plus strictes : 775 pour les dossiers et 664 pour les fichiers au minimum, et idéalement 755 pour les dossiers et 644 pour les fichiers dès que la configuration de l’hébergeur le permet.

Comment vérifier vos propres permissions

  1. Se connecter en FTP ou SFTP

    La plupart des clients FTP affichent une colonne de permissions à côté de chaque fichier et dossier, généralement sous la forme de trois chiffres ou d’une suite de lettres.

  2. Vérifier le gestionnaire de fichiers de l’hébergeur

    Le panneau d’administration de l’hébergement propose en général un gestionnaire de fichiers avec les mêmes informations, sans avoir besoin d’un client FTP externe.

  3. Contrôler en priorité les fichiers de configuration

    wp-config.php sur WordPress, ou les fichiers de configuration de la base de données sur PrestaShop, doivent être vérifiés en premier : ce sont eux qui contiennent les informations les plus sensibles.

  4. Demander confirmation à votre hébergeur

    Un hébergeur sérieux peut confirmer si votre compte bénéficie d’une isolation entre clients sur le même serveur, ce qui réduit le risque même en cas de permission mal réglée ailleurs.

Pour aller plus loin

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Qu’avez-vous constaté ?
Depuis quand le problème est-il constaté ?

Plus l’infection est ancienne, plus elle a pu se propager dans les fichiers et la base de données.

Disposez-vous d’une sauvegarde saine ?
Avez-vous encore accès à l’administration WordPress ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Comment savoir si mon site a été infecté depuis un autre site du même serveur mutualisé ?
Je vérifie la date de création des fichiers injectés, les journaux d’accès disponibles et les permissions en place, ce qui permet souvent de distinguer une intrusion directe d’une propagation via le serveur.
Passer à un hébergement dédié règle-t-il définitivement ce risque ?
Cela supprime le risque de propagation entre comptes voisins, mais ne remplace pas des permissions correctement réglées : un fichier en 777 reste un risque, même seul sur son propre serveur.
Pourquoi mon hébergeur demande-t-il du 777 à l’installation ?
Certains installateurs de CMS ont besoin d’écrire des fichiers de configuration avant que les permissions définitives ne soient appliquées. C’est une étape temporaire, pas un réglage à conserver après l’installation.
Un dossier d’upload trop ouvert est-il vraiment un risque important ?
Oui : un dossier destiné aux images ou aux documents, s’il est en 777, peut permettre l’exécution d’un fichier qui s’y trouve selon la configuration du serveur, alors qu’il ne devrait contenir que des médias.
Faut-il vérifier ces permissions après chaque mise à jour du CMS ?
Une mise à jour peut recréer certains fichiers avec des permissions par défaut différentes des vôtres. Un contrôle rapide après une mise à jour majeure évite qu’un fichier sensible se retrouve à nouveau trop ouvert.