Sécurité

Cette page décrit les mesures que StixFlow applique pour protéger les comptes, les identifiants et les données de paiement, ce qui reste de la responsabilité du marchand, et la manière de signaler une vulnérabilité. Elle décrit les pratiques en place à la date indiquée ci-dessus et ne constitue pas un engagement contractuel de niveau de service.

1. Données de paiement

Les numéros de carte et cryptogrammes sont saisis dans des composants contrôlés par le prestataire de services de paiement et lui sont transmis directement. Ils ne transitent jamais par les serveurs de StixFlow et ne sont pas conservés par StixFlow. StixFlow ne reçoit que le résultat du paiement et des informations limitées, telles que la marque de la carte et ses quatre derniers chiffres.

Les opérations de paiement sont exécutées par des prestataires de services de paiement agréés, qui maintiennent leur propre certification PCI DSS. Les marchands restent responsables de leur conformité PCI DSS au niveau applicable à leur propre intégration.

2. Chiffrement

• En transit. Tous les échanges avec le site, le tableau de bord, les pages de paiement et l’API utilisent HTTPS (TLS). Les requêtes HTTP sont redirigées vers HTTPS.
• Au repos. Les secrets récupérables, tels que les secrets de signature des webhooks et la copie scellée des clés API, sont chiffrés en AES-256 avec une clé conservée en dehors de la base de données.

3. Comptes et identifiants

• Les mots de passe ne sont jamais conservés en clair. Ils sont hachés avec Argon2id, un algorithme salé et coûteux en mémoire.
• Les clés secrètes d’API sont vérifiées par comparaison d’empreintes. Une copie scellée, chiffrée en AES-256, permet à un administrateur habilité de révéler une clé lorsque l’assistance l’exige ; chaque révélation est inscrite au journal d’audit.
• Les clés de test (sk_test_) et les clés de production (sk_live_) sont distinctes et ne peuvent pas être utilisées dans l’autre environnement.
• Les clés de production ne sont délivrées qu’après la vérification de l’entreprise et la signature du Contrat marchand par les deux parties.
• Les cookies de session ne sont pas lisibles par les scripts et les formulaires sont protégés contre les requêtes intersites falsifiées.

4. Cloisonnement des données des marchands

Chaque requête est exécutée dans le contexte d’un seul marchand. Les identifiants appartenant à un autre marchand sont rejetés au niveau applicatif. Les environnements de test et de production sont strictement séparés.

5. API et webhooks

• L’API est authentifiée par une clé secrète transmise en jeton porteur, depuis le serveur du marchand uniquement.
• Les requêtes de création acceptent une clé d’idempotence, afin qu’une nouvelle tentative ne crée pas de doublon.
• Chaque webhook est signé en HMAC-SHA256 sur un horodatage et le corps du message. Les marchands doivent vérifier la signature et rejeter les horodatages anciens.

6. Prévention de la fraude

Lorsqu’un marchand active Shield, chaque paiement fait l’objet d’un contrôle antifraude avant son autorisation, puis est approuvé ou refusé. Ce contrôle ne garantit pas la détection de toute fraude. L’authentification forte du client est appliquée par le prestataire de services de paiement lorsque la réglementation l’exige.

7. Journalisation et surveillance

Les événements applicatifs, les événements de sécurité et les actions administratives sensibles sont journalisés, en particulier toute révélation de la clé d’un marchand par un administrateur. Les journaux servent à détecter, analyser et résoudre les incidents.

8. Hébergement

La plateforme et ses bases de données sont hébergées dans l’Union européenne par OVH SAS, qui applique ses propres mesures de sécurité physique et réseau.

9. Incidents

Les incidents de sécurité sont évalués, contenus et documentés. Lorsqu’un incident affecte des données personnelles, les marchands concernés sont informés dans les meilleurs délais, comme le prévoit l’Accord de traitement des données, et l’autorité compétente est notifiée lorsque la loi l’exige.

10. Ce qui relève du marchand

• Garder secrets les clés API et les mots de passe, côté serveur uniquement, et les renouveler en cas de doute sur leur exposition.
• Ne jamais placer une clé secrète dans une page web, une application mobile ou un dépôt public.
• Vérifier la signature des webhooks avant de traiter un événement.
• Sécuriser ses propres sites, systèmes et accès du personnel.
• Signaler à StixFlow sous vingt-quatre (24) heures tout incident susceptible d’affecter le service, ses clés ou des données de paiement.
• Ne jamais transmettre une clé secrète de production par e-mail ou dans une demande d’assistance.

11. Signaler une vulnérabilité

Si vous pensez avoir découvert une faille de sécurité dans StixFlow, écrivez à [email protected]. Merci d’indiquer une description du problème, les étapes permettant de le reproduire et l’adresse ou le point d’accès concerné.

Nous demandons aux chercheurs d’agir de bonne foi :

• tester uniquement sur votre propre compte, et dans l’environnement de test chaque fois que c’est possible ;
• ne pas consulter, modifier ni supprimer de données qui ne sont pas les vôtres, et vous arrêter dès que vous en rencontrez ;
• ne pas dégrader le service : pas de déni de service, pas de scan automatisé massif, pas d’ingénierie sociale, pas d’intrusion physique ;
• nous laisser un délai raisonnable pour corriger le problème avant toute divulgation.

Nous accusons réception des signalements, tenons leur auteur informé des suites données, et n’engageons pas de poursuites contre une personne qui a respecté ces règles. StixFlow ne propose pas actuellement de programme de primes rémunéré.