Tests et pentests d’un site e-commerce : méthode, actions, finalités

Un samedi matin, une boutique en ligne perd 47 000 € en quatre heures. Pas un piratage spectaculaire, pas un ransomware. Juste une faille bête : le prix des produits était calculé côté navigateur, jamais re-vérifié côté serveur. Un client a modifié les valeurs dans sa requête, est passé en caisse avec un panier à 1,20 €, et a recommencé. Soixante-douze fois. Avec soixante-douze comptes différents.

Personne, dans l’équipe technique, n’avait imaginé qu’on pouvait faire ça. Personne ne l’aurait imaginé. C’est exactement le rôle d’un pentest : tester ce que personne n’a imaginé.

Un site marchand n’est pas une vitrine inerte. C’est une mécanique vivante qui traite des comptes clients, des paiements, des stocks, des coupons, des données personnelles. Chaque rouage peut casser, et chaque casse coûte. Une faille dans le panier, c’est du chiffre d’affaires qui part. Une faille dans la session, c’est la confiance qui s’effondre. Une faille sur un module obsolète, c’est parfois toute la boutique qui se retrouve hors-ligne pendant trois jours.

Tester la sécurité d’un site e-commerce, ce n’est pas lancer trois outils et imprimer un rapport. Un audit sérieux combine reconnaissance technique, scans automatisés, vérifications manuelles et compréhension de la logique métier. Voici comment ça se passe vraiment, étape par étape, sans jargon mais sans rien diluer.

Pourquoi tester un site e-commerce avant que les attaquants le fassent à votre place

Un site marchand concentre des risques que les sites vitrines n’ont pas. Vol de comptes clients, détournement de session, manipulation de panier ou de prix, accès non autorisé aux commandes, fuite de données personnelles, exploitation d’une faille sur le CMS ou les modules, injection de code malveillant, compromission du tunnel de paiement : la liste n’est pas exhaustive, elle est juste réaliste.

Le but d’un test de sécurité n’est pas de cocher des cases. C’est d’identifier les risques avant qu’ils soient exploités, et surtout de les hiérarchiser. Toutes les alertes ne se valent pas. Une CVE non exploitable dans votre contexte n’a pas le même poids qu’une faille IDOR qui permet à un client de voir les commandes de tous les autres. Un bon audit fait le tri, parce que c’est ce qui permet de décider où mettre l’effort et le budget.

C’est aussi un sujet stratégique : les enjeux de la cybersécurité pour les entreprises ne sont plus uniquement techniques. Ils touchent la conformité, l’assurabilité, la réputation. Une boutique e-commerce qui se fait pirater, c’est aussi un dirigeant qui passe ses week-ends à appeler ses clients un par un.

Test, audit, scan, pentest : ne plus mélanger les termes

Les mots ont des sens précis dans ce métier, et les confondre crée des malentendus avec les prestataires.

Un scan de vulnérabilités est une analyse automatisée. Il détecte les ports ouverts, les versions logicielles exposées, les en-têtes manquants, les vulnérabilités publiquement référencées (les CVE). C’est rapide, c’est utile, mais c’est superficiel. Un scan ne comprend pas votre logique métier.

Un audit technique va plus loin que le scan. Il analyse la configuration, les technologies, les flux, les logs disponibles, les dépendances, les pratiques de développement. C’est plus structuré qu’un scan, mais ça reste une lecture statique de l’existant.

Un pentest est offensif. Il reproduit le raisonnement d’un attaquant, dans un cadre autorisé et contractualisé. Il teste les failles logiques que les outils détectent mal : modifier un prix dans une requête, accéder à la commande d’un autre client, contourner une étape du tunnel d’achat, rejouer un coupon. C’est là que se trouvent les failles les plus graves sur un site e-commerce, et c’est là que l’œil humain reste irremplaçable.

Sur un site marchand qui compte, les trois approches se complètent. Le scan donne la photo, l’audit donne la radio, le pentest essaie d’enfoncer la porte. Aucun ne remplace les deux autres.

