Durcissement du serveur PrestaShop : fermer ce qui n’a pas à être ouvert

Sécuriser le serveur d’une boutique PrestaShop consiste à fermer ce qui n’a pas à être ouvert : ports, services, comptes, droits d’écriture, dossier d’administration, en-têtes et versions sans correctif. Chaque point se vérifie par une question à l’hébergeur ou par un contrôle de l’extérieur. Sur un hébergement mutualisé, l’hébergeur tient la plupart des réglages : la mission devient alors un contrôle écrit plutôt qu’une intervention.

• L’inventaire des ports, des services et des comptes ouvre le durcissement d’un serveur PrestaShop
• Les droits d’écriture d’une boutique PrestaShop se limitent aux répertoires qui en ont besoin
• Le dossier d’administration de PrestaShop se protège par un mot de passe serveur et des adresses
• Les en-têtes HTTP et le TLS d’un serveur PrestaShop se contrôlent de l’extérieur
• Les versions de PHP et les réglages PHP fixent la part du serveur qu’aucun correctif ne couvre
• Un durcissement de serveur PrestaShop se livre avec un état avant et après, testé sur une copie
• Attendre est la bonne décision quand la boutique est déjà compromise ou en plein pic
• Sources consultées
• Foire aux questions

L’inventaire des ports, des services et des comptes ouvre le durcissement d’un serveur PrestaShop

La fiche 9 du guide de la CNIL (version 2024, mise à jour 2026) demande de désinstaller ou désactiver les services et interfaces inutiles. Elle demande aussi de limiter les outils d’administration aux personnes habilitées et d’utiliser des comptes sans privilèges pour les opérations courantes. La fiche 10 précise : quand l’accès à un serveur web passe uniquement par HTTPS, seuls les flux entrants sur le port 443 restent autorisés, les autres ports sont bloqués.

Trois questions écrites suffisent pour ouvrir le dossier :

• Quels ports répondent vu de l’extérieur, et pourquoi chacun ?
• Quels comptes existent (système, FTP ou SSH, c’est-à-dire l’accès distant aux fichiers et à la console, base de données, panneau de l’hébergeur), au nom de qui ?
• Qui administre le serveur, par quel canal ?

Un scénario courant : le compte FTP créé pour un ancien prestataire reste actif, partagé entre trois personnes. La CNIL range les comptes génériques et une base de données directement accessible depuis Internet parmi ce qu’il ne faut pas faire.

Les droits d’écriture d’une boutique PrestaShop se limitent aux répertoires qui en ont besoin

La page d’installation en local (« localhost ») de la documentation développeur de PrestaShop 1.7 liste quinze répertoires où la boutique doit pouvoir écrire, dont cache, config, img, modules, themes, translations, upload et var. Elle déconseille, en production, de faire tourner Apache sous son propre utilisateur et demande de changer les droits dossier par dossier.

Le reste de l’arborescence n’a pas besoin d’être modifiable par le serveur web (déduction). Un scénario : un module vulnérable, sur un serveur qui écrit partout, peut réécrire un fichier du cœur.

La configuration d’exemple de la documentation pour Nginx va plus loin : elle refuse les fichiers .php dans /img et /upload, sous le commentaire « Prevent injection of PHP files ». Elle refuse aussi notamment les fichiers .log, .tpl, .twig et .yml. La page signale que cette configuration « may be incomplete » : adaptez-la, ne la copiez pas.

Le dossier d’administration de PrestaShop se protège par un mot de passe serveur et des adresses

Le guide de la version 1.6 demande de renommer le dossier /admin après l’installation. La documentation développeur de PrestaShop 9 ajoute d’y poser un fichier .htaccess ou .htpasswd, ce que le guide détaille : un mot de passe demandé par le serveur avant même la page de connexion, avec une restriction possible par domaine ou par adresse IP. Le fichier .htpasswd se range hors des dossiers accessibles par le web, et la méthode ne vaut que sous Apache : sous Nginx, la règle s’écrit dans la configuration du serveur (déduction).

Le renommage réduit le bruit des robots ; le mot de passe serveur et la restriction par adresse forment la barrière (déduction). Dans Paramètres avancés > Administration, l’option « Vérifier l’adresse IP du cookie » (Check the cookie’s IP address) vérifie que l’adresse du visiteur correspond à celle du cookie. La « Durée de vie du cookie back-office » (Lifetime of the back office cookie) est de 480 heures par défaut, selon la documentation de la version 8 et le code d’installation de la 8.2 : raccourcissez-la si la sécurité le demande.

Le dossier /install se supprime après l’installation : la documentation développeur de PrestaShop 9 parle d’une obligation. Le guide de la 1.6 ajoute les fichiers README.md, CONTRIBUTING.md, CONTRIBUTORS.md et le dossier /docs, et un bloc FilesMatch qui refuse l’accès aux fichiers .tpl.

Décrire mon besoin →

Les en-têtes HTTP et le TLS d’un serveur PrestaShop se contrôlent de l’extérieur

La CNIL demande TLS (le protocole qui chiffre les échanges web) sur tous les sites web, obligatoire sur les pages d’authentification et celles qui transmettent des données personnelles, avec les cookies marqués « HttpOnly » et « Secure ». Elle privilégie TLS 1.3 ou, à défaut, 1.2 d’après les recommandations de l’ANSSI, et cite un testeur en ligne de configuration TLS (« SSL Server Test »).

La fiche de référence d’OWASP sur les en-têtes HTTP fournit des valeurs d’exemple :

