Guide de sécurisation pour site e-commerce

Image de présentation pour

Le secteur du retail est une cible privilégiée des attaquants. Entre la gestion des comptes clients, les paiements, les cartes cadeaux ou encore les programmes de fidélité, un site e-commerce concentre une quantité importante de données sensibles et de flux financiers.

Dans la pratique, les vulnérabilités exploitées sont souvent simples : absence de contrôle serveur, fuite d’informations via les messages d’erreur, contournement du paiement ou encore brute-force sur des fonctionnalités exposées publiquement.

Voici une liste de points de contrôle concrets permettant d’évaluer le niveau de sécurité d’un site marchand moderne.

Gestion du compte utilisateur

Politique de mot de passe

La politique de mot de passe constitue la première ligne de défense contre la compromission des comptes clients.

Une politique minimale doit imposer :

  • au moins 8 caractères ;
  • une majuscule ;
  • une minuscule ;
  • un caractère spécial.

Même si cette politique reste relativement classique, elle permet d’éviter les mots de passe trop faibles.

Il est également recommandé de :

  • vérifier les mots de passe contre des bases de mots de passe compromis ;
  • empêcher l’utilisation du mot de passe précédent ;
  • proposer l’authentification multifacteur (MFA) pour les comptes sensibles.

Messages d’erreur lors de l’authentification

Les messages d’erreur ne doivent jamais permettre à un attaquant de savoir si un compte existe ou non.

Par exemple, ces messages sont problématiques :

  • « Cet utilisateur n’existe pas »
  • « Mot de passe incorrect »
  • « Adresse mail inconnue »

Ils permettent de réaliser facilement une phase d’énumération de comptes. Le site doit retourner un message générique :

Identifiant ou mot de passe incorrect

La même logique s’applique au renouvellement du mot de passe. Un message sécurisé peut être :

Si cette adresse existe, un email de réinitialisation a été envoyé

Changement d’adresse email

Le changement d’adresse email est une action sensible qui doit être sécurisée.

Les bonnes pratiques sont :

  • ne jamais indiquer si la nouvelle adresse existe déjà ;
  • envoyer un lien de validation sur la nouvelle adresse ;
  • ne modifier l’adresse qu’après validation ;
  • notifier l’ancienne adresse email qu’un changement est en cours.

Exemple de message générique :

Un email de validation a été envoyé à la nouvelle adresse renseignée

Cette mesure limite les prises de contrôle de compte via modification frauduleuse de l’email.

Changement du mot de passe

Lorsqu’un utilisateur souhaite modifier son mot de passe depuis son espace client, le mot de passe actuel doit être demandé.

Sans cette vérification, une session compromise permettrait immédiatement à un attaquant de verrouiller le propriétaire légitime hors de son compte.

Stockage sécurisé des mots de passe

Les mots de passe ne doivent jamais être stockés en clair.

Ils doivent être protégés à l’aide d’un algorithme de hachage robuste tel que :

  • Argon2 ;
  • bcrypt ;
  • PBKDF2.

Le mécanisme de vérification doit également être réalisé en temps constant afin d’éviter certaines attaques temporelles. Une délibération de la CNIL remonte que l’utilisation de SHA-256 avec un sel n’est pas suffisant :

  1. La rapporteure relève que les mots de passe des comptes utilisateurs du site web de la société étaient stockés hachés avec la fonction de hachage SHA256 et l’ajout d’un sel. Elle considère que de telles modalités de stockage constituent un manquement à l’article 32 du RGPD …

Enfin, il convient également de s’assurer que les anciens comptes utilisateurs ne conservent pas des mots de passe hachés avec des algorithmes obsolètes ou des paramètres de sécurité trop faibles (MD5, SHA1, bcrypt avec un coût insuffisant, etc.). Une stratégie de migration progressive des mots de passe doit être mise en place lors des authentifications utilisateurs afin d’appliquer les standards de sécurité actuels à l’ensemble du parc de comptes.

Protection contre le brute-force

Les interfaces d’authentification sont constamment ciblées par des robots essayant des milliers de couples identifiant / mot de passe.

Plusieurs protections doivent être mises en place :

  • limitation du nombre de tentatives (rate-limit);
  • blocage temporaire du compte ;
  • blocage de l’adresse IP ;
  • ajout d’un Captcha ;
  • détection comportementale.

Les APIs d’authentification mobiles et les endpoints JSON sont souvent oubliés lors de ces protections.

Gestion des sessions

La gestion des sessions est fréquemment négligée alors qu’elle est critique.

Il convient notamment de :

  • invalider les sessions lors d’un changement de mot de passe ;
  • définir une expiration automatique ;
  • protéger les cookies avec les attributs :
    • HttpOnly
    • Secure
    • SameSite
  • empêcher la réutilisation de session après déconnexion.

Envoi d’emails

Protection contre le spam

Les fonctionnalités permettant d’envoyer des emails doivent être protégées contre les abus.

Exemples fréquents :

  • partage de wishlist ;
  • envoi d’un panier ;
  • formulaire de contact ;
  • invitation d’un ami.