Cadrer le périmètre avant de lancer quoi que ce soit

C’est l’étape qu’on saute toujours, et qu’on regrette toujours. Avant le moindre test, le périmètre doit être noir sur blanc.

Les éléments à définir avec le prestataire :

• domaine principal et sous-domaines à inclure ou exclure ;
• environnement testé : production, préproduction, staging ;
• horaires autorisés (typiquement hors heures de pointe) ;
• limites de charge tolérées ;
• tests du tunnel de paiement autorisés ou non ;
• comptes de test mis à disposition ;
• périmètre des tests authentifiés ;
• contacts techniques joignables en cas d’incident.

Sans autorisation écrite, un pentest peut devenir illégal et peut perturber le service. Sur un site e-commerce en production, les tests doivent être contrôlés et non destructifs. Le bon réflexe : préproduction par défaut, production uniquement sur des phases black-box légères et avec un canal de communication ouvert avec l’hébergeur.

Phase 1 : reconnaissance et cartographie de la surface d’attaque

La première phase consiste à comprendre comment le site apparaît vu de l’extérieur. Quelles technologies tournent dessous, quelles adresses sont visibles, quelles informations un attaquant peut collecter avant même d’avoir tenté quoi que ce soit. C’est l’équivalent du repérage des lieux avant tout audit.

Les actions typiques :

• identifier les technologies utilisées (CMS, serveur web, langages, modules) ;
• vérifier les ports exposés et les services qui répondent ;
• analyser les certificats TLS et leur cohérence avec les domaines servis ;
• observer les en-têtes HTTP retournés ;
• récupérer robots.txt et sitemap.xml pour cartographier les endpoints ;
• repérer les zones critiques : login, panier, compte, recherche, checkout.

Les outils du métier sur cette phase : Nmap pour les ports et services, WhatWeb ou Wappalyzer pour les technologies, Nuclei pour les CVE, Nikto pour les mauvaises configurations courantes, Burp Suite ou OWASP ZAP pour l’analyse applicative en profondeur. Pour comparer ces solutions, voir notre comparatif des outils d’audit de site.

Cette étape répond à une question simple : qu’est-ce qui est exposé publiquement ? Plus la réponse est courte, mieux le site se porte.

Phase 2 : analyse des vulnérabilités connues

Une fois la surface cartographiée, on confronte ce qui est exposé aux bases publiques de vulnérabilités. Sur un site marchand, plusieurs zones sont à vérifier en priorité :

• le CMS (PrestaShop, WooCommerce, Magento, Shopify customisé) et sa version exacte ;
• les modules ou plugins installés, qui sont historiquement le maillon faible ;
• les versions PHP, Apache, Nginx, Node.js exposées ;
• les librairies JavaScript côté front (souvent oubliées et rarement à jour) ;
• les fichiers exposés par erreur (.env oubliés, fichiers de sauvegarde, sources accessibles).

Un point important : un résultat automatique n’est pas une vulnérabilité confirmée. Les scanners produisent des faux positifs, et chaque alerte doit être validée manuellement. Une CVE remontée sur une version de PHP n’est exploitable que si la fonction concernée est réellement appelée par votre application. C’est exactement ce travail de tri qui sépare un rapport copié-collé d’un audit utile.

Pour avoir un point de départ rapide, vous pouvez démarrer avec Ze Audit Web, notre outil d’analyse des points faibles d’un site qui balaie la performance, le SEO, la sécurité et la conformité en quelques minutes.

Phase 3 : sécurité HTTP et configuration serveur

Les en-têtes HTTP jouent un rôle majeur dans la protection côté navigateur. Ce sont les instructions que votre serveur donne au navigateur de vos visiteurs pour lui dire quoi accepter et quoi refuser.

Les points à vérifier systématiquement :

Un cookie de session sans HttpOnly augmente fortement le risque en cas de faille XSS. Sur un site e-commerce, la session utilisateur est critique : elle donne accès au compte, au panier, aux adresses, aux commandes passées et à venir. Un attaquant qui vole une session vole tout ça d’un coup.

