# Vérifier l’intégrité d’un connecteur Stripe sur un site de santé

> Avant d'installer un connecteur de paiement sur un site manipulant des données médicales, une checklist précise vaut mieux qu'une confiance aveugle envers le badge « vérifié ».

- Auteur : Clément Hadrot
- Publié le : 2024-04-12
- Mis à jour le : 2024-04-12
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/verifier-integrite-connecteur-stripe-site-sante/

## L’essentiel

- Vérifier l'auteur et l'historique du dépôt
- Examiner chaque permission demandée
- Isoler la clé API par environnement

Douze mille dossiers de patients, un formulaire de prise de rendez-vous en ligne et un module de paiement pour les consultations non remboursées : voilà le terrain sur lequel un connecteur Stripe mal choisi peut faire des dégâts. Sur un site de santé, l'extension qui relie WordPress à l'API de paiement ne touche jamais qu'un panier d'achat anodin. Elle côtoie des données couvertes par le secret médical, même indirectement, et un défaut de vigilance à l'installation coûte bien plus cher qu'un remboursement client.

La tentation est grande de se fier au nombre d'installations actives ou à une note moyenne flatteuse sur le répertoire officiel. Ces indicateurs ne disent rien de la qualité du code, ni des permissions réellement sollicitées auprès de l'API Stripe. Cette checklist détaille les points à vérifier avant d'activer un connecteur de paiement sur ce type de site, sans entrer dans la question de ses performances ou de son ergonomie.

## 1. Remonter à l'auteur et à l'historique du dépôt

Le nom affiché sur la fiche du répertoire WordPress.org ne suffit pas. Ouvrez la page du dépôt SVN ou, si l'auteur en fournit un, le miroir GitHub associé. Un connecteur sérieux affiche un historique de commits régulier, des messages de version cohérents avec le changelog publié, et idéalement une organisation identifiable plutôt qu'un pseudonyme isolé créé la veille de la publication.

Vérifiez aussi l'ancienneté du compte auteur sur le répertoire et le nombre d'autres extensions qu'il maintient. Un compte créé le mois précédent, avec une seule extension touchant à des flux financiers, mérite un examen supplémentaire avant toute installation en production.

## 2. Passer en revue chaque permission OAuth demandée

Lors de la connexion d'un compte Stripe à une extension WordPress, l'écran d'autorisation Stripe Connect liste précisément les portées demandées : lecture des paiements, écriture des remboursements, accès aux informations client, accès aux webhooks. Chaque portée doit correspondre à une fonctionnalité annoncée par l'extension.

1. Lecture seule des charges (`charge:read`) : nécessaire pour afficher un historique de paiement, rien de plus.
2. Écriture sur les remboursements (`refund:write`) : légitime seulement si l'extension propose un bouton de remboursement dans l'administration WordPress.
3. Accès aux informations client complètes : à questionner si l'extension se contente d'encaisser un montant fixe pour une consultation.

> L'essentiel à retenir : Vérifier l'auteur et l'historique du dépôt ; Examiner chaque permission demandée ; Isoler la clé API par environnement

## 3. Isoler les clés API par environnement

Une clé de test et une clé de production ne devraient jamais transiter par le même canal ni être stockées au même endroit sans distinction claire. Configurez les clés Stripe dans des constantes définies hors du dépôt de code, par exemple dans `wp-config.php` ou via des variables d'environnement injectées par l'hébergeur :

```
define( 'STRIPE_SECRET_KEY_LIVE', getenv( 'STRIPE_SECRET_LIVE' ) );
define( 'STRIPE_SECRET_KEY_TEST', getenv( 'STRIPE_SECRET_TEST' ) );
```

Cette séparation permet de révoquer une clé compromise sans toucher à l'autre, et d'auditer facilement laquelle a été utilisée lors d'un incident.

## 4. Contrôler la validation des webhooks entrants

Un connecteur Stripe digne de confiance vérifie systématiquement la signature des événements reçus via `Stripe-Signature` avant de déclencher la moindre action côté WordPress. Sans cette vérification, n'importe qui connaissant l'URL du webhook peut simuler un paiement réussi. Inspectez le code source de l'extension à la recherche d'un appel à la méthode de construction d'événement fournie par le SDK Stripe officiel plutôt qu'un simple décodage JSON de la requête brute.

Si le code n'est pas lisible facilement (fichiers minifiés, obfuscation), c'est en soi un signal d'alerte suffisant pour reporter l'installation le temps d'obtenir des explications de l'éditeur.

## 5. Cartographier les données transmises hors du site

Demandez-vous, poste par poste, ce que l'extension envoie réellement à Stripe : montant, référence de commande, adresse e-mail, adresse postale complète ? Sur un site de santé, même un intitulé de service (« consultation psychologique », « suivi addictologie ») transmis en clair dans la description d'un paiement peut constituer une donnée sensible si elle transite ensuite par des journaux ou des exports comptables peu protégés.

- Comparez les champs envoyés avec ceux strictement nécessaires à la transaction bancaire.
- Vérifiez si l'extension propose une option pour anonymiser ou généraliser le libellé de la prestation.
- Contrôlez où sont journalisés les échanges avec l'API, et pendant combien de temps.

> Sur ce type de site, la question à se poser n'est jamais « ce connecteur fonctionne-t-il ? » mais « que ferait-on si son code était compromis demain matin ? ». Si la réponse implique une fuite de données de santé, la checklist n'est pas terminée.

## En résumé

Un connecteur Stripe qui fonctionne correctement n'est pas nécessairement un connecteur sûr pour un site manipulant des données de santé. L'auteur, les permissions exactes accordées, la séparation des clés par environnement, la vérification des signatures de webhook et la nature des données transmises constituent cinq angles de contrôle indépendants les uns des autres. Aucun ne remplace les autres : une extension irréprochable sur les quatre premiers points peut encore transmettre des libellés de prestation trop explicites au cinquième. Cette checklist prend une vingtaine de minutes à dérouler, un temps négligeable face au coût d'un incident touchant des données médicales.