Sécurité PrestaShop : mises à jour, SSL et durcissement .htaccess

Table des matières :

1. Mises à jour PrestaShop : réduire la fenêtre d’exploitation (core, modules, PHP)
2. SSL/TLS : HTTPS intégral, certificats automatisés, et proxy-aware en production
3. Durcissement .htaccess : ce que PrestaShop régénère, et ce que vous devez verrouiller
4. Contrôles continus : tester TLS, surveiller les logs, et prouver que le durcissement tient

La sécurité PrestaShop en production se joue sur trois axes qui se cassent souvent la figure ensemble : mises à jour (core + modules + dépendances), SSL/TLS (HTTPS partout, sans ambiguïté derrière proxy/CDN) et durcissement Apache via .htaccess (réduire la surface d’attaque sans casser la boutique). Les exemples ci-dessous sont pensés pour PrestaShop 8.2.x et 9.1.x (Symfony 6.4 côté core), avec PHP 8.2/8.3 — note : PrestaShop 9.1 supporte PHP 8.1–8.5 (cf. PrestaShop 9.1 : compatibilité PHP 8.1–8.5). Pour .htaccess, on parle Apache 2.4 ; si vous êtes sur Nginx, les règles doivent être portées dans la conf vhost (et surtout pas “traduites à la volée” sans tests).

Dans un contexte e-commerce (souvent collecte de données personnelles, comptes clients, paiement via PSP, comptes BO à privilèges), l’objectif n’est pas d’empiler des “trucs sécurité” : c’est de réduire durablement la probabilité d’une compromission (vol de session, webshell via upload, injection via module), et de limiter l’impact si un incident arrive (détection rapide + rollback + restauration).