Des protections doivent être appliquées :

  • rate limiting ;
  • Captcha ;
  • limitation par IP ;
  • limitation par compte utilisateur.

Sans cela, le site peut devenir une plateforme d’envoi de spam.

Configuration sécurisée des emails

Les emails envoyés par le domaine doivent respecter les standards modernes : SPF, DKIM et DMARC.

Une mauvaise configuration peut permettre :

  • l’usurpation du domaine ;
  • une mauvaise délivrabilité ;
  • le phishing ciblant les clients.

Chiffrement des échanges

HTTPS obligatoire

L’ensemble des échanges doit être réalisé en HTTPS. Le site doit :

  • rediriger automatiquement HTTP vers HTTPS ;
  • utiliser HSTS.

Exemple d’en-tête HSTS :

Strict-Transport-Security: max-age=31536000

Configuration TLS robuste

La configuration TLS doit respecter l’état de l’art.

Les points à contrôler :

  • désactivation des protocoles obsolètes ;
  • désactivation des suites cryptographiques faibles ;
  • utilisation de TLS 1.2 minimum ;
  • préférence pour TLS 1.3.

Des outils comme SSL Labs ou Mozilla SSL Configuration Generator permettent de vérifier rapidement le niveau de sécurité.

Sécurisation du panier et des promotions

Gestion de l’état du panier

Le serveur doit systématiquement recalculer :

  • les quantités ;
  • les prix ;
  • les promotions ;
  • les frais de port.

Aucune donnée critique ne doit être considérée comme fiable côté client.

Par exemple :

  • quantité négative ;
  • modification du prix unitaire ;
  • suppression de frais de livraison ;
  • ajout d’une réduction arbitraire.

Toutes ces valeurs doivent être validées côté serveur.

Codes promotionnels

Les champs de coupon sont très souvent ciblés par brute-force.

Les protections attendues :

  • limitation du nombre de tentatives ;
  • délai temporaire après plusieurs échecs ;
  • journalisation des abus ;
  • surveillance des campagnes promotionnelles.

Un attaquant peut autrement découvrir des codes valides par automatisation.

Cartes cadeaux

Les cartes cadeaux sont aujourd’hui massivement ciblées par des groupes criminels spécialisés.

Les attaques observées consistent à :

  • brute-forcer des numéros de cartes ;
  • générer frauduleusement des cartes ;
  • modifier le montant ;
  • réutiliser des cartes déjà consommées.

Les points de contrôle essentiels sont :

  • génération aléatoire forte ;
  • identifiants non prédictibles ;
  • contrôle serveur du solde ;
  • journalisation complète ;
  • protection contre le brute-force ;
  • invalidation correcte après utilisation.

Les cartes cadeaux doivent être considérées comme un véritable moyen de paiement.

Sécurisation du paiement

Restriction des moyens de paiement

Le backend doit vérifier les moyens de paiement réellement autorisés.

Un attaquant peut tenter de modifier :

  • le type de paiement ;
  • les paramètres transmis au prestataire ;
  • les APIs de validation.

Les contrôles doivent toujours être réalisés côté serveur et non uniquement dans l’interface graphique.

Contournement du paiement

Le scénario classique d’attaque consiste à :

  • modifier le montant envoyé au PSP ;
  • falsifier le retour de succès ;
  • rejouer une réponse valide.

Le site marchand ne doit jamais considérer le navigateur comme une source fiable.

La validation du paiement doit se faire via :

  • webhook sécurisé ;
  • signature cryptographique ;
  • vérification serveur-à-serveur ;
  • contrôle du montant attendu.

Cette vérification asynchrone est indispensable avec des PSP comme Stripe ou Worldline.

Sécurisation des webhooks de paiement

Les webhooks doivent :

  • être authentifiés ;
  • utiliser une signature ;
  • vérifier l’origine ;
  • empêcher les rejeux.

Une absence de vérification permet parfois de forger artificiellement un paiement validé.

Factures et suivi de commande

Identifiants non prédictibles

Les liens d’accès aux factures ou au suivi de commande ne doivent pas être devinables.

Mauvais exemple :

https://market.com/factures/42

Bon exemple :

https://market.com/factures/6781b71c-e442-11ed-b5ea-0242ac120002

L’utilisation d’identifiants séquentiels expose des vulnérabilités de type IDOR (Insecure Direct Object Reference).

Utilisation de frameworks e-commerce

La majorité des sites marchands modernes reposent sur des frameworks ou CMS spécialisés comme Magento, PrestaShop, WooCommerce ou encore Shopify.

Ces plateformes apportent de nombreuses fonctionnalités mais augmentent également fortement la surface d’attaque :

  • administration complexe ;
  • nombreux modules tiers ;
  • APIs exposées ;
  • dépendances externes ;
  • composants historiques parfois vulnérables.

Les attaques ciblent très régulièrement des vulnérabilités connues affectant ces frameworks ou leurs extensions.

Mise à jour du framework e-commerce

