Le 3-D Secure n'empêche pas un skimmer sur votre page
Le 3-D Secure authentifie le porteur chez sa banque. Le skimmer lit les champs sur votre page, avant. Ce n'est pas un argument pour dire « on est protégés ». Le HTML du checkout l'est, ou ne l'est pas.
3-D Secure authentifie chez la banque. Le skimmer lit les champs avant. Ce n'est pas un argument pour dire « on est protégés ». Le HTML du checkout l'est ou ne l'est pas.
Ce que 3-D Secure fait vraiment
3-D Secure (3DS2, « authentification forte ») fait valider le paiement par la banque émettrice : biométrie, app, SMS selon les cas. Ça réduit certaines fraudes « carte volée utilisée sur un site honnête ». Ça déplace la responsabilité (liability shift) dans beaucoup de schémas. Ça n'inspecte pas les scripts que VOTRE page charge. Ça n'empêche pas un overlay. Ça n'empêche pas une redirect vers une fausse page « 3-D Secure » qui n'est pas la banque.
Confondre « le client a eu un SMS banque » et « personne n'a lu sa carte chez nous » est l'erreur de briefing la plus fréquente auprès d'un assureur ou d'un PSP. PCI, Stripe.
Où le skimmer se place dans la chaîne
Le client tape sur votre checkout (ou croit le faire). Le JS pirate copie. Ensuite seulement, le flux peut appeler Stripe / la banque et déclencher un 3DS. L'authentification porte sur un paiement, parfois déjà précédé d'une exfiltration. Variante : pas de vrai paiement, juste la fausse page. Variante : paiement réel + copie — le client « a bien reçu sa commande » et découvre un débit ailleurs six semaines plus tard.
Iframe banque vs champs sur votre origine
Des champs hébergés (iframe PSP) rendent la copie plus difficile : le JS de votre origine ne lit pas facilement l'intérieur de l'iframe (sauf overlay, clickjacking, ou bug). 3DS n'est pas cette iframe. Vous pouvez avoir 3DS + champs en clair sur votre page (mauvais), ou iframe + 3DS (mieux pour la copie), ou redirect totale Checkout (encore une autre surface). Relisez ce qui s'affiche, pas le logo « 3DS » dans le footer.
Ce que 3DS change pour la fraude, pas pour la copie
Un attaquant qui a déjà le PAN + CVC peut souvent payer ailleurs, sur des sites sans 3DS ou avec exemption. Votre 3DS n'efface pas ce stock. D'où l'information clients « surveillez les relevés » même si « tous nos paiements étaient 3DS ». Que dire.
Phrases à retirer des mails clients et SAQ
« Protégé par 3-D Secure donc aucune carte n'a pu être interceptée ». « Authentification forte = site sûr ». « Liability shift = pas notre problème ». Remplacez par : le 3DS était actif / non ; le HTML du checkout a été relu ; voici la fenêtre. Un reviewer PCI connaît la différence. Un client, non : ne lui vendez pas une protection qu'il n'a pas eue.
Friction, exemption, et faux sentiment
Beaucoup de paiements sont exemptés (petit montant, TRA). « On a 3DS » ne veut pas dire que chaque client a vu un challenge. Même avec challenge, la copie amont tient. Ne comptez pas les exemptions pour rassurer un dossier skimmer.
Comment tester sans se raconter d'histoire
Parcourez le checkout, listez les scripts, les iframes, les hops d'URL jusqu'au challenge. Une carte de test PSP. Si un hop n'est pas le PSP / la banque, stop. Si un script inconnu écoute les inputs, stop. Le succès d'un paiement 3DS de test ne dit rien sur les scripts.
Ce qui protège réellement le tunnel
HTML maîtrisé (liste d'hôtes JS), champs ou redirect chez le PSP, employés et clés, pas de module nulled, caches propres après incident. Le 3DS reste utile contre d'autres fraudes : gardez-le, cessez d'en faire un bouclier Magecart. Créer un compte pour un audit de chaîne checkout.
- 3DS ≠ lecture du HTML.
- Chaîne d'URL jusqu'à la banque relue.
- Phrases « protégés par 3DS » retirées du dossier cartes.
- Tunnel PSP / scripts listés.
Liability shift : ce que ça ne paie pas
Le « liability shift » 3DS déplace une partie de la fraude carte vers l'émetteur, sous conditions (catégorie, exemption, données du message 3DS). Il ne paie pas votre SAV, ni un dossier CNIL, ni les avis Google, ni un SAQ plus dur. Il ne rembourse pas un client qui a saisi sa carte sur VOTRE page skimmée puis s'est fait débiter ailleurs. N'en faites pas le dernier paragraphe d'un mail clients.
Un PSP qui écrit « 3DS donc vous êtes couverts » parle de SON risque sur LESURS transactions. Votre HTML reste votre risque. Tenez les deux phrases dans le ticket, ne les fusionnez pas. PCI, Stripe.
Si vous passez en checkout entièrement hébergé (redirect) après l'incident, le 3DS continue d'avoir du sens contre la fraude classique. C'est un plus, pas un constat rétroactif sur la fenêtre skimmer.