Phase 4 : tests applicatifs manuels, là où se cachent les vraies failles

C’est ici que le pentest devient réellement intéressant. Les outils automatiques peuvent difficilement comprendre la logique métier d’un site marchand. Or c’est précisément là que se trouvent les failles les plus graves, parce qu’elles ne sont jamais référencées comme CVE et qu’elles sont propres à votre site.

Tester le panier

Quelques actions classiques à mener (toujours dans un environnement autorisé) :

• modifier l’identifiant produit dans la requête et observer la réaction ;
• envoyer un produit qui n’existe pas ;
• jouer avec la quantité (zéro, négative, très élevée) ;
• vérifier si le prix est recalculé côté serveur ou si le client peut l’imposer ;
• rejouer une requête d’ajout au panier capturée plus tôt.

L’objectif est simple : vérifier que le serveur ne fait jamais confiance aux données envoyées par le client. Un site qui accepte un prix envoyé par le navigateur est un site qu’on peut piller. Ce type d’incident, on l’a déjà documenté côté terrain dans notre anatomie d’une cyberattaque sur un site e-commerce PrestaShop.

Tester les coupons et promotions

La logique promotionnelle est un nid à failles. Quelques tests à faire :

• appliquer plusieurs fois le même coupon ;
• modifier l’identifiant du coupon dans la requête ;
• utiliser un coupon expiré ;
• cumuler des remises théoriquement incompatibles ;
• réutiliser un code à usage unique déjà consommé.

Un cumul de remises non maîtrisé peut transformer un panier de 200 euros en panier à -15 euros. Ce n’est pas une faille théorique, c’est un classique.

Tester le checkout

Le tunnel d’achat doit valider chaque étape côté serveur, jamais côté client uniquement. Les actions à éprouver :

• sauter une étape du tunnel (passer directement à la confirmation sans paiement) ;
• modifier le mode de livraison après calcul ;
• forcer le montant total à la baisse ;
• rejouer une requête de validation de commande ;
• tester les transitions d’état d’une commande (panier vers payé sans paiement réel).

Ces tests sont à faire en préproduction. Toucher au tunnel de paiement en production sans accord explicite peut perturber des commandes réelles.

Phase 5 : authentification, sessions et comptes clients

L’authentification est un point sensible. Les vérifications à mener :

• robustesse de la connexion (longueur de mot de passe, complexité, lockout) ;
• expiration et invalidation de session après déconnexion ;
• protection contre le brute force (rate limiting, captcha, MFA) ;
• procédure de réinitialisation de mot de passe (token unique, à usage unique, expiration) ;
• changement d’email ou de mot de passe avec confirmation ;
• réutilisation d’anciens tokens après déconnexion.

Un test particulièrement utile : vérifier qu’une session reste invalide après un changement de mot de passe. Une session qui ne s’invalide pas correctement permet à un attaquant de conserver son accès même après que le client a réagi en changeant son mot de passe. Ça paraît basique. Ça reste fréquent.

Phase 6 : contrôle d’accès et failles IDOR

Les failles IDOR (Insecure Direct Object Reference) sont parmi les plus fréquentes sur les sites e-commerce, et parmi les plus graves. Le principe : une URL référence directement un objet métier par son identifiant, et l’application ne vérifie pas que l’utilisateur connecté a le droit d’y accéder.

Exemple typique :

/fr/commande?id=12345

Si un client connecté peut remplacer 12345 par 12346 et voir la commande d’un autre client, vous avez une faille critique. Pas une alerte, pas un warning : une vraie fuite de données personnelles, avec exposition RGPD à la clé.

Les zones à tester systématiquement : commandes, factures, adresses, profils, tickets support, fichiers téléchargeables (factures PDF en particulier), retours produits. Le bon réflexe côté code : chaque ressource est vérifiée côté serveur, pas seulement masquée côté interface.

Phase 7 : XSS et injections SQL

