Sécurité des paiements : PCI et fraude

Module 6: Gestion et sécurité · Temps de lecture : 11 minutes

Objectif pédagogique : Après cette leçon, vous saurez expliquer pourquoi une boutique ne traite jamais elle-même les données de carte, ce que PCI DSS et SAQ A signifient pour une petite boutique, comment protéger la page de commande, et comment repérer et limiter la fraude et le card testing.

Notions clés : PCI DSS, données de carte, prestataire de paiement, redirection vers la page de paiement, formulaire de paiement intégré (iframe), SAQ A, scripts sur la page de commande, e-skimming, https, HSTS, card testing, limitation du débit (rate limiting), captcha, 3-D Secure, rétrofacturation (chargeback), risque de fraude

Les données de carte n’ont rien à faire dans votre boutique

Un numéro de carte bancaire, sa date d’expiration et son code de sécurité valent de l’or pour les criminels. Quiconque les stocke ou les transmet relève de PCI DSS (Payment Card Industry Data Security Standard), la norme de sécurité des réseaux de cartes. La version actuelle est la v4.0.1. Pour une entreprise qui traite elle-même les données de carte, cela représente un ensemble d’exigences considérable : séparation des réseaux, journaux, analyses, tests par un organisme agréé.

Une petite boutique ne souhaite pas s’engager là-dedans, et n’en a pas besoin. La règle est simple : les données de carte n’entrent jamais dans votre boutique. Le client les saisit chez votre prestataire de paiement (Mollie, Stripe, PayPal, WooPayments ou un autre, leçon 4.4). La boutique reçoit ensuite uniquement l’information : payé ou non, avec une référence. Pas de numéro de carte, pas de code. Cela signifie aussi :

• ne jamais créer votre propre champ de formulaire pour les numéros de carte, même pas « juste pour une commande par téléphone » ;
• ne jamais accepter de données de carte par e-mail, chat ou téléphone pour les noter dans une note de commande ;
• ne pas utiliser d’extension qui conserve les données de carte dans votre propre base de données.

Redirection ou formulaire intégré : SAQ A

Les petites boutiques démontrent leur conformité à PCI DSS au moyen d’un SAQ (Self-Assessment Questionnaire, un questionnaire d’auto-évaluation). Votre prestataire de paiement le demande parfois. Le plus léger est le SAQ A, destiné aux boutiques qui externalisent entièrement le paiement. Dans une boutique, cela fonctionne de deux manières :

1. Redirection. Après avoir cliqué sur « Commander », le client est envoyé vers la page de paiement du prestataire, puis revient. La boutique ne voit jamais les données de carte, ni même la page sur laquelle elles sont saisies.
2. Formulaire intégré. Le champ de paiement se trouve dans votre page de commande, mais il s’agit d’une iframe (une portion de page) du prestataire. Les données de carte vont directement du navigateur au prestataire.

Depuis le 31 mars 2025, une nouvelle version du SAQ A s’applique. Elle contient une condition qui concerne surtout la seconde méthode : si vous utilisez un formulaire intégré, vous devez confirmer que votre site n’est pas vulnérable aux attaques par scripts pouvant affecter le système de paiement. Le contexte est l’e-skimming : un script malveillant sur votre page de commande qui lit ce que le client saisit, ou qui superpose un faux champ de paiement au vrai. Si vous redirigez vers la page du prestataire, cette condition ne vous concerne pas. Demandez à votre prestataire de paiement quel SAQ s’applique à votre intégration : il le sait précisément.

Ce que vous faites dans tous les cas :

• Gardez la page de commande dépouillée. Tout script présent sur cette page peut en principe lire ce qui est saisi : widgets de chat, gestionnaires de balises, pixels publicitaires, outils de test A/B. Ne chargez sur la page de commande que ce qui est nécessaire au paiement. Un gestionnaire de balises sur la page de commande est une porte par laquelle toute personne ayant accès à ce compte peut ajouter des scripts.
• Peu d’extensions, et à jour (leçon 6.2). La plupart des cas d’e-skimming sur WordPress passent par une faille dans une extension ou par un mot de passe administrateur volé.
• Une Content-Security-Policy (un en-tête qui indique de quels domaines les scripts peuvent provenir) limite les dégâts si quelque chose s’introduit malgré tout. C’est un travail pour quelqu’un qui sait le tester : une CSP mal configurée casse votre bouton de paiement.

https et HSTS sur la page de commande

Que toute votre boutique fonctionne en https va de soi (formation WordPress, leçon 3.1). Pour la page de commande, deux points s’ajoutent :

• http doit rediriger immédiatement vers https, avec une redirection permanente (301 ou 308). Un client qui saisit un jour http://shop.example.com/commande/ ne doit jamais recevoir une page non chiffrée.
• HSTS (HTTP Strict Transport Security) est un en-tête qui demande au navigateur de n’ouvrir votre site qu’en https pendant une certaine durée. Vous empêchez ainsi qu’une personne sur un wifi public intercepte la première requête non chiffrée. Un max-age d’au moins 180 jours est un minimum courant. N’activez HSTS que lorsque tout, y compris les sous-domaines que vous incluez, fonctionne en https : un navigateur qui a vu HSTS refuse ensuite http. La fiche KB 6752 explique comment le configurer.

Le contenu mixte (un script ou une feuille de style chargé en http sur une page https) est particulièrement dangereux sur la page de commande : c’est précisément ce type de fichier qui peut être remplacé en cours de route.

Card testing

Lors d’un card testing, des criminels utilisent votre boutique pour tester des numéros de carte volés. Ils passent automatiquement des centaines de petites commandes. Chaque paiement réussi leur indique qu’une carte fonctionne. Vous vous retrouvez avec une pile de commandes échouées, des frais par transaction, des rétrofacturations et, dans le pire des cas, un prestataire de paiement qui bloque votre compte.

