Intégrations sécurisées : Stripe, Shopify, Salesforce, webhooks

Définition

Une intégration sécurisée protège trois éléments : les identifiants qui donnent accès, les données qui circulent entre les systèmes et l'intégrité des événements métier qui déclenchent des actions. Les identifiants comprennent les clés API, les jetons OAuth et les secrets client ; ils doivent résider uniquement côté serveur, dans un gestionnaire de secrets ou une configuration d'environnement protégée, avec les autorisations les plus restreintes dont l'intégration a besoin. Les données en transit utilisent HTTPS, et les données au repos se limitent à ce que l'entreprise a réellement besoin de stocker. L'intégrité des événements repose sur la vérification que les webhooks entrants proviennent bien du fournisseur. Stripe, par exemple, signe les événements de webhook avec un secret de signature et fournit un en-tête de signature que votre endpoint doit vérifier ; Shopify signe les webhooks avec un en-tête HMAC ; les intégrations Salesforce reposent généralement sur OAuth via une connected app ou son équivalent plus récent, une external client app, avec des autorisations limitées. La fiabilité compte aussi. Les webhooks peuvent arriver en retard, plusieurs fois ou dans le désordre ; les gestionnaires doivent donc être idempotents, et les appels sortants doivent gérer les limites de débit et les nouvelles tentatives sans dupliquer les débits, les commandes ou les enregistrements. C'est pour cette raison que Stripe prend en charge les clés d'idempotence.

Public concerné

Ce guide s'adresse :

• Aux équipes qui connectent des paiements, des abonnements ou des parcours de paiement à leurs propres systèmes
• Aux entreprises e-commerce qui synchronisent commandes, stocks ou clients entre Shopify et d'autres plateformes
• Aux entreprises qui intègrent les données CRM de Salesforce à des outils internes ou à des portails clients
• Aux responsables produit qui examinent un travail d'intégration livré par une agence ou un freelance

Ce qu'il aide à clarifier

Passer en revue les contrôles aide à clarifier :

• Où sont stockés les identifiants, qui peut y accéder et comment ils font l'objet d'une rotation
• Si les endpoints de webhook vérifient les signatures et rejettent les requêtes non signées ou rejouées
• Comment les échecs, les nouvelles tentatives et les doublons sont gérés sans corrompre les données
• Quelles données sont copiées entre les systèmes, et si elles sont toutes nécessaires

Ce qui est inclus

• Conservez les clés API secrètes uniquement côté serveur ; utilisez des clés publiables ou publiques dans les clients lorsque le fournisseur le permet
• Stockez les secrets dans un gestionnaire de secrets ou une configuration protégée, jamais dans les dépôts de code source
• Demandez les scopes et autorisations les plus restreints ; utilisez des identifiants distincts pour chaque environnement
• Effectuez une rotation des identifiants selon un calendrier défini et immédiatement après tout changement de personnel ou de fournisseur
• Vérifiez les signatures des webhooks selon la méthode documentée par le fournisseur et rejetez les requêtes qui échouent
• Contrôlez l'horodatage des événements pour réduire le risque de rejeu, et enregistrez les identifiants des événements traités
• Rendez les gestionnaires idempotents afin que des événements répétés ne créent pas d'actions en double
• Utilisez des clés d'idempotence ou des protections équivalentes sur les opérations de création sortantes lorsque c'est possible
• Gérez les limites de débit avec un backoff et mettez le travail en file d'attente plutôt que de l'abandonner
• Journalisez les événements d'intégration sans consigner de secrets, de données de carte ni de données personnelles superflues
• Alertez une personne lorsque des tâches de synchronisation ou des webhooks échouent de manière répétée
• Testez dans les environnements sandbox ou les modes test du fournisseur avant de passer aux identifiants de production

Ce qui n'est pas inclus

• La validation de conformité PCI DSS ou l'approbation par un processeur de paiement
• Les opérations de lutte contre la fraude ou la gestion des rétrofacturations (chargebacks)
• L'affirmation que l'application de ces contrôles empêche tout incident d'intégration
• L'exploitation des plateformes tierces, qui reste sous la responsabilité des fournisseurs

Quand le choisir

Utilisez cette liste de contrôle lors de la conception d'une nouvelle intégration, avant la mise en production, lorsque vous héritez du code d'intégration d'une autre équipe, et après tout incident impliquant des paiements en double, des commandes manquantes ou un accès inattendu aux données. Elle est particulièrement importante lorsqu'une intégration peut déclencher des actions financières, comme des débits, des remboursements ou des modifications d'abonnement, ou exposer des fiches clients.

Notre approche

Traitez chaque intégration comme un petit produit, avec son propre responsable, sa documentation et sa surveillance. Commencez par un inventaire des intégrations, des identifiants et des endpoints de webhook ; de nombreuses organisations découvrent des clés dont personne ne se souvient de la création. Appliquez ensuite les contrôles ci-dessus par ordre de risque : les secrets et la vérification des signatures d'abord, puis l'idempotence et la gestion des échecs, puis la journalisation et les alertes. Notre service Secure Backend & API Engineering conçoit et livre des travaux de backend et d'intégration avec un contrat d'API, une synthèse des tests et un runbook d'exploitation, l'accès à la production et les données clients n'étant utilisés que sur autorisation écrite explicite. Lorsque la logique de paiement et d'abonnement est concernée, Subscription & Payment Infrastructure Security peut examiner séparément les parcours de paiement et de droits d'accès convenus. Si vous souhaitez une vérification indépendante des endpoints d'intégration existants, une revue de sécurité applicative peut les inclure dans son périmètre.

service Secure Backend & API Engineering

Foire aux questions

Articles connexes