Les sites e-commerce contiennent énormément de champs alimentés par les utilisateurs : recherche, formulaire contact, avis clients, adresse de livraison, nom et prénom, message cadeau, champs personnalisés des modules. Chaque champ est un point d’entrée potentiel.

Tests basiques pour les XSS :

<script>alert(1)</script> et « ><img src=x onerror=alert(1)>

Une XSS stockée dans un champ visible par l’administrateur (nom, message cadeau, avis client) est particulièrement grave. Elle peut permettre le vol de session admin, la modification de contenu côté boutique, l’injection de scripts persistants visibles par tous les visiteurs.

Les injections SQL sont moins fréquentes sur les CMS modernes correctement maintenus, mais elles doivent rester sur la check-list. Les zones à éprouver : formulaires, filtres de recherche, paramètres numériques dans les URL, filtres de catégorie. Un comportement bizarre sur une apostrophe dans un champ de recherche est toujours à creuser.

Phase 8 : protection CSRF

Une faille CSRF (Cross-Site Request Forgery) permet de forcer un utilisateur authentifié à exécuter une action sans son consentement. L’attaquant prépare une page piégée, le client la visite alors qu’il est connecté à votre boutique, et la page exécute des requêtes à son insu.

Les actions sensibles à tester :

• modification d’adresse de livraison ;
• changement d’email associé au compte ;
• changement de mot de passe ;
• ajout au panier ;
• validation d’une commande ;
• suppression d’un compte ;
• modification de préférences.

Un bon mécanisme CSRF utilise un token unique, imprévisible, lié à la session et vérifié côté serveur. Si une requête fonctionne sans token, ou avec un token invalide, ou avec un token rejouable, c’est cassé. La bonne nouvelle : la plupart des CMS récents protègent ça nativement. Encore faut-il vérifier que la protection est bien active sur les modules tiers, qui sont souvent moins rigoureux.

Phase 9 : audit du code et des dépendances

Quand le code source est disponible, l’audit gagne en précision. Les actions recommandées :

• analyse statique du code avec Semgrep, SonarQube ou CodeQL ;
• audit des dépendances avec npm audit, Composer audit, pip-audit ou Snyk ;
• recherche de secrets oubliés (clés API, tokens, accès FTP ou SMTP) avec Gitleaks ou TruffleHog ;
• vérification des fichiers .env, .git accessibles publiquement, sauvegardes oubliées sur le serveur ;
• revue manuelle des contrôleurs sensibles (paiement, compte, panier).

Les dépendances tierces sont aujourd’hui un point majeur. Un module e-commerce vulnérable peut exposer l’ensemble du site, même si le cœur applicatif est propre. Un audit qui ne regarde que le code que vous avez écrit passe à côté de 70 % de la surface d’attaque réelle.

Comment lire et interpréter le rapport d’audit

Un bon rapport ne doit pas être une liste brute de messages remontés par les outils. Chaque finding doit être qualifié sur plusieurs dimensions :

• vulnérabilité confirmée ou faux positif ;
• criticité (critique, haute, moyenne, faible, info) ;
• impact concret sur l’activité (perte de données, fraude, indisponibilité) ;
• facilité d’exploitation (ressources nécessaires, niveau d’accès requis) ;
• preuve (capture, payload, log) ;
• recommandation de correction concrète et chiffrée en effort ;
• priorité dans le plan d’action global.

Une vulnérabilité critique permet typiquement un accès non autorisé aux commandes, une prise de contrôle de compte ou une modification de prix. Une faiblesse moyenne ressemble plus à un en-tête manquant, une configuration Apache perfectible, une exposition de version. Une information technique exposée est faible seule, mais peut devenir utile dans une chaîne d’attaque combinée à autre chose.

Pour aller plus loin sur la traduction de ces résultats en pilotage simple pour un dirigeant, regardez du côté de Wazuh et de notre approche du Classeur Cyber qui transforme les données techniques en indicateurs lisibles.

À quoi sert vraiment un pentest e-commerce

Un pentest ne sert pas seulement à trouver des failles. Il sert à prendre de meilleures décisions. Les finalités principales :

