10 idées reçues sur la sécurité de votre plateforme web

Vous pensez que vos applications web et mobiles sont à l’abri des risques de piratage ? En êtes-vous sûr ? Voici notre top 10 des idées reçues sur la sécurité des plateformes web. Contactez nous si vous souhaitez échanger à ce sujet !

1. Les hackers ne s’intéressent qu’aux grandes entreprises

Nous entendons très souvent ces propos. Mais malheureusement, les hackers ne s’intéressent que très peu à la taille de votre entreprise : ils vont saisir toutes les opportunités qui se présentent à eux, quel que soit votre nombre d’employés ou votre chiffre d’affaire. Evidemment, les multinationales sont plus visibles et exposées, mais elles sont par conséquent mieux préparées à contrer les attaques. Les PME sont des cibles privilégiées, en raison notamment de leur manque de préparation. L’un de nos clients ayant un « petit » site de vente en ligne l’a appris à ses dépends lorsqu’il a constaté que tous les paiements effectués sur son site étaient redirigés vers un compte bancaire à l’étranger.

De plus, les données d’une PME peuvent être très intéressantes pour ses concurrents, ce qui peut aussi motiver des attaques.

2. Mes développeurs sont des rockstars

Les meilleurs développeurs produisent du beau code, sans bugs. Leur job est de développer des applications à la fois visuelles et performantes, dans des délais toujours plus resserrés. Mais ce ne sont généralement pas des experts en sécurité. Construire une plateforme et tester ses failles de sécurité sont des démarches bien différentes. D’où l’importance de faire conduire des tests d’intrusion, ce qui permettra aussi aux développeurs de monter en compétence sur le sujet sécurité, et qui peut être complété par des formations spécifiques sur le sujet.

A titre de comparaison, même la meilleure des peintures gagnera à être protégée par une couche de vernis!

3. J’utilise des frameworks solides, donc ma plateforme est sécurisée

Effectivement, mieux vaut utiliser des frameworks solides comportant une couche de sécurité. Cependant, il ne suffit pas de choisir un bon framework : tout dépend de comment celui-ci sera utilisé. Il n’est pas rare que des développeurs désactivent certaines protections incluses dans un framework afin de gagner du temps en évitant certaines contraintes. C’est pour cela que les tests sécurité restent indispensables.

hacker picture

4. Nous ne traitons pas de données sensibles, donc la sécurité n’est pas une priorité

Bien sûr, l’une des priorités en sécurité est de protéger les données les plus sensibles, telles que les données financières ou les données de santé. Mais la sécurité ne se limite pas à cela. Si par exemple vous gérez un site e-commerce, comment réagiriez vous en cas de site indisponible pendant 2 jours ? La réputation d’une entreprise est aussi un point crucial : une fuite d’informations que vous ne classez pas comme « sensibles » pourrait tout de même impacter la confiance de vos clients. Par exemple, une simple fuite d’adresses email et de mots de passe.

A cela s’ajoute que beaucoup de hackers piratent des sites internet pour pouvoir les utiliser comme des « zombies » lors de leurs futures attaques, ou pour héberger leurs activités illégales. Selon les législations en vigueur dans leur pays, les entreprises ont une responsabilité morale, voir légale, face à ces risques.

5. J’utilise déjà un pare-feu applicatif (WAF)

Les pare-feux applicatifs constituent une bonne protection pour les applications web. Cependant, malgré leur efficacité, ils ne peuvent pas constituer une garantie de sécurité. Les risques sont de 2 types : un hacker expérimenté pourra contourner un WAF; et le fait d’avoir un WAF peut conduire certaines entreprises à trop se reposer sur cette protection. Et malheureusement, ce laxisme pourra être exploité par des individus mal intentionnés.

6. J’ai déjà fait un pentest