Le framework principal doit être maintenu à jour en permanence. Les vulnérabilités affectant les plateformes e-commerce sont particulièrement sensibles car elles permettent souvent :

  • l’exécution de code à distance ;
  • le vol de données clients ;
  • la compromission du backoffice ;
  • l’installation de skimmers bancaires ;
  • le détournement des paiements.

Les attaquants automatisent massivement l’exploitation des vulnérabilités publiques sur les sites non mis à jour.

Il convient donc de :

  • surveiller les bulletins de sécurité éditeurs ;
  • appliquer rapidement les correctifs critiques ;
  • maintenir les versions supportées ;
  • tester les mises à jour dans un environnement de préproduction.

Mise à jour des modules et extensions

Les modules tiers représentent une source majeure de compromission.

Dans la pratique, les incidents de sécurité concernent très souvent :

  • des plugins abandonnés ;
  • des modules développés sur mesure non maintenus ;
  • des extensions vulnérables ;
  • des dépendances JavaScript obsolètes.

Chaque module installé augmente la surface d’attaque du site.

Les bonnes pratiques incluent :

  • limiter le nombre de modules installés ;
  • supprimer les modules inutilisés ;
  • maintenir les extensions à jour ;
  • surveiller les CVE affectant les plugins ;
  • privilégier des éditeurs reconnus ;
  • réaliser des revues de sécurité des modules sensibles.

Pour Prestashop, le site Friends-Of-Presta Security Advisories liste les modules présentant une vulnérabilité.

Désactivation des composants inutiles

Les fonctionnalités non utilisées doivent être désactivées ou supprimées :

  • pages d’administration secondaires ;
  • APIs inutilisées ;
  • modules de démonstration ;
  • outils de debug ;
  • connecteurs historiques.

Les composants inutiles deviennent souvent des points d’entrée oubliés lors des audits de sécurité.

Protection du site par un WAF et un CDN

Les sites marchands sont exposés en permanence à des attaques automatisées :

  • scans de vulnérabilités ;
  • brute-force ;
  • credential stuffing ;
  • scraping ;
  • attaques DDoS ;
  • exploitation de failles connues ;
  • bots frauduleux.

La mise en place d’un WAF (Web Application Firewall) couplé à un CDN permet d’ajouter une couche de protection essentielle entre Internet et l’application.

Des solutions comme Cloudflare ou encore Bunny permettent de renforcer significativement la sécurité d’un site e-commerce.

Sécurisation du backoffice

Le backoffice d’un site marchand constitue une cible prioritaire pour les attaquants. Contrairement au front-office, il permet généralement d’accéder à des fonctionnalités sensibles :

  • gestion des commandes ;
  • remboursement ;
  • génération de cartes cadeaux ;
  • gestion des clients ;
  • administration des promotions ;
  • accès aux données personnelles ;
  • gestion des stocks et des prix.

Une compromission du backoffice peut avoir un impact financier immédiat et massif.

Restriction d’accès au backoffice

L’accès au backoffice doit être limité autant que possible.

Plusieurs mécanismes peuvent être mis en place :

  • filtrage par adresse IP ;
  • VPN obligatoire ;
  • authentification multifacteur (MFA) ;
  • restriction géographique ;
  • SSO d’entreprise.

L’authentification multifacteur doit être obligatoire pour tous les comptes administrateurs et opérateurs backoffice.

Le backoffice ne devrait jamais être accessible publiquement sans protection renforcée.

Gestion des droits et des rôles

Les utilisateurs du backoffice ne doivent disposer que des droits strictement nécessaires à leurs missions.

Par exemple :

  • un préparateur de commande ne doit pas pouvoir générer des remboursements ;
  • un support client ne doit pas pouvoir modifier des prix ;
  • un administrateur marketing ne doit pas accéder aux données bancaires.

Une séparation stricte des privilèges permet de limiter l’impact d’un compte compromis.

Désactivation des comptes inutilisés

Les anciens comptes administrateurs ou prestataires doivent être désactivés rapidement.

Les points de contrôle incluent :

  • suppression des comptes obsolètes ;
  • désactivation automatique après inactivité ;
  • revue périodique des habilitations ;
  • suppression immédiate des accès lors d’un départ.

Les comptes dormants constituent une cible fréquente lors des compromissions.

Conclusion

La sécurisation d’un site e-commerce ne repose pas uniquement sur les vulnérabilités techniques classiques comme le XSS ou l’injection SQL.

Dans le retail, les failles les plus exploitées concernent souvent :

  • les logiques métier ;
  • les paiements ;
  • les promotions ;
  • les cartes cadeaux ;
  • les APIs ;
  • les workflows utilisateurs.

La majorité des attaques réussies exploitent des oublis de contrôle côté serveur ou des mécanismes métier insuffisamment sécurisés.

Une revue régulière des points de contrôle présentés dans cet article permet déjà d’élever significativement le niveau de sécurité d’un site marchand moderne.

Merci d'avoir lu cet article !

Si vous avez des commentaires ou des retours sur cet article, n'hésitez pas à me contacter. Venez aussi me dire bonjour sur X (ex-Twitter) ou sur Linkedin.