Votre voisin de serveur se fait pirater : et vous
Ou : dans un immeuble, la qualité de votre serrure compte moins que l’épaisseur des cloisons.
La réponse courte : sur un hébergement mutualisé bien cloisonné, le piratage d’un voisin reste chez le voisin, parce que chaque compte ne voit que ses propres fichiers et exécute son PHP sous son propre utilisateur. Sur un hébergement mal cloisonné, un script malveillant déposé chez lui peut lire vos fichiers de configuration, donc le mot de passe de votre base de données. Sur les serveurs sous CloudLinux, la technique de cloisonnement s’appelle CageFS : la documentation de CloudLinux la décrit comme un système de fichiers virtualisé qui enferme chaque utilisateur dans sa propre « cage », d’où il ne voit ni les autres comptes ni leurs noms. Cette isolation des comptes fait partie de ce que l’hébergeur protège, et c’est l’une des rares choses que vous ne pouvez pas vérifier vous-même.
Le cloisonnement a plusieurs étages : les fichiers, les processus (sous quel utilisateur tourne PHP), les ressources (processeur et mémoire plafonnés par compte) et le réseau. Les trois premiers dépendent de la configuration du serveur. Le quatrième, l’adresse IP partagée pour le site et pour l’envoi des mails, ne se cloisonne pas : il se partage, avec ses risques.
Pour qui : un indépendant ou une petite entreprise qui veut un mutualisé sérieux sur l’isolation des comptes, avec une adresse IP dédiée possible en option.
À partir de : 5,75 € HT par mois pour l’hébergement web Infomaniak, facturé à l’année par défaut, sans prix promotionnel affiché (relevé du 12 novembre 2026).
Pour démarrer : poser les questions du tableau au support avant de commander l’hébergement web Infomaniak ou une autre offre, puis garder la réponse écrite.
Sécurité d’un hébergement mutualisé : les questions à poser sur l’isolation des comptes
| Question à poser au support | Réponse rassurante | Pourquoi elle compte |
|---|---|---|
| Chaque compte est-il enfermé dans son propre système de fichiers ? | oui, avec CageFS ou un équivalent | un voisin compromis ne voit pas vos fichiers |
| PHP s’exécute-t-il sous l’utilisateur de mon compte ? | oui, avec des processus propres à chaque compte | un script du voisin n’a pas vos droits |
open_basedir est-il la seule barrière ? | non | PHP lui-même le présente comme une protection d’appoint |
| Les ressources sont-elles plafonnées par compte ? | oui : processeur, mémoire, processus | un voisin infecté ne ralentit pas tout le serveur |
| Mes mails partent-ils d’une adresse partagée ? | si oui, l’hébergeur surveille les listes noires | un voisin qui envoie du spam peut faire bloquer vos mails |
| Mon site partage-t-il son adresse IP ? | une adresse dédiée est proposée en option | une attaque contre un voisin peut couper l’adresse commune |
Le cas de open_basedir mérite un détour. Cette directive limite les dossiers que PHP peut ouvrir ; elle ressemble à une cloison, sans en être une. Le manuel de PHP est pourtant clair sur sa portée : c’est une mesure d’appoint, et « on ne peut donc pas s’y fier lorsque la sécurité est nécessaire ». Une réponse du support qui s’arrête à open_basedir est donc une réponse incomplète.
Ce que les hébergeurs en disent publiquement varie. PlanetHoster annonce sur sa page d’accueil CageFS et les limites de ressources de CloudLinux pour isoler chaque compte. o2switch parle de sites « cloisonnés » grâce à ses Lunes, des comptes cPanel supplémentaires inclus dans ses offres. Infomaniak indique dans sa FAQ que PHP y tourne en mode FPM, un mode qui permet de faire tourner chaque compte sous son propre utilisateur, sans détailler son cloisonnement sur la page de l’offre. Dans tous les cas, une question écrite au support coûte moins cher qu’une supposition.
Reste l’adresse IP, le point que le cloisonnement ne règle pas. Sur un mutualisé, les mails partent souvent par des serveurs d’envoi communs : si un voisin piraté envoie du spam, l’adresse peut finir sur une liste noire, et vos factures atterrir dans les indésirables de vos clients. Un bon hébergeur surveille ces listes et fait retirer ses adresses ; un service mail séparé du mutualisé, avec sa propre réputation d’envoi, supprime le problème. Côté site, l’adresse IP commune expose à un autre risque, celui des attaques par saturation dirigées contre un voisin.
Ces questions ne servent pas qu’avant l’achat. Elles valent aussi au moment de répartir plusieurs sites : mettre un site de test oublié dans le même compte qu’une boutique, c’est créer soi-même le voisin dangereux.
Quand c’est votre compte qui a été percé
Un cloisonnement solide protège vos voisins de vous autant que vous de vos voisins. Si le compte piraté est le vôtre, il faut d’abord trouver la porte d’entrée, extension, thème ou mot de passe ; l’ordre des opérations, et les guichets à prévenir en Belgique, en France et en Suisse, sont décrits dans les premières heures après une intrusion.
L’adresse commune, cible collatérale
Quand une attaque par saturation vise un voisin, la protection du réseau filtre ce qu’elle peut ; au-delà, l’adresse IP entière peut être coupée, avec tous les sites qu’elle sert. Le mécanisme, et ce qu’un CDN ou une adresse dédiée changent, sont expliqués dans la protection anti-DDoS d’un mutualisé.