Les technologies web évoluent en permanence. Les hackers le savent bien, et ont (presque) toujours un coup d’avance afin de pouvoir maintenir leur efficacité. Sécuriser une application web ou mobile est un processus continu. D’autant plus que toute nouvelle mise en production contient potentiellement de nouvelles failles et doit donc être testée. Les entreprises ayant un haut niveau d’exposition aux risques effectuent plusieurs audits de sécurité par an, avec par exemple des tests d’intrusion mensuels ou trimestriels.

7. Il n’y a pas de ROI avec les audits de sécurité

Il est possible de comparer un audit de sécurité à une assurance. Personne n’apprécie de payer son assurance auto, mais en cas d’accident, on comprend vite à quel point c’était nécessaire. Et dans une logique plus commerciale, les questions de sécurité prennent de l’importance du point de vue des clients. Prouver à ses utilisateurs que des mesures ont été prises pour protéger leurs données, par exemple avec un certificat d’audit, est un avantage compétitif. En effet, la confiance des clients se mérite.

C’est particulièrement le cas en B2B : la plupart des grands-comptes incluent un volet sécurité dans leurs appels d’offres, ou questionnent la sécurité des données lors de leur processus d’achat. Être pro-actif sur ces questions a un impact direct sur les ventes.

8. Je n’ai pas le temps de faire un audit de sécurité

Compte tenu des deadlines, des demandes clients urgentes, et des changements de dernière minute, il peut paraître compliqué de s’engager dans un projet de sécurité. Et pourtant, faire conduire des tests d’intrusion requiert certainement moins de travail de votre part que vous ne pourriez l’imaginer. Durant les tests, très peu d’implication est requise de votre part. A la suite des tests, un rapport détaillant les vulnérabilités identifiées ainsi que les correctifs à implémenter vous sera remis. Les failles sont classées en niveau de criticité, ce qui vous permet de prioriser leur traitement selon vos disponibilités. Libre à vous de fixer le calendrier des corrections, mais au moins vous êtes informé des risques et de l’éventuelle présence de failles critiques.

9. Il faut être naïf pour se faire avoir par un email de phishing

« Bonjour Monsieur. Je suis Maitre Antonin Leverheux, avocat professionel depuis 1999. Je suis désolé de vous aprendre que l’oncle de votre arrière grand-père a décéder avant hier. Etant son dernier héritiers, vous héritez de sa fortune de €500.000.000 ! Pour commencer la procédure d’héritage, merci de me faire parvenire un premier virement de €300.00 pour réglé les frais de dossier sur le comte suivant… ».

LOL. Nous avons tous reçu ce genre d’email, et il est difficile de tomber dans le panneau. Mais le phishing peut-être fait de façon beaucoup plus intelligente et même redoutable.

Via des attaques d’ingénierie sociale, un pirate peut facilement obtenir des informations lui donnant accès à un back-office ou un réseau interne, ouvrant ainsi la porte aux fuites de données. Par exemple, lors d’une attaque d’un site de réservation d’appartements, un pirate pourra viser le service client, dont les employés ont accès à beaucoup d’informations et sont trop rarement formés aux risques. Beaucoup d’entreprises sont victimes d’attaques d’ingénierie sociale, et pourtant les risques peuvent être considérablement réduits en améliorant les processus internes et en sensibilisant les équipes. Pour ces raisons, il est recommandé de conduire des campagnes d’ingénierie sociales afin de former ses équipes sur le sujet.

10. C’est trop cher

Les audits de sécurité ont un prix. Mais si l’audit est bien mené et que les tests sont adaptés au niveau de risque de votre plateforme, alors l’audit peut être considéré comme un investissement plutôt qu’un simple coût. Le degré de profondeur et d’exhaustivité d’un audit déterminent son coût, et doivent être adaptés à vos besoins. En effet, selon votre domaine métier, il ne sera pas forcément nécessaire d’imposer le même niveau de sécurité que pour une banque voire que pour le FBI.

Chez Vaadata, nous avons l’habitude de travailler avec des start-ups pour lesquelles le budget sécurité est limité. Nous leurs proposons des services abordables, et même une option de tarif variable selon le nombre de failles identifiées pendant l’audit de sécurité.