« Compte tenu de l’état des connaissances, des coûts de mise en œuvre […] ainsi que des risques […], le responsable du traitement […] met en œuvre les mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque. » (RGPD — Règlement (UE) 2016/679, art. 32, 2016, https://eur-lex.europa.eu/eli/reg/2016/679/oj)

Mises à jour PrestaShop : réduire la fenêtre d’exploitation (core, modules, PHP)

La réalité côté e-commerce : la majorité des incidents “PrestaShop” viennent soit d’un module vulnérable, soit d’un core figé qui traîne des CVE, soit d’un serveur qui n’a pas reçu ses patchs OpenSSL/Apache/PHP. OWASP a mis le sujet noir sur blanc dans le Top 10 : « If you do not know the versions of all components you use (both client-side and server-side), you are likely vulnerable. » (OWASP Top 10, A06:2021 “Vulnerable and Outdated Components”, https://owasp.org/Top10/). Traduction opérationnelle : tant que vous n’avez pas un inventaire de versions (core + modules + dépendances PHP + OS), vous pilotez à l’aveugle.

Sur PrestaShop, le piège classique est de traiter la mise à jour comme une tâche “admin” alors qu’elle doit être un processus d’ingénierie. Concrètement : un environnement de staging isoproduit (même PHP, même config de cache, même reverse proxy), des snapshots (fichiers + base), et un runbook qui inclut rollback. Si vous migrez vers 9, le core a bougé (Symfony 6.4, commandes CLI, etc.) : vous devez caler votre stratégie avec une checklist de compatibilité modules (voir Compatibilité modules PrestaShop 9 : checklist avant migration sécurisée) et une vraie campagne de tests fonctionnels (tunnel de commande, règles panier, mails transactionnels — voir Contrôle PrestaShop post-modification : checklist tunnel de commande).

Une pratique simple (et très rentable) consiste à formaliser une politique de délai de patch. Exemple pragmatique, à adapter à votre contexte (trafic, exposition, dépendances PSP/ERP) :

Type de mise à jour	Exemples	Délai cible en prod	Pré-requis
Critique / exploit probable	module paiement, RCE, contournement auth	24–72 h	staging + rollback + gel des changements non liés
Haute	fuite d’info, XSS impactant BO, CSRF sensible	7 jours	tests checkout + BO
Moyenne	bugfix sécurité sans exploit évident	30 jours	fenêtre maintenance
Confort / dette	refacto, mises à jour mineures	planifié	batch avec tests élargis

La surface d’attaque modules est souvent sous-estimée : un module PHP a généralement les mêmes privilèges que le core (lecture/écriture filesystem, DB, appels réseau). Deux actions qui font gagner du temps et de la sécurité : (1) désinstaller proprement ce qui ne sert plus (tables, overrides, hooks) plutôt que “désactiver” (voir Modules PrestaShop : désinstallation propre, performances et sécurité en production) ; (2) suivre les bulletins/CVE des modules critiques (paiement, logistique, connecteurs). Exemple concret côté paiement : une vulnérabilité module peut déclencher une mise à jour hors cycle, avec mesures compensatoires (WAF, règles de blocage) en attendant le déploiement ; cf. CVE-2025-61922 ps_checkout : mise à jour 5.0.5 et mesures.

Mini-scénario (vécu en production) : un module “secondaire” (slider, export, connecteur marketing) n’est plus maintenu, mais reste installé “au cas où”. Un attaquant n’a pas besoin d’attaquer le checkout : il vise le maillon le plus faible, obtient une écriture fichier (ou une requête SQL), puis pivote vers les sessions BO / tokens / config. Dans cette logique, l’“inventaire” devrait inclure :

• le statut de maintenance (éditeur actif, derniers commits/releases),
• les droits implicites (écrit-il dans /upload/ ? expose-t-il un endpoint public ?),
• l’exposition (front-office, back-office, CRON public, webhook).

Techniquement, industrialisez au minimum :

• Git pour versionner le code (y compris thèmes), et tracer précisément ce qui change entre deux releases.
• Composer audit quand applicable (PrestaShop embarque vendor/, mais vos modules/projets custom ont souvent leur propre composer.json). Exemple : composer audit --locked --no-interaction dans votre pipeline.
• Automatisation des déploiements (CI/CD) pour réduire les “hotfix SSH”. Une build reproductible réduit les surprises (voir Intégration continue PrestaShop : BuildKit, GitHub Actions et build reproductible).

Ajoutez une brique souvent oubliée : la gestion du cycle de vie PHP. Une boutique peut être “à jour PrestaShop” tout en étant exposée si PHP/OS traîne (EOL, patchs absents). Pour vérifier rapidement la fenêtre de support PHP côté officiel : https://www.php.net/supported-versions.php. En pratique :

• évitez les sauts de version PHP “au hasard” en prod : testez d’abord les modules sensibles (paiement, search, marketplace),
• surveillez les extensions (opcache, intl, imagick) : une mise à jour peut changer un comportement et casser un module,
• gardez un rollback PHP (container immuable / paquets pinés / snapshots VM), pas seulement un rollback du code.

SSL/TLS : HTTPS intégral, certificats automatisés, et proxy-aware en production

Sur une boutique, le SSL/TLS n’est pas “juste un cadenas” : c’est la base de la confidentialité (sessions, tokens, credentials BO), de l’intégrité (anti-tampering) et d’une partie du SEO (canonical, redirections propres). L’IETF est explicite sur le legacy : « TLS 1.0 and TLS 1.1 are deprecated » (RFC 8996, 2021, https://www.rfc-editor.org/rfc/rfc8996). Donc en 2026 : TLS 1.2 minimum, TLS 1.3 si possible, et des suites cohérentes avec les recommandations Mozilla (https://ssl-config.mozilla.org/).

Côté certificats, l’option pragmatique reste ACME + Let’s Encrypt, parce que l’automatisation évite les expirations “à 2h du matin”. La promesse est assumée : « Let’s Encrypt is a free, automated, and open certificate authority » (Let’s Encrypt, https://letsencrypt.org/). Sur un serveur unique, un Certbot avec timer systemd suffit ; sur une archi multi-nœuds (LB + backends), privilégiez DNS-01 (cert centralisé au load balancer) ou un gestionnaire de secrets (Vault) selon votre stack.

Bon réflexe “production” : monitorer l’expiration comme une métrique (jours restants) et poser une alerte (J-30 puis J-7). Beaucoup d’incidents TLS ne viennent pas du renouvellement lui-même, mais d’un détail : chaîne intermédiaire manquante, erreur d’accès au répertoire challenge, règle de redirection qui bloque /.well-known/acme-challenge/, ou encore un changement de LB qui oublie d’embarquer la clé/cert.

Exemple minimal Apache 2.4 (à mettre en vhost, pas dans .htaccess) :

# Apache 2.4 + OpenSSL récent
SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLCipherSuite          TLSv1.2 HIGH:!aNULL:!MD5:!3DES
SSLHonorCipherOrder     on
SSLUseStapling          on
SSLStaplingCache        "shmcb:/var/run/ocsp(128000)"

# HTTP/2 si mod_http2 activé
Protocols h2 http/1.1

# HSTS (à activer seulement après validation complète HTTPS)
Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"

Le point qui casse le plus souvent sur PrestaShop : HTTPS derrière reverse proxy/CDN. Si le backend voit du HTTP (proxy → backend), PrestaShop peut générer des liens en HTTP, des cookies incohérents et du mixed content. Il faut que l’app détecte correctement le schéma externe (via X-Forwarded-Proto) et que votre proxy soit “trusted” selon la couche Symfony/Front Controller. Sans ça, vous aurez des redirections en boucle et des sessions BO instables. Dans la même famille : attention aux règles “Force HTTPS” ajoutées à la main dans .htaccess alors que le LB gère déjà la redirection ; vous empilez deux logiques et vous créez des boucles.

Un test simple après mise en place CDN/proxy : connectez-vous au BO, naviguez 2–3 pages, puis vérifiez dans le navigateur que :

• les URLs restent en HTTPS (aucun retour en HTTP),
• les cookies de session portent bien l’attribut Secure (et idéalement HttpOnly),
• il n’y a pas d’erreur mixed content sur la page checkout (souvent causée par un module qui charge une ressource en HTTP).

Enfin, SSL/TLS doit être cohérent avec vos contraintes de paiement et de conformité. Si vous manipulez du paiement (même via redirection), votre périmètre de responsabilité augmente (sessions BO, pages checkout, scripts tiers). Pour cadrer proprement la partie conformité et tests (sandbox, scénarios), vous pouvez croiser ce durcissement TLS avec les exigences PCI-DSS décrites dans Paiement en plusieurs fois PrestaShop : tests sandbox, TAEG et conformité PCI-DSS.

Durcissement .htaccess : ce que PrestaShop régénère, et ce que vous devez verrouiller

PrestaShop génère (et régénère) une partie du .htaccess à la racine, notamment quand vous touchez aux URL simplifiées. Le problème est connu : vos règles custom peuvent être écrasées si vous les insérez au mauvais endroit. Discipline minimale : n’éditez pas les blocs gérés par PrestaShop (souvent délimités par des marqueurs # ~~start~~ / # ~~end~~ selon versions) ; ajoutez vos règles avant ou après ces blocs, et testez systématiquement sur staging. Le cœur de PrestaShop n’est pas “HTAccess-aware” au sens DevOps : il ne vous garantit pas une fusion non destructive.

Au passage, gardez en tête que .htaccess a un coût : Apache le relit et l’applique à chaque requête (selon config). En production, essayez de limiter les “bidouilles” à ce qui est strictement utile ; tout ce qui relève de la politique globale (TLS, modules Apache, compression) est mieux placé au niveau vhost.

Le durcissement utile commence par réduire l’exposition de fichiers sensibles (dotfiles, dumps, manifests) et éviter des fuites d’infos qui facilitent l’exploitation (versions, chemins, secrets). Exemple (racine) :

# Empêcher l’indexation de répertoires
Options -Indexes

# Bloquer l'accès à des fichiers sensibles
<FilesMatch "(?i)^(composer\.(json|lock)|package\.json|yarn\.lock|\.env|\.gitignore|\.htaccess|phpunit\.xml|dump\.sql)$">
  Require all denied
</FilesMatch>

# Bloquer les répertoires VCS
RedirectMatch 404 (?i)\/\.git(\/|$)
RedirectMatch 404 (?i)\/\.svn(\/|$)

Astuce “anti-fuite” : si vous exportez parfois des fichiers (CSV, logs, dumps) pour du support, évitez de les déposer dans la webroot “temporairement”. La majorité des fuites viennent d’un fichier oublié (export.csv, backup.zip, debug.log) qui reste accessible et indexable. Si vous n’avez pas le choix, ajoutez une règle de blocage sur des patterns de sauvegarde courants (zip/tar/gz) — mais testez : certains thèmes/modules peuvent servir des archives légitimes.

Deuxième brique : empêcher l’exécution de scripts dans des répertoires qui servent au stockage (uploads, images, pièces jointes). C’est un classique : une faille d’upload + exécution = RCE. Sur Apache 2.4, dans /img/ et /upload/ (via un .htaccess placé dans ces dossiers), vous pouvez interdire PHP :

# /img/.htaccess et /upload/.htaccess
<FilesMatch "(?i)\.php$">
  Require all denied
</FilesMatch>

# Optionnel : bloquer d’autres extensions exécutables selon votre stack
<FilesMatch "(?i)\.(phar|phtml|pht|cgi|pl|asp|aspx)$">
  Require all denied
</FilesMatch>

Ne faites pas ça dans /modules/ ou /override/ : vous casserez le runtime (beaucoup de modules exposent des endpoints front/back). C’est précisément là que le core PrestaShop montre ses limites : la séparation “code exécutable” vs “fichiers uploadés par l’utilisateur” n’est pas strictement cloisonnée par défaut ; à vous de blinder les dossiers qui doivent rester statiques.

Troisième brique : durcir l’accès au Back-Office. Renommer le dossier /adminXXXX/ est utile mais insuffisant. Ajoutez un contrôle d’accès réseau (allowlist IP) si vos équipes ont des IP fixes/VPN, ou a minima une auth HTTP basique en amont. Exemple allowlist (à adapter) :

# Dans le .htaccess du dossier admin (ex: /admin123/)
<RequireAll>
  Require ip 203.0.113.10 203.0.113.11
</RequireAll>

Alternative souvent efficace (si vous ne pouvez pas allowlister) : une Basic Auth au niveau Apache/Nginx avant la page de login PrestaShop. Avantages : ça stoppe une grosse partie du bruit (scans, brute-force) et ça force un secret de plus. Exemple (à mettre dans le dossier admin, en stockant le fichier .htpasswd hors webroot) :

AuthType Basic
AuthName "Back-Office"
AuthUserFile /etc/apache2/.htpasswd_prestashop_admin
Require valid-user

Si vous ne pouvez pas allowlister (IP mobiles), basculez sur une protection WAF + détection brute-force + journalisation. Sur ce point, évitez de “sur-optimiser” .htaccess avec des regex anti-bot ingérables : vous allez dégrader la perf et créer des faux positifs. Pour une approche propre côté SIEM/WAF et contrôle d’API/BO, voyez Sécurité PrestaShop : protéger API backoffice, WAF et journalisation SIEM.

Contrôles continus : tester TLS, surveiller les logs, et prouver que le durcissement tient

Un durcissement non monitoré finit toujours par régresser : une mise à jour de module qui ajoute un endpoint, une règle .htaccess écrasée, un proxy qui change un header, un certificat qui n’est plus renouvelé. La base : centraliser logs Apache/Nginx, logs PHP-FPM, logs PrestaShop (BO + erreurs), et poser des alertes sur quelques signaux faibles : 401/403 en hausse sur /admin, spikes 404 sur endpoints connus, et erreurs 5xx sur checkout. Si vous avez besoin d’une mise en place rapide, Netdata donne une visibilité immédiate sur serveurs web, DB et ressources (voir Netdata monitoring : surveiller AWS, Kubernetes, bases de données et serveurs web) ; et Grafana sert ensuite à industrialiser les dashboards (voir Grafana sur Ubuntu : installation APT et configuration initiale).

Côté vérifs “sécurité”, arrêtez de valider au doigt mouillé. Faites tourner des tests automatisables :

• TLS : SSL Labs (https://www.ssllabs.com/ssltest/) ou testssl.sh (https://testssl.sh/) après chaque changement de LB/vhost.
• Headers : Mozilla Observatory (https://observatory.mozilla.org/) pour repérer HSTS/CSP manquants.
• Web : OWASP ZAP (https://www.zaproxy.org/) sur staging pour détecter des patterns évidents (exposition d’admin, répertoires, etc.).

Pour que ces contrôles servent vraiment, pensez “Definition of Done” après chaque changement d’infra ou de sécurité (nouveau CDN, nouveau WAF, migration PrestaShop, changement PHP) :

• un scan TLS (résultat archivé),
• une navigation BO + un checkout de test (avec paiement sandbox si possible),
• un contrôle “ressources bloquées / mixed content” dans la console navigateur,
• une vérification que les logs arrivent toujours dans votre stack (sinon vous devenez aveugle au pire moment),
• un test de rollback (au moins 1 fois par trimestre) : restaurer une sauvegarde sur staging et rejouer un checkout.

L’objectif n’est pas de “faire A+” partout : c’est d’éviter les régressions et d’attraper vite un mauvais déploiement.

Enfin, ne négligez pas la couche “hygiène” qui évite de transformer une erreur en incident : permissions filesystem strictes, display_errors=Off en prod, séparation environnements, et gestion propre des erreurs (voir Gestion d’erreur PHP : bonnes pratiques et configuration développement/production). Ajoutez une routine de maintenance DB et sauvegardes testées (restores réels), parce qu’en sécurité, le dernier rempart reste la capacité à reconstruire vite (voir Base de données PrestaShop : routine de maintenance et nettoyage automatisé et, pour l’infra, Hébergement cloud managé : performance NVMe, CDN mondial et TTFB <50 ms).

Si vous devez prioriser : (1) patch management avec staging + rollback, (2) HTTPS propre proxy-aware + HSTS après validation, (3) .htaccess minimaliste mais ciblé (fichiers sensibles + no-exec dans uploads + verrouillage BO), (4) monitoring + tests automatisés. C’est beaucoup moins “spectaculaire” qu’un gros WAF, mais c’est ce qui fait baisser réellement la surface d’attaque sur une boutique PrestaShop.