OWASP recommande aussi de retirer X-Powered-By, et de retirer l’en-tête Server ou de le rendre neutre. Le manuel de PHP indique que la directive expose_php vaut « 1 » par défaut et fait apparaître la version de PHP dans l’en-tête X-Powered-By.

Pour Content-Security-Policy, la fiche d’OWASP juge la configuration complexe et renvoie à une fiche dédiée. Une politique trop stricte bloque en silence les scripts de paiement ou de mesure : essayez-la en préproduction (déduction).

Les versions de PHP et les réglages PHP fixent la part du serveur qu’aucun correctif ne couvre

Chaque version de PHP reçoit deux ans de support actif, puis deux ans de correctifs de sécurité, d’après php.net. Au 14 octobre 2026, PHP 8.2 n’en reçoit que jusqu’au 31 décembre 2026, PHP 8.3 jusqu’au 31 décembre 2027, et PHP 8.1 ne figure plus au tableau des versions supportées. La documentation de PrestaShop 9 accepte PHP 8.1 à 8.4 pour la 9.0 et 8.1 à 8.5 pour la 9.1. La compatibilité par version de PrestaShop se lit dans la mission hébergement et infogérance.

Durcir sans casser suppose de respecter les exigences de la boutique. La documentation de PrestaShop 9 écrit que l’option allow_url_fopen doit être activée, car la boutique accède à des fichiers distants, y compris pour les paiements ; son php.ini d’exemple laisse allow_url_include sur « Off ». Le manuel de PHP prévient que disable_functions « can be circumvented » et ne suffit pas à protéger un hébergement mutualisé, et que open_basedir reste « an extra safety net ».

Un durcissement de serveur PrestaShop se livre avec un état avant et après, testé sur une copie

Exigez un état daté avant et après, avec la liste des écarts trouvés et leur sort : corrigé, refusé avec raison, reporté. La CNIL attend en plus une journalisation des événements, des mises à jour critiques installées sans délai (le cas échéant après test) avec une vérification hebdomadaire, et des sauvegardes restaurables, dont la sauvegarde et la reprise fixent les règles.

Le test porte sur le parcours : commande jusqu’au retour du prestataire de paiement, connexion au back-office, envoi d’un e-mail, génération d’un PDF. Pour un paiement hors du site, la documentation développeur de PrestaShop 9 (« Payment modules ») décrit un appel du prestataire vers la boutique, dont la source se vérifie par signature ou jeton : une règle de pare-feu trop stricte peut le couper, et les commandes restent en attente de paiement (scénario).

Le prix suit le nombre de serveurs et d’environnements, la présence d’une préproduction, le choix mutualisé ou dédié, l’étendue du contrôle et la surveillance continue. Faites écrire qui paie la remise en état quand un réglage coupe la boutique.

Décrire mon besoin →

Attendre est la bonne décision quand la boutique est déjà compromise ou en plein pic

Une boutique déjà piratée passe d’abord par le nettoyage après piratage : durcir autour d’une porte d’entrée ouverte la protège pour l’intrus (déduction). Un pic de ventes annoncé reporte les modifications qui demandent un redémarrage.

Un serveur obsolète mais essentiel s’isole, et les données personnelles qu’il traite se limitent en attendant son remplacement, d’après la fiche 9.

Sources consultées

• CNIL, « Guide pratique RGPD : Sécurité des données personnelles », version 2024, mise à jour 2026, fiches 9 et 10, consulté le 14 octobre 2026.
• PrestaShop, documentation de la version 1.6 en français, « Rendre votre installation de PrestaShop plus sûre », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de la version 9, « File structure », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de la version 1.7, installation en local (« localhost »), section des permissions, consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de la version 9, « Configure Nginx », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de la version 9, « System requirements » et « Payment modules », consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de la version 8, « Administration », consulté le 14 octobre 2026.
• OWASP, « HTTP Headers Cheat Sheet », consulté le 14 octobre 2026.
• php.net, manuel, « Description of core php.ini directives » et « Supported Versions », consulté le 14 octobre 2026.

Foire aux questions

Un hébergement mutualisé peut-il être durci ?

En partie. L’hébergeur règle le système, PHP et le serveur web ; vous gardez les droits de la boutique, le dossier d’administration, les comptes et les modules. La mission consiste alors à faire écrire ce que l’hébergeur ferme et à contrôler de l’extérieur ce qui répond.

Le certificat HTTPS suffit-il à sécuriser le serveur ?

Non. HTTPS protège l’échange entre le visiteur et le serveur ; il ne dit rien des ports ouverts, des droits d’écriture ni des comptes. La CNIL demande TLS en plus des mesures d’accès et de mise à jour.

Faut-il un pare-feu applicatif ?

La CNIL cite, pour les serveurs critiques, des systèmes de détection et de prévention des attaques en complément des mesures de base. Un pare-feu applicatif filtre une partie des requêtes web ; il ne corrige ni un module vulnérable ni un PHP sans correctif (déduction).

Peut-on durcir un serveur sans arrêter la boutique ?

Tout se prépare sur une copie, et la mise en ligne se fait hors pic. Les changements qui demandent un redémarrage du serveur web ou de PHP coupent brièvement le site (déduction) : demandez la fenêtre prévue par écrit.

À quelle fréquence contrôler la configuration d’un serveur ?

La CNIL demande une vérification automatique hebdomadaire des mises à jour. Pour les traitements les plus critiques, elle conseille des tests de vulnérabilités menés de façon régulière et avant toute mise en production d’une nouvelle version logicielle (fiche 10).