La sécurité des paiements dans votre boutique en ligne : PCI, card testing et ce que fait votre hébergeur

Quiconque reçoit des paiements en ligne est concerné par les règles de sécurité des sociétés de cartes bancaires (PCI DSS), par des criminels qui veulent voler des données de carte et par le card testing : l'essai de cartes volées dans votre boutique. Cet article explique ce que cela signifie pour une petite boutique en ligne, ce que vous faites vous-même et ce que votre hébergeur règle ou non pour vous.

La règle principale : les données de carte n'arrivent jamais dans votre boutique

Un numéro de carte, la date d'expiration et le code de sécurité sont saisis par le client chez votre prestataire de paiement, pas dans votre propre boutique. Votre boutique est seulement informée si le paiement a été effectué. Cela signifie aussi :

• jamais de champ de formulaire personnel pour les numéros de carte, même pas pour une commande par téléphone ;
• ne jamais accepter de données de carte par e-mail, chat ou téléphone et les noter dans une commande ;
• pas d'extension qui conserve les données de carte dans votre propre base de données.

PCI DSS et SAQ A en termes simples

PCI DSS (Payment Card Industry Data Security Standard) est la norme de sécurité des sociétés de cartes bancaires ; la version actuelle est la v4.0.1. Une entreprise qui traite elle-même les données de carte doit respecter un ensemble conséquent d'exigences. Une petite boutique qui externalise entièrement le paiement démontre sa conformité au moyen d'un questionnaire court : le SAQ A (Self-Assessment Questionnaire A). Votre prestataire de paiement vous le demande parfois.

L'externalisation peut se faire de deux manières :

1. Redirection : après la commande, le client se rend sur la page de paiement du prestataire, puis revient.
2. Un champ de paiement intégré : le champ de paiement se trouve sur votre page de commande, mais il s'agit d'un fragment de page (iframe) du prestataire.

Depuis le 31 mars 2025, une nouvelle version du SAQ A est en vigueur. Toute personne utilisant un champ de paiement intégré doit y confirmer que son site n'est pas vulnérable à des attaques par scripts pouvant affecter le paiement. Les sites qui utilisent une redirection ne sont pas soumis à cette condition. Demandez à votre prestataire de paiement quel questionnaire correspond à votre intégration.

Protéger la page de commande

• Gardez la page de commande sobre. Tout script présent sur cette page peut en principe lire ce que le client saisit (e-skimming) : widgets de chat, gestionnaires de balises, pixels publicitaires. Ne chargez là que ce qui est nécessaire au paiement.
• Peu d'extensions, et toujours à jour. Les scripts malveillants s'infiltrent le plus souvent via une faille dans une extension ou un mot de passe administrateur volé.
• https partout, avec redirection du http vers le https et HSTS. Voir Rediriger obligatoirement les visiteurs vers https et HSTS et en-têtes de sécurité pour votre site web.

Reconnaître et limiter le card testing

Lors d'un card testing, des criminels passent automatiquement de nombreuses petites commandes pour voir quelles cartes volées fonctionnent. Vous le reconnaissez à un grand nombre de commandes en peu de temps, souvent pour le même produit bon marché, avec des noms variables et de nombreuses commandes au statut Échec. Cela vous coûte des frais de transaction et des rétrofacturations, et dans le pire des cas, votre prestataire de paiement bloque votre compte.

• La limitation de débit (une limite au nombre de requêtes par unité de temps). WooCommerce dispose de cette fonction intégrée pour les blocs de commande, mais elle est désactivée par défaut. Activez la dans WooCommerce > Réglages > Avancé > Fonctionnalités, option Rate limiting Checkout block and Store API.
• Un captcha lors de la commande. Les attaquants changent souvent d'adresse IP ; la limitation de débit et un captcha combinés fonctionnent le mieux.
• Les filtres antifraude de votre prestataire de paiement. Activez les et vérifiez ce qu'ils signalent.
• 3-D Secure, la confirmation supplémentaire dans l'application bancaire, complique l'usage frauduleux de cartes volées.

Ce que votre hébergeur fait, et ce qu'il ne fait pas

Réglé chez WebOké :

• Un certificat Let's Encrypt gratuit pour https
• HSTS est activé par défaut sur la plupart des serveurs
• Le pare-feu applicatif web (WAF) est activé par défaut et bloque les attaques connues
• Imunify360 contrôle immédiatement les nouveaux fichiers à la recherche de logiciels malveillants et analyse régulièrement votre pack
• Une sauvegarde de l'ensemble de votre pack chaque nuit, conservée 30 jours, dans un autre datacenter

Reste à votre charge (ou à celle de votre créateur de site) :

• Mettre à jour WordPress, WooCommerce, le thème et les extensions (Installatron peut le faire automatiquement, voir Mises à jour et mises à jour automatiques)
• L'intégration et les réglages antifraude chez votre prestataire de paiement
• Les scripts présents sur votre page de commande
• Des mots de passe forts et la double authentification pour les administrateurs
• La limitation de débit, le captcha et la vérification des commandes suspectes

Les logiciels que vous installez vous même, y compris via Installatron, sont sous votre responsabilité. Si votre site est tout de même piraté, suivez le plan d'action Mon site web a été piraté : plan d'action. Si une intrusion touche des données personnelles de clients, lisez aussi S'agit il d'une fuite de données et dois je la signaler ?

Pour en savoir plus

• Cours gratuit Sécurité en ligne, leçon 4.2 Votre site web : https, HSTS et en têtes de sécurité
• Le PCI Security Standards Council au sujet du SAQ A (en anglais)
• WooCommerce au sujet du card testing et de la limitation de débit (en anglais)