• réduire le risque d’attaque réussie ;
• prioriser les corrections selon leur impact réel ;
• renforcer la confiance des clients qui voient une marque qui se prend au sérieux ;
• améliorer la conformité (RGPD, PCI-DSS, NIS 2 selon votre secteur) ;
• protéger le chiffre d’affaires en réduisant les fenêtres d’indisponibilité ;
• éviter les incidents de paiement ou de fuite de données ;
• améliorer les pratiques de développement de l’équipe technique.

Un bon pentest produit un plan d’action clair, pas seulement un score. Et un score sans plan d’action, c’est de la décoration sur un mur.

Retour d’expérience : ce qu’un audit a révélé sur une boutique « pourtant à jour »

Le contexte : Un client e-commerçant nous contacte fin 2024. CA annuel autour de 3 M€, boutique sur PrestaShop, équipe technique interne de deux développeurs. Le site tourne depuis six ans, il est maintenu, les modules sont mis à jour régulièrement, la dernière migration PrestaShop date de huit mois. Côté dirigeant, le sentiment est clair : « on n’a rien à se reprocher, on a fait les choses correctement ». L’audit est commandé surtout pour cocher une case avant le renouvellement de l’assurance cyber.

Le cadrage : Une demi-journée pour fixer le périmètre, les comptes de test, les horaires autorisés, le canal de communication avec l’hébergeur. On part sur du black-box puis du gray-box, en préproduction pour les tests sensibles, en production pour la reconnaissance et les scans non intrusifs. Tout est écrit, signé, daté.

Ce qu’on a trouvé en quatre jours.

• Une faille IDOR sur les factures PDF : En modifiant un identifiant dans l’URL de téléchargement, un client connecté pouvait récupérer la facture de n’importe quel autre client. Nom, prénom, adresse, montant, liste des produits achetés. Aucune vérification côté serveur. Risque RGPD : maximum. Découverte : en quinze minutes.
• Un coupon cumulable avec lui-même : Un code promo à usage unique pouvait être appliqué autant de fois qu’on voulait en rejouant simplement la requête d’ajout au panier. Sur l’historique du site, deux commandes anciennes affichaient un montant négatif. Personne ne s’en était aperçu.
• Trois modules tiers avec des CVE critiques publiées en 2023 : Modules toujours installés, toujours actifs, jamais mis à jour parce que le fournisseur avait disparu. Un de ces modules permettait théoriquement une RCE (exécution de code à distance).
• Un fichier .env accessible publiquement : sur un sous-domaine de staging oublié, indexé par les moteurs de recherche. Il contenait les identifiants SMTP du compte de notification clients et une ancienne clé API d’un prestataire de paiement.
• Une session qui ne s’invalidait pas après changement de mot de passe : Si un compte avait déjà été compromis, le client pouvait changer son mot de passe sans déloger l’attaquant.

La réaction du dirigeant : Le mot exact, à la restitution : « je pensais qu’on était propres ». C’est la phrase qu’on entend le plus souvent. Pas par négligence : parce qu’aucun de ces points n’apparaît dans une mise à jour de routine. Le module qui marche tous les jours ne signale pas qu’il est vulnérable. Le panier qui s’additionne correctement ne dit pas qu’on peut le manipuler. Le site qui répond en HTTPS ne dit pas que ses cookies sont volables.

Le plan d’action : Cinq corrections critiques traitées dans les dix jours. Trois corrections moyennes étalées sur six semaines. Le sous-domaine staging désindexé et fermé en deux heures. Coût total de l’audit + remédiation : environ 1,5 % du CA mensuel de la boutique. Coût hypothétique d’une seule de ces failles exploitée à grande échelle : plusieurs dizaines de milliers d’euros minimum, sans compter le RGPD et l’effet sur la confiance des clients.

Ce qu’il faut en retenir si vous hésitez à faire auditer votre boutique : Un site « à jour » n’est pas un site « audité ». Une équipe technique compétente n’est pas une équipe qui passe son temps à essayer de casser son propre travail. Faire venir un regard extérieur pendant quelques jours, c’est exactement ce qui permet de découvrir les failles que vos propres yeux ne voient plus, parce qu’ils sont habitués au code. Et c’est ce qui transforme un sentiment de sécurité en sécurité réelle.

Ce qu’il faut retenir avant de planifier votre prochain audit

Tester un site e-commerce demande une approche complète. Les outils automatisés sont utiles pour cartographier rapidement et détecter les vulnérabilités connues, mais ils ne suffisent pas. Les failles les plus critiques sont presque toujours liées à la logique métier : panier, paiement, compte client, coupons, commandes, contrôle d’accès. Et la logique métier ne se teste qu’à la main, avec quelqu’un qui comprend votre application.

La bonne approche combine reconnaissance technique, scans de vulnérabilités, analyse HTTP, tests manuels, tests authentifiés, audit de code source quand il est disponible, et rapport priorisé. Un site bien testé est un site dont les risques sont compris, documentés et traités dans le bon ordre. Le pentest n’est pas une fin en soi : c’est un outil de pilotage de votre sécurité.

Chez Zetruc, on accompagne les e-commerçants sur ce sujet depuis plus de 20 ans. Audit black-box, pentest applicatif, mise en conformité, formation des équipes, accompagnement complet sur la cybersécurité : on adapte la profondeur à la taille de votre boutique, à votre budget et à votre niveau de maturité. Si vous voulez faire le point sur votre site avant qu’un attaquant ne s’en charge, contactez notre équipe pour cadrer un audit.

La méthode Zetruc en 5 temps

Notre approche d’un test de sécurité sur un site e-commerce suit toujours la même structure. Pas par dogmatisme : parce qu’elle évite les angles morts.

1. Cadrage et périmètre. On fixe noir sur blanc ce qui sera testé : domaines, sous-domaines, environnements (production, préproduction), modules tiers, API, espace administrateur. On définit ce qui est explicitement hors périmètre (par exemple un module fournisseur qu’on n’a pas le droit de toucher). Sans cette étape, on ouvre la porte à des malentendus juridiques et à des tests partiels.
2. Reconnaissance. Avant d’attaquer, on cartographie la surface exposée : pages publiques, points d’entrée API, formulaires, en-têtes HTTP, technologies détectables (CMS, framework, version), comptes admin connus. Cette phase reproduit ce qu’un attaquant fait en premier : du repérage. Pour aller plus loin sur les outils utilisés, voir notre article sur les outils d’audit de site.
3. Tests automatisés. On lance des scanners de vulnérabilités sur l’ensemble du périmètre. Ils repèrent les classiques : injections SQL connues, XSS reflétés, configurations par défaut, versions logicielles obsolètes, en-têtes de sécurité manquants. C’est rapide, ça couvre large, mais ça ne détecte que le déjà-connu.
4. Tests manuels. C’est ici que le pentest gagne sa valeur. Un humain teste la logique métier : peut-on modifier le prix d’un panier en passant par l’API ? Peut-on commander un produit en rupture ? Peut-on accéder à la commande d’un autre client en changeant un identifiant dans l’URL ? Peut-on contourner un coupon à usage unique ? Aucun scanner ne trouve ces failles, parce qu’elles dépendent de la spécificité du site. C’est là qu’on capte les vraies vulnérabilités e-commerce.
5. Restitution et plan de remédiation. On livre un rapport hiérarchisé par criticité (critique, élevée, moyenne, faible), avec pour chaque faille : la preuve d’exploitation, l’impact métier, et la correction recommandée. Le rapport ne sert à rien s’il finit dans un tiroir. On propose toujours un plan d’action chiffré et calé dans le temps.

Votre boutique a-t-elle été testée cette année ? Si la réponse est non, ou si vous lancez bientôt une refonte, parlons de votre site. On commence toujours par un cadrage gratuit pour identifier ce qui mérite vraiment d’être testé en priorité et ce qui peut attendre.