Le guide essentiel de la sécurité des données pour les chefs de produit
Avez-vous entendu parler de Code Spaces ? Il s'agissait d'un référentiel de code source similaire à Github.
Eh bien, vous n’en avez probablement jamais entendu parler parce que, malgré un produit prometteur, ils ont disparu presque instantanément en juin 2014 après une énorme faille de sécurité. Cette brèche a entraîné la perte de toutes leurs données clients, les obligeant à cesser toute activité.
Après cet incident, tout le monde dans le monde numérique, y compris les chefs de produit, a retenu une leçon qui ne doit jamais être oubliée — LES PRODUITS DOIVENT ÊTRE SÉCURISÉS.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Dans ce guide, je vais vous introduire au monde de la sécurité produit et vous aider à garder la sécurité à l’esprit lors de la gestion de vos produits.
Pourquoi les chefs de produit doivent-ils se soucier de la sécurité des données
En théorie, votre gestion de produit au quotidien devrait se concentrer uniquement sur la rétention, les entretiens utilisateurs et d’autres aspects non techniques sans avoir à se soucier de la sécurité.
Cependant, nous vivons dans un monde peuplé de personnes mal intentionnées qui seraient ravies de voler vos données (pour les revendre ailleurs plus tard), les chiffrer, vous demander une rançon (c’est-à-dire un ransomware), ou tout simplement de nuire pour le plaisir de nuire.
Ainsi, au-delà de vos indicateurs d’activation et de rétention, vous devez aussi vous soucier de l’énorme risque commercial qu’un manque de sécurité fait peser sur votre produit. Une faille de sécurité suffisamment grave peut nuire à votre réputation à un tel point que toutes les années de dur labeur de vos équipes marketing, développement produit et ventes peuvent disparaître en une seule journée.
De plus, vous risquez de faire face à des poursuites judiciaires de la part de vos partenaires et clients dont vous n’avez pas su protéger les données.
À mon avis, il est donc essentiel que les chefs de produit soient « sensibilisés à la sécurité » lorsqu'ils conçoivent et développent leurs produits.
Les 4 failles de sécurité les plus courantes dans le développement produit
En tant que chef de produit, il n’est pas nécessaire d’avoir des connaissances approfondies sur les dernières méthodes de piratage et les moyens de s’en protéger. Ce sont vos équipes sécurité et ingénierie qui doivent mettre en œuvre et gérer ces aspects.
Toutefois, il vous faut une compréhension technique de base sur la façon dont fonctionnent certains des problèmes de sécurité les plus courants et comment des hackers peuvent en profiter. Cela rendra votre processus de décision plus « sensibilisé à la sécurité ».
Voyons ensemble quatre de ces failles de sécurité pour bien comprendre de quoi il s’agit.
1. Injection SQL
Quand j’étais un jeune chef de produit, j’ai décidé d’apprendre un peu le code et j’ai réalisé un petit (et affreux) script PHP qui servait de backend à un formulaire de contact sur un site web. Il recevait un message, l’enregistrait en base de données et composait un email destiné à moi avec son contenu.
Lorsque j’ai montré cela à un ami développeur, il a à peine pu contenir son amusement (mon code était tout simplement catastrophique), et il m’a demandé si j’avais fait la « sanitisation » de mes entrées. Comme vous vous en doutez, je n’avais aucune idée de ce qu’il voulait dire, et il m’a expliqué que mes bases de données étaient exposées à l’injection SQL faute de « sanitisation » des saisies.
L’injection SQL consiste pour un pirate à saisir du code SQL à la place d’un texte dans vos champs de saisie afin d’exécuter ce code dans votre backend et ainsi obtenir un accès non autorisé à votre produit ou voler des informations de vos bases de données.
Imaginez que LinkedIn utilise cette requête SQL pour vérifier votre mot de passe lors de la connexion (disclaimer : ils font évidemment quelque chose de plus intelligent que cette simple requête SQL).
Si, théoriquement, les champs de la page de connexion n'étaient pas « sanitisés », vous pourriez taper ' OR '1'='1 dans les champs nom d’utilisateur et mot de passe puis cliquer sur Se connecter.
Dans ce cas, le backend insérerait votre ' OR '1'='1 dans la requête SQL, qui deviendrait alors quelque chose comme ceci.
Cette requête renverra la valeur « true ». Cela signifie que vous pourriez vous connecter à LinkedIn sans disposer d’un nom d’utilisateur ni d’un mot de passe valide.
Comme je l’ai déjà mentionné, vous pouvez éviter ce problème en « sanitisant » vos saisies. La sanitisation, dans ce contexte, signifie que tout ce qui est saisi dans les champs de saisie est traité comme du texte ordinaire, même si vous entrez du code ou une requête SQL.
Avec des champs correctement « sanitisés », LinkedIn tentera de rechercher un utilisateur nommé ' OR '1'='1 dans la base de données au lieu d’exécuter le code. Il échouera et vous renverra une erreur signalant qu’il n’existe pas de tel utilisateur sur LinkedIn.
Se protéger contre les injections SQL est l’une des premières mesures à adopter pour garantir la sécurité des données de vos clients et éviter toute fuite ou accès non autorisé à ces informations.
2. Scripts intersites (XSS)
Le XSS est une autre méthode courante pour les hackers de manipuler votre produit et d’y agir de manière malveillante. Pour se rendre compte à quel point c’est fréquent, un rapport de Positive Technologies estime qu’environ 90 % de toutes les applications web sont vulnérables à ce type d’attaque.
Mais de quoi s’agit-il exactement ? Le XSS ressemble un peu à une injection SQL dans la mesure où des hackers manipulent votre système pour exécuter du code non prévu à l’origine. Toutefois, dans ce cas, le code malveillant ne s’exécute pas dans le backend ou les bases de données, mais bien dans le frontend.
Un des exemples amusants et inoffensifs de XSS est l’emoji cœur auto-retweeté de Twitter (oui, je continue à l’appeler Twitter—essayez donc de m’en empêcher). C’est amusant parce que personne ne s’attendait à une erreur aussi grossière de Twitter, et inoffensif parce que tout ce que ça faisait, c’était de se retweeter lui-même.
Cette attaque n’était qu’un simple tweet contenant le texte suivant.
Comme on peut le voir sur l’image, il ne s’agit pas de texte simple mais d’un morceau de code (Javascript avec jQuery, pour être précis) accompagné d’un émoji cœur à la fin.
Eh bien, avant que Twitter ne corrige cette faille de sécurité, si vous ouvriez ce tweet dans votre navigateur, le moteur de ce dernier reconnaissait son contenu comme du code valide, le cachait à l’utilisateur et l’exécutait. Ainsi, à la place de deux lignes de code, vous ne voyiez qu’un tweet avec un cœur.
Lorsque le code s’exécutait, il parcourait le HTML de la page, trouvait automatiquement le bouton retweet à l’écran et cliquait dessus.
Ce qui signifiait que toute personne voyant ce tweet le retweetait automatiquement — ce qui a infecté une grande partie des utilisateurs de Twitter.
Maintenant, imaginez qu’il ne s’agisse pas d’un tweet autorépétitif mais d’un script plus nocif, capable par exemple d’aspirer des informations confidentielles de votre écran pour les envoyer au hacker. Ou encore, un code malveillant sur votre navigateur pourrait prendre le contrôle de votre application de banque en ligne et commencer à transférer l’argent hors de votre compte.
Vous voyez l’idée — le XSS reste ultra dangereux même sans pouvoir accéder à vos serveurs ou bases de données.
Mais en quoi cela vous concerne-t-il en tant que chef de produit ? Il se peut que vous demandiez à vos ingénieurs de vous développer des fonctionnalités innovantes, comme permettre à votre site de visualiser le contenu d’autres onglets du navigateur de l’utilisateur et d’en faire quelque chose d’intéressant.
Si vous faites cette demande et que votre équipe refuse de réaliser cette fonctionnalité, ne soyez ni surpris ni déçu, car ce que vous demandez relève tout simplement d’une attaque XSS sur d’autres sites.
Le XSS est un domaine fascinant de la cybersécurité, et il existe de nombreux livres de référence à ce sujet. Mon préféré est XSS Attacks par Seth Fogie.
3. APIs non sécurisées
Les interfaces de programmation applicative (ou APIs) sont les moyens de communication entre votre serveur d’un côté, et le navigateur de l’utilisateur ou votre application sur leur appareil mobile/ordinateur de l’autre.
À chaque besoin d’obtenir, de stocker ou de traiter des données sur votre serveur, le navigateur ou l’appli (également appelés « clients ») envoie une requête au serveur avec les informations nécessaires. Le serveur exécute ensuite l’opération et renvoie une réponse.
Par exemple, lors de la connexion, les clients envoient vos identifiants (nom d’utilisateur et mot de passe) afin que le serveur vérifie votre identité. Lorsque la demande est traitée, le serveur renvoie un message de « succès » ainsi que le contenu de la page que l’utilisateur doit voir après connexion.
Puisque les APIs manipulent des données utilisateur, elles sont également sujettes à des vulnérabilités de sécurité qui peuvent entraîner une manipulation malveillante de données (par exemple demander au serveur d’effectuer un virement d’argent au nom de l’utilisateur) ou une fuite d’informations (comme demander au serveur de divulguer les dossiers médicaux de l’utilisateur).
Les types de vulnérabilités d’API les plus répandus sont :
Absence d’authentification : ici, l’API ne demande pas au client de prouver son identité avant de lui fournir des informations confidentielles. Pour illustrer la situation, imaginez que quelqu’un se rend dans une banque et demande à retirer de l’argent du compte de Mark Zuckerberk, et que le guichetier réponde simplement : « Bien sûr, combien ? »
Pas de limitation du taux : Ici, les API ne cessent pas de traiter les requêtes, même s’il y en a juste beaucoup trop—bien plus que prévu—ce qui peut surcharger votre serveur jusqu’à le faire tomber. Ce genre de flux massif de requêtes se produit quand quelqu’un tente de lancer une attaque DDoS sur vos serveurs.
Exposition excessive des données : Cela se produit lorsque les réponses de votre API contiennent des informations auxquelles vous ne souhaitez vraiment pas que les gens aient accès. Par exemple, en envoyant de l’argent à quelqu’un via la banque en ligne, supposons que la notification de l’API indiquant la réussite de la transaction comporte également le solde du compte du bénéficiaire, une information que vous ne devriez clairement pas voir.
Les solutions à ces trois vulnérabilités sont assez évidentes : demander une authentification pour les données sensibles, ajouter une limitation de taux, et s’assurer de ne servir que les données qui doivent l’être.
Si vous souhaitez approfondir la sécurité des API, vous pouvez consulter le livre de Neil Madden sur le sujet.
4. Manque de chiffrement
Mon responsable sécurité adore répéter qu’une bonne stratégie de cybersécurité pour un produit ressemble à un oignon—elle se compose de multiples couches de protection sur les différentes parties du produit.
Tout ce que nous avons évoqué jusqu’à présent concernait les risques de sécurité à la couche de surface, lorsque l’utilisateur ne peut pas accéder à vos serveurs ou bases de données et essaie d’attaquer « de l’extérieur ».
Cependant, si un hacker parvient tout de même à avoir un accès complet à vos serveurs (et franchit la première couche), vous devez malgré tout prévoir des mesures pour protéger vos bases de données contre leurs accès non autorisés—afin de garder les couches internes sécurisées elles aussi.
L’un des meilleurs moyens de protéger vos données, dans ce cas, est de les chiffrer. Cela signifie que même si quelqu’un accède à vos bases de données et télécharge ces données, ce ne sera pour lui qu’un charabia inexploitablre puisqu’il est chiffré.
Seule l’entreprise ou l’utilisateur—les deux parties possédant la clé de chiffrement—peuvent décrypter ce charabia pour obtenir des informations utiles. Malheureusement, oublier de chiffrer les données sur les serveurs est extrêmement courant et a déjà provoqué de nombreuses fuites massives de données.
J’ai personnellement vu trop de sites et de produits qui ont tenté le diable en stockant les mots de passe de leurs utilisateurs en texte clair—ce qui est considéré comme un péché capital en informatique. La bonne pratique consiste ici à faire passer le mot de passe dans un algorithme de hachage, à obtenir une version chiffrée (appelée hash), puis à stocker cela à la place.
Ce qui est intéressant, c’est que l’utilisateur et l’entreprise disposent tous deux de la clé permettant de retransformer le hash en texte clair afin d’utiliser ce mot de passe pour l’authentification. Mais, si un pirate accède à la base de données et télécharge le hash, revenir au mot de passe d’origine lui demanderait des millions d’années de calcul sans la clé. (Je ne plaisante pas, c’est le vrai chiffre !)
Le chiffrement est un autre domaine fascinant de la cybersécurité que je vous recommande vivement d’explorer. Vous pouvez notamment commencer par apprendre comment fonctionne la cryptographie à clé publique, sur laquelle repose aujourd’hui l’ensemble d’Internet.
Intégrer la sécurité applicative dans le cycle de vie produit et logiciel
À la lumière de toutes ces vulnérabilités et bonnes pratiques, concentrons-nous sur une question évidente que vous pourriez vous poser—comment puis-je garder mes produits sécurisés en tant que chef de produit ?
Je pensais que vous ne poseriez jamais la question ! Voici deux importantes bonnes pratiques de sécurité pour vous y aider :
Sécuriser les produits dès leur conception
Il s’agit d’une approche du développement qui stipule qu’il faut intégrer les exigences de sécurité dès le premier instant où vous commencez à concevoir vos produits, afin que les mesures de protection soient nativement intégrées dans votre code et votre architecture plutôt qu’ajoutées a posteriori dans le SDLC.
La seconde option est généralement beaucoup plus coûteuse et offre une protection moindre qu’un logiciel « sécurisé d’origine ».
Il est donc de votre responsabilité, en tant que chef de produit, de demander à votre équipe de développement de suivre cette approche et d’éviter de reléguer au second plan des éléments contribuant à la sécurité du produit.
More Articles
- L’IA dans la recherche utilisateur : comment l’IA transforme la compréhension des utilisateurs
- Livraison de produits pensés pour le global sans casse-tête mondial : comment intégrer la localisation dans votre workflow produit
- L’IA dans la planification de sprint : Comment l’IA améliore l’efficacité de l’équipe
Audits de sécurité réguliers
La majorité des produits que j’ai gérés étaient soumis à des tests de sécurité réguliers (généralement une fois tous les six mois à un an). Nous testions l’ensemble de la posture de sécurité, ce qui comprenait :
- Tests de pénétration
- Modélisation des menaces
- Revue des contrôles de sécurité
- Revue de la stratégie de sécurité et des fonctionnalités de sécurité
- Revue de la chaîne d'approvisionnement et des processus automatisés
- Analyse du code (y compris le code open source utilisé et le code obtenu via des partenariats tiers)
- Création de feuille de route de sécurité et de métriques
- Évaluation des risques
- ...et bien plus encore !
C'est important car votre produit évolue constamment, et vous pourriez accidentellement compromettre la sécurité de votre logiciel en ajoutant de nouvelles fonctionnalités. Des audits réguliers permettront d’identifier rapidement ces problèmes et de les corriger et valider avant qu’un acteur malveillant ne les découvre en premier.
En tant que chef de produit, votre rôle est de prévoir du temps et de donner la priorité à ces audits et aux opérations de nettoyage du code qui en découlent.
Faites confiance à vos experts en sécurité
Quelle que soit la fonctionnalité que vous envisagez de développer et quel que soit le plan d’action pour atteindre vos objectifs de croissance, pensez toujours à valider vos idées auprès de votre équipe sécurité.
Et écoutez bien—il peut vous sembler que les spécialistes de la sécurité veulent "surprotéger" votre produit. Cependant, la plupart du temps, s’ils ne valident pas votre idée, vous devriez envisager d’y apporter des modifications. Sinon, le risque n’en vaut pas la peine.
Et puisqu'on parle d’y réfléchir, pensez aussi à vous abonner à notre newsletter pour recevoir de nombreux guides et articles sur la gestion de produit directement dans votre boîte de réception !