Comment le repérer : beaucoup de commandes en peu de temps, souvent du même petit produit, avec des noms différents mais des adresses identiques ou étranges, et de nombreuses commandes au statut Échec.

Comment le limiter :

• La limitation du débit (rate limiting, une limite du nombre de requêtes par période). La Store API de WooCommerce, utilisée par les blocs panier et validation de commande, intègre une limitation du débit, mais elle est désactivée par défaut. Dans WooCommerce > Réglages > Avancé > Fonctionnalités, vous pouvez activer « Rate limiting Checkout block and Store API » pour la passation des commandes. Avec du code (un filtre), vous pouvez définir vous-même la limite ; par défaut, elle est de 25 requêtes par 10 secondes et seules les commandes et les autres actions d’écriture sont comptées. Si votre boutique se trouve derrière un proxy ou un CDN, la prise en charge du proxy doit être activée, sinon tous les visiteurs comptent comme un seul.
• Un captcha ou un obstacle comparable lors de la validation de la commande. WooCommerce indique lui-même que la limitation du débit et le captcha fonctionnent le mieux ensemble : les attaquants changent souvent d’adresse IP.
• Les réglages de votre prestataire de paiement. Les prestataires disposent de leurs propres filtres antifraude et limites. Activez-les et consultez ce qu’ils signalent.
• 3-D Secure (la confirmation supplémentaire dans l’application bancaire, qui fait partie de l’authentification forte du client dans l’UE) complique la tâche des criminels et, en cas de litige, transfère souvent la responsabilité à la banque du titulaire de la carte.

Autres fraudes

Toute fraude n’est pas automatisée. Voici des signaux qui, cumulés, justifient d’attendre un peu avant d’expédier :

• adresse de facturation et adresse de livraison dans des pays différents, ou adresse de livraison chez un service de réexpédition ;
• une première commande composée uniquement de produits chers et faciles à revendre, avec livraison express ;
• plusieurs tentatives avec des cartes différentes ;
• un client qui demande après le paiement d’envoyer le colis à une autre adresse.

Une rétrofacturation (chargeback) est l’annulation d’un paiement par carte par la banque du client. Vous perdez le montant, souvent avec des frais, et le produit est parti. Conservez donc les preuves d’expédition et de livraison. Un paiement iDEAL (Pays-Bas) ne pouvait jusqu’à présent pas être annulé de cette manière ; pour Wero, votre prestataire de paiement vous dira ce qu’il en est (leçon 4.4). En France, les moyens de paiement courants sont la carte bancaire (CB, Visa, Mastercard), PayPal, Apple Pay et le paiement en plusieurs fois.

Résumé

• Les données de carte n’entrent jamais dans votre boutique : ni dans des formulaires, ni dans des notes, ni dans des e-mails. Le prestataire de paiement les traite.
• La redirection vers la page de paiement ou un champ intégré du prestataire vous maintient dans le questionnaire PCI le plus léger (SAQ A) ; avec un champ intégré, votre page de commande doit être protégée contre les attaques par scripts.
• Gardez la page de commande dépouillée, en https avec une redirection 301 depuis http et un HSTS d’au moins 180 jours.
• Vous limitez le card testing avec la limitation du débit (désactivée par défaut), un captcha et les filtres de votre prestataire.
• Soyez attentif aux signaux de fraude et conservez les preuves de livraison contre les rétrofacturations.

Quiz

Exercice

Exercice A6.3 : Votre page de paiement est-elle sécurisée ? Saisissez l’adresse de votre boutique et l’adresse de votre page de commande. Le programme vérifie le certificat, demande la page de commande en http (sans suivre la redirection) et en https (avec un panier vide, rien n’est commandé). Vert si le certificat est valide, si http redirige vers https avec un 301 ou un 308, si l’en-tête Strict-Transport-Security a un max-age d’au moins 180 jours, s’il n’y a pas de contenu mixte et si cinq autres domaines au maximum chargent des scripts sur la page (le programme les affiche). Orange en l’absence de HSTS ou avec un HSTS trop court, en cas de redirection temporaire (302 ou 307), de plus de cinq domaines de scripts ou d’un gestionnaire de balises, ou d’un champ de numéro de carte dans votre propre HTML au lieu de chez le prestataire. Rouge si https ou le certificat ne sont pas corrects, si http ne redirige pas, ou si des scripts ou feuilles de style sont chargés en http. Ne stockez jamais vous-même de données de carte. Ce contrôle ne voit que ce qui figure sur la page sans panier.

Question pour vous-même (non corrigée) : votre extension de paiement redirige-t-elle vers le prestataire, ou le champ de paiement se trouve-t-il dans votre page ? Quel SAQ s’applique selon votre prestataire ?

Une coche verte signifie que ce contrôle est correct à cet instant, pas que votre boutique est sûre.

Pour aller plus loin

Les étapes dans un panneau s’appliquent à WebOké ; chez d’autres hébergeurs, le fonctionnement est comparable.

• Formation WordPress gratuite 3.1: Https et le certificat
• HSTS et en-têtes de sécurité pour votre site web
• Rediriger obligatoirement les visiteurs vers https
• Guide DirectAdmin 6.4: Rediriger toujours les visiteurs vers HTTPS
• Formation gratuite Sécurité en ligne pour les entrepreneurs 4.2: Votre site web : https, HSTS et en-têtes de sécurité
• Mises à jour du SAQ A (PCI Security Standards Council, en anglais) : https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Limitation du débit pour la Store API (developer.woocommerce.com, en anglais) : https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, en anglais) : https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/