Tout ce que vous voudriez savoir avant d'installer.
Un regard détaillé sur le fonctionnement de En-têtes de Sécurité PrestaShop 8 & 9 : CSP, HSTS et Note A+ sans Toucher au Serveur, pourquoi nous l'avons conçu ainsi, et la réflexion derrière les fonctionnalités ci-dessus.
Pourquoi votre boutique obtient F sur securityheaders.com
PrestaShop n'envoie presque aucun en-tête de sécurité. Sans Content-Security-Policy, un script injecté par un module compromis ou une faille XSS peut lire les champs du formulaire de paiement. Sans HSTS, la première visite peut passer en http. Sans X-Frame-Options, votre boutique peut être affichée dans le cadre d'un site piégé. Les scanners publics le voient en quelques secondes et les agences, les auditeurs et certains partenaires de paiement consultent ces notes.
Construire une CSP sans casser le paiement
Une CSP trop stricte bloque Google Analytics, le widget de chat ou le formulaire Stripe. Le module part donc d'une politique compatible avec les thèmes PrestaShop et vous laisse cocher les services que vous utilisez. En mode test, la politique s'applique à vos IP et à vos appareils de test, tandis que les navigateurs des visiteurs remontent en Report-Only ce qui serait bloqué. Vous parcourez la boutique, vous traitez les violations, puis vous passez en mode appliqué quand la liste reste vide.
unsafe-inline, nonce et note A+
La note A demande une CSP appliquée, HSTS d'au moins six mois et les en-têtes courants. Le A+ exige en plus de ne plus autoriser les scripts inline sans contrôle. Le mode nonce ajoute un jeton aléatoire à chaque balise script de la page et retire unsafe-inline. Deux limites à connaître : un module de cache de page complète sert le HTML avec le nonce du premier visiteur, et les balises HTML personnalisées de Google Tag Manager doivent utiliser la variable nonce de GTM. Le journal des violations signale ces cas avant la mise en production.
Un module qui surveille après la mise en production
Une fois la CSP appliquée, une mise à jour de thème ou de module peut charger un domaine nouveau. Le module repère les ressources réellement bloquées qui n'avaient jamais été vues et envoie un email aux destinataires choisis, au plus une fois par heure. Chaque changement de réglages est conservé avec l'employé qui l'a fait et les différences avec l'état actuel : si une page casse, la version précédente se restaure en un clic.
Depuis PrestaShop plutôt que depuis le serveur
Les en-têtes sont envoyés par PHP au démarrage de chaque requête, sur le front et, si vous le souhaitez, sur le back-office. Aucun accès SSH ni fichier .htaccess n'est nécessaire, ce qui convient aux hébergements mutualisés. Si votre hébergeur ou Cloudflare ajoute déjà certains en-têtes, le scanner intégré signale les doublons. Et si vous préférez finalement confier les en-têtes au serveur, le module génère les blocs Apache et Nginx correspondants.
Il n’y a pas encore d’avis.