Sécurité e-commerce : la checklist HTTPS, SSL, RGPD et PCI-DSS

Vendre en ligne sans sécuriser son site expose à trois risques simultanés : une sanction du régulateur (CNIL, autorités PCI), une compromission des données de vos clients et une interruption de service préjudiciable à votre activité. Cette checklist couvre les quatre piliers indissociables — HTTPS/SSL, PCI-DSS v4.0, RGPD et infrastructure — et s'applique quelle que soit votre plateforme : PrestaShop, WooCommerce ou solution sur-mesure Symfony.

Le RGPD impose la privacy by design (protection dès la conception) et des mesures techniques proportionnées pour garantir la confidentialité et l'intégrité des données traitées. En cas de violation, la CNIL peut infliger des sanctions proportionnelles au chiffre d'affaires de votre structure.

Côté paiement, le standard PCI DSS v4.0 — dont toutes les exigences différées sont devenues obligatoires au 31 mars 2025 — a introduit deux nouvelles contraintes pour les pages de paiement : l'inventaire formel de chaque script JavaScript (exigence 6.4.3) et la détection automatique des modifications non autorisées des en-têtes HTTP de sécurité (exigence 11.6.1). Ces deux obligations s'appliquent même si vous externalisez le traitement chez un prestataire PSP.

Avant de déployer cette checklist, un audit technique de votre e-commerce vous permettra de prioriser les actions selon votre niveau de maturité actuel.

Le protocole HTTPS chiffre l'ensemble des échanges entre votre serveur et le navigateur de l'acheteur. Son activation est exigée sur la totalité du site, pas uniquement sur les pages de paiement.

• Installer un certificat SSL valide (Let's Encrypt ou autorité commerciale) et le renouveler avant expiration.
• Forcer la redirection HTTP vers HTTPS avec un code 301 permanent sur l'ensemble des URLs.
• Désactiver les protocoles TLS 1.0 et TLS 1.1, qui sont interdits par PCI DSS ; activer TLS 1.2 au minimum, TLS 1.3 en priorité.
• Activer HSTS (HTTP Strict Transport Security) avec une durée d'au moins un an et le flag includeSubDomains.
• Vérifier l'absence de contenu mixte (ressources HTTP chargées sur une page HTTPS) — les navigateurs les bloquent et dégradent la confiance utilisateur.

Les en-têtes HTTP constituent une deuxième ligne de défense contre les injections et les attaques XSS (Cross-Site Scripting). Pour une page de paiement conforme PCI DSS v4.0, les en-têtes suivants sont impératifs :

• Content-Security-Policy : liste blanche stricte des scripts autorisés — exigé par PCI DSS 6.4.3 pour inventorier chaque source JavaScript.
• X-Content-Type-Options: nosniff : empêche la détection automatique du type MIME.
• X-Frame-Options: DENY : bloque les tentatives de clickjacking.
• Referrer-Policy: strict-origin-when-cross-origin : limite les fuites d'URL vers des tiers.

Intégrez la vérification de ces en-têtes dans votre pipeline CI/CD pour détecter toute régression dès le déploiement.

PCI DSS (Payment Card Industry Data Security Standard) est la norme internationale qui régit la sécurité des données de porteurs de cartes. Tout marchand qui accepte les cartes bancaires — même via un PSP qui héberge le formulaire de paiement — doit respecter un niveau de conformité adapté à son volume de transactions.

La stratégie la plus efficace pour les marchands de taille moyenne est de limiter la surface d'attaque :

• Utiliser des champs de saisie hébergés chez votre PSP (hosted fields ou iframes sécurisés) : les données de carte ne transitent jamais par votre serveur.
• Activer l'authentification multifacteur (MFA) sur tous les accès à votre back-office e-commerce.
• Segmenter votre réseau pour isoler les flux de paiement du reste de l'infrastructure.
• Ne stocker aucune donnée de carte bancaire en clair : dès lors que vous externalisez le paiement chez un PSP certifié, le périmètre PCI de votre application se réduit considérablement.

Ces deux nouvelles obligations PCI DSS v4.0, applicables depuis mars 2025, imposent une discipline rigoureuse sur vos pages de paiement :

• Exigence 6.4.3 : maintenez un inventaire daté et autorisé de chaque script JavaScript chargé sur la page de paiement, avec justification métier documentée pour chaque script tiers.
• Exigence 11.6.1 : mettez en place une détection automatique des changements non autorisées sur les en-têtes HTTP et le contenu des pages de paiement, avec une fréquence minimale hebdomadaire.

La documentation officielle du PCI Security Standards Council détaille les questionnaires d'auto-évaluation (SAQ) applicables selon votre profil marchand et votre méthode de paiement.

Le RGPD ne se limite pas à la bannière de cookies. Il couvre l'ensemble du cycle de vie des données personnelles : collecte, stockage, durée de conservation, sous-traitance et droits des personnes.

• Désigner un référent interne — ou un DPO (délégué à la protection des données) si votre traitement est à grande échelle — et tenir le registre des activités de traitement à jour.
• Déployer un gestionnaire de consentement (CMP) conforme : bannière avec refus aussi simple que l'acceptation, sans case pré-cochée.
• Chiffrer les mots de passe avec Argon2 ou bcrypt ; chiffrer les données personnelles sensibles stockées en base (adresses, numéros de téléphone) avec AES-256.
• Documenter les durées de conservation par catégorie de données et mettre en place une purge automatique à échéance.
• Préparer une procédure de notification de violation : la CNIL doit être informée dans les 72 heures suivant la découverte d'une fuite de données.
• Pour les sites qui intègrent des traceurs tiers (analytics, remarketing), vérifier que chaque outil dispose d'une base légale (consentement ou intérêt légitime documenté).

La sécurité du code applicatif est insuffisante si l'hébergement est défaillant. Les points de vigilance prioritaires :

• Exiger des sauvegardes automatiques quotidiennes stockées hors site, et tester la restauration au moins une fois par trimestre.
• Activer un pare-feu applicatif web (WAF) avec les règles OWASP Top 10 au minimum, placé en coupure devant votre application.
• Mettre en place une protection anti-DDoS (Distributed Denial of Service) : rate limiting, filtrage par réputation d'IP.
• Restreindre les accès SSH à une liste blanche d'IP et à l'authentification par clés publiques uniquement — désactiver les mots de passe SSH.
• Surveiller les journaux serveur et appliquer des alertes sur les accès inhabituels ou les tentatives d'authentification répétées.

Pour aller plus loin sur la résilience de votre infrastructure, consultez notre guide sur le monitoring et l'infrastructure pour un e-commerce résilient.

La sécurité est un processus continu, pas un état figé. Les actions à planifier régulièrement :

• Appliquer les mises à jour de sécurité de votre CMS, de vos modules et de vos dépendances dans les 48 heures suivant leur publication — les exploits ciblant des versions connues sont publiés rapidement.
• Exécuter un scanner de vulnérabilités (OWASP ZAP ou équivalent) à chaque déploiement majeur.
• Limiter les comptes administrateurs au strict nécessaire et activer la MFA sur chacun d'eux.
• Formaliser un plan de réponse aux incidents : qui est notifié, dans quel délai, avec quelle procédure de rollback.
• Revoir annuellement votre questionnaire PCI DSS et votre registre de traitements RGPD pour refléter les évolutions de votre architecture.

Sur les architectures headless, la tokenization des données de paiement réduit le périmètre de conformité PCI en empêchant les numéros de carte de transiter par votre front-end.

Appliquer cette checklist de façon autonome est possible pour une équipe technique expérimentée. Si vous souhaitez un audit de conformité ou la mise en œuvre complète de ces mesures — HTTPS, PCI-DSS v4.0, RGPD, WAF, supervision 24/7 — les équipes de Webntricks interviennent sur PrestaShop, WooCommerce et solutions Symfony sur-mesure.

Consultez nos expertises en développement et sécurité e-commerce pour cadrer votre projet.