Vous activez votre firewall en mode blocage, tout fonctionne parfaitement pendant des jours… et soudain un client vous écrit pour dire que son paiement par carte a échoué. Vous regardez les logs, et voilà : votre propre firewall a bloqué la requête de confirmation de Stripe ou PayPal, la prenant pour du trafic suspect. La vente est déjà perdue.
Pourquoi un firewall trop agressif peut casser les paiements sans que vous le sachiez
Les passerelles de paiement ne se contentent pas de rediriger le client vers leur site — beaucoup envoient des requêtes automatiques vers votre serveur (webhooks, confirmations asynchrones) pour vous signaler qu’un paiement a été effectué. Si votre firewall ne peut pas distinguer ces requêtes légitimes d’un bot quelconque, il peut les bloquer exactement comme il bloquerait une attaque — et vous ne le saurez que lorsqu’un client se plaindra ou que vous éplucherez les logs manuellement.
Pourquoi “autoriser tout ce qui ressemble à un paiement” ne suffit pas
N’importe qui peut prétendre être Stripe
Baisser la garde de façon générique — par exemple, autoriser toute requête mentionnant “stripe” ou “paypal” dans l’URL — est exactement le genre de faille qu’un vrai attaquant exploite, parce que ce type de texte est trivial à falsifier. La solution n’est pas d’assouplir le firewall, c’est qu’il reconnaisse avec certitude quand l’origine est vraiment la passerelle de paiement.
Confirmer l’origine réelle, pas ce que prétend être la requête
La différence, c’est de vérifier de façon fiable qu’une requête provient vraiment de la passerelle de paiement, plutôt que de faire confiance à ce que cette requête prétend être. C’est ce qui permet de laisser passer le trafic légitime sans ouvrir la porte à n’importe qui d’autre — sans avoir à baisser la garde de façon générique.
Pourquoi toutes les passerelles ne sont pas traitées de la même façon
Stripe, PayPal, Braintree et les autres ne fonctionnent pas toutes de la même manière en interne, et chacune a sa propre façon fiable de confirmer qu’une requête est vraiment la sienne. Appliquer le même critère à toutes de la même façon, au lieu d’apporter une protection solide, pourrait échouer au pire moment sans prévenir. C’est pourquoi SeenSecure adapte sa vérification à chaque passerelle plutôt que d’imposer une méthode universelle unique à toutes.
Une couche qui n’agit que lorsque c’est nécessaire
Cette vérification n’a de sens que lorsque le firewall est réellement en mode blocage actif — en mode observation seule, il n’y a rien à “laisser passer”, puisque rien n’est encore bloqué. C’est pourquoi cette couche est liée au mode de protection réel du firewall, plutôt que d’être un réglage indépendant que quelqu’un pourrait oublier de coordonner avec le reste.
Questions fréquentes
Comment savoir si mon firewall bloque déjà des confirmations de paiement sans que je le sache ?
Vérifiez le journal d’activité du firewall à la recherche de requêtes bloquées liées à votre passerelle de paiement — s’il y en a, c’est le signe le plus clair.
Cela signifie-t-il que n’importe qui peut se faire passer pour Stripe ou PayPal et contourner mon firewall ?
Non — le trafic n’est exempté de l’analyse que lorsque SeenSecure peut confirmer de façon fiable qu’il provient vraiment de la passerelle de paiement, pas simplement parce que la requête prétend l’être.
Dois-je configurer quelque chose si je ne vends rien par carte sur mon site ?
Non, cette couche n’a d’importance que si vous utilisez l’une de ces passerelles de paiement — si vous ne traitez aucun paiement en ligne, elle ne vous concerne absolument pas.