Article d'utilité publique

Introduction

Nous construisons aujourd’hui plus de sites web et d’applications que jamais. Avec les outils modernes, dont les plateformes dites "no-code" (c’est le fait de créer des services sans coder, en se servant d’interfaces purement visuelles), n’importe qui (toute proportion gardée) peut lancer un service, une boutique en ligne ou une plateforme en quelques jours, ou quelques heures pour ceux qui aiment "jouer".

Une promesse de vitesse devenue l’argument de vente numéro un : "Pourquoi attendre des semaines alors que vous pouvez construire votre site en quelques clics ?".

Cette phrase, vous l’avez peut-être entendue pratiquement mot pour mot dans des publicités. C’est devenu un slogan, une mode.

C’est séduisant, bien sûr. Et pour beaucoup d’agences, cette rapidité est une aubaine : elles peuvent obtenir plus de projets, les concevoir plus rapidement, et donc avoir plus de clients et plus de revenus.

La productivité comme objectif

L’Ia et le no-code ont profondément transformé la manière dont on conçoit une prestation web : autrefois, la réalisation d’un projet impliquait beaucoup d’échanges, un investissement en temps conséquent, une forte implication du client, et nous mettions au monde un "bébé".

Aujourd’hui, la création de sites s’est en grande partie industrialisée, la production se standardise et beaucoup de prestataires affichent des temps de production records, parfois même garantis. Ce qui, du point de vue développeur, peut sembler suspect, puisque le travail de développement consiste avant tout à être confronté à des imprévus et à des bugs rarement linéaire.

Nous venons chercher notre site de la même manière que nous venons chercher notre voiture neuve une fois qu’elle a été préparée. C’est devenu une véritable chaîne de production.

La productivité est le terme le plus en vogue dans le secteur technologique. Tout doit aller le plus vite possible. C’est la course à celui qui saura créer une application en un temps record.

Sur les réseaux, certains développeurs se félicitent d’avoir développé une application en vingt minutes. À quoi cela rime-t-il ? Bonne question. Le plaisir de l’exploit technique, sans doute.

Le problème, c’est que cette formidable révolution (sur le papier) s’accompagne à coup sûr d’un danger silencieux : la sécurité.

Tout ce qui est compressé dans le temps finit par l’être aussi dans la réflexion. Et c’est là que les problèmes commencent.

Certaines personnes créent des systèmes qui manipulent des données sensibles, souvent sans vraiment comprendre les risques et surtout en les sous-estimant.

Pour prendre l’exemple du no-code (nous parlons d’une part très importante des sites modernes), les outils embarquent généralement des mécanismes de sécurité, mais le problème vient de la méconnaissance de leurs limites par les utilisateurs.

Résultat : les mêmes mauvaises pratiques se généralisent et engendrent à leur tour les mêmes types de failles. Et la sécurité web, déjà fragile de nos jours, se retrouve encore davantage malmenée.

Il en est de même pour les éléments de sécurité intégrés par certains "frameworks" (ce sont des outils conçus pour les développeurs, leur permettant de gagner du temps).

Ils sont en général très fiables car testés et approuvés par l’éditeur de la technologie lui-même, ils permettent d’aller très vite, ce qui peut pousser certains développeurs à faire des implémentations moins robustes en cas de simples copier-coller ou s’ils ne maîtrisent pas leurs bonnes pratiques d’utilisation.

Or, la robustesse en développement, c’est la base de tout. Les frameworks ne sont pas en cause : c’est leur utilisation non maîtrisée qui l’est.

Le marketing l'emporte sur la raison

L’artisanat est-il mort ? Non, mais il se raréfie. Le problème de fond ne vient pas du fait que des solutions existent pour gagner du temps (ce qui est excellent dans une certaine mesure), mais que la communication est loin d’être claire entre le prestataire et le client.

Aujourd’hui, dans bien des secteurs, le marketing a pris le pas, et souvent sur la raison. Dans celui du développement web, les principes de "cartes sur table" pour offrir au client un choix libre et éclairé ne sont pas systématiques.

Le no-code est clairement mis en avant, que ce soit au travers de son utilisation massive par les professionnels du secteur, ou des publicités sponsorisées jouant sur l’aspect "confort" recherché naturellement par l’être humain.

Nous nous trouvons dans un contexte où les risques ne sont pas toujours pesés. Et pourtant, aujourd’hui plus que jamais, l’aspect sécurité devrait être l’une des premières choses étudiées avec le client pour ensuite choisir une orientation technique.

Dans les faits, ces moments de discussion ne sont pas automatiques. Généralement parce que le client n’a pas un profil "informatique" et qu’il s’en remet au savoir-faire du prestataire. Mais il faut savoir aussi que le prestataire est parfois non ou mal éduqué sur l’aspect sécurité.

Le no-code ne doit pas être un automatisme

Dans cet article, nous vous le disons clairement et sans détour : le no-code n’est pas la solution automatique à choisir pour votre projet.

La solution doit être adaptée et définie stratégiquement en fonction de l’ampleur de celui-ci. Si vous ne pouvez pas en discuter avec votre prestataire, changez de prestataire.

Dans tous les cas, en développement web, se laisser séduire par des promesses de simplicité et de rapidité est une mauvaise idée. Ce n’est pas un choix stratégique, c’est une décision émotionnelle.

Là est tout le problème : L’utilisation du no-code est devenue si naturelle que c’est devenu une habitude quasi systématique chez certains professionnels.

N’oubliez pas : dès lors que vous avez un site web, vous êtes exposé. Vous avez des responsabilités, légales, et envers vos visiteurs et vos clients.

Même si votre prestataire peut avoir sa part de responsabilité en cas de faute, vous ne pourrez pas vous décharger entièrement de vos obligations : en tant que propriétaire du site, vous restez responsable.

Le décor étant planté, avec cette introduction longue (mais nécessaire), avant même de parler de techniques, il est donc essentiel de revenir à la philosophie même de la sécurité : la penser et la comprendre, pour prévenir les risques au mieux.

Définition d'un client

Tout d’abord, il faut savoir qu’un site web ou une application, c’est la face visible d’un projet. Dans notre jargon, nous appelons la partie que l’utilisateur voit et utilise, un "client" (on l’appelle aussi le "côté front").

Ce que vous voyez sur votre écran n’est qu’un assemblage de code et de fonctionnalités mis bout à bout et fonctionnant ensemble, pour au final ne faire qu’un.

Même si votre site est conçu via une plateforme no-code, il y a toujours du code derrière. C’est un assemblage de code qui permet de créer un site sans code... Dans tous les cas, derrière un site, il y a toujours du code.

Sur un échiquier, notre "client" serait l’équivalent du Roi : indispensable, mais très vulnérable. Il n’a aucune défense propre. Il peut bénéficier de certaines protections (imposées par le serveur (nous y viendrons juste après) ou le navigateur (Firefox, Chrome, Edge, etc.)) mais ce ne sont pas des défenses qu’il contrôle lui-même.

On pourrait dire que ce sont des protections qui lui sont imposées, mais celles-ci ne suffisent pas à elles seules. Notre Roi peut juste avancer ou reculer, aller de gauche à droite. En termes de sécurité, il n’est pas fiable : vous devez donc le protéger pour ne pas vous retrouver en "échec et mat".

Depuis ce "client", nous pouvons faire certaines vérifications et mettre en place des règles de validation, mais il faut garder à l’esprit qu’elles ne fonctionnent que si l’utilisateur agit de manière bienveillante, car elles peuvent être contournées ou désactivées par quelqu’un qui s’y connaît en développement.

Définition d'un serveur

C’est ici que nous entrons dans le cœur du sujet lorsque nous parlons de sécurité web.

Peut-être avez-vous l’intuition que la page du site sur lequel vous êtes est le point de départ, mais en réalité, c’est l’acteur central de la communication.

Littéralement, la page web vous est "servie" justement par un serveur (ou un système intermédiaire comme un Content Delivery Network (Cdn) ou un "cache". Nous verrons cela plus loin)

Oui, comme au restaurant ! En langage technique, pour que la page s’affiche quand vous tentez d’accéder à elle, votre navigateur envoie une "requête", dans la majorité des cas une requête GET (obtenir).

Le navigateur initie la communication avec le serveur, mais toute la chaîne de sécurité se passe côté serveur.

Pour notre allégorie de la forteresse (que l’on va voir un peu plus loin), nous considérerons le client (le navigateur) d’un site web comme la destination finale, car c’est là que le résultat est affiché et que le contenu devient visible. Cela simplifie la compréhension de la sécurité et des protections mises en place tout au long du trajet.

Sans le savoir, cette requête a traversé tout un tas de "couches réseau" et de mécanismes de sécurité, et ce sont ces "protocoles", validés un à un, qui vous ont donné l’accès à la page.

Et tout cela s’est produit en moins d’un battement de cil, sans que vous vous en aperceviez.

Dans notre quotidien, nous rangeons le serveur dans une jolie case que l’on nomme le "côté back". Ce côté back est un terme fourre-tout qui englobe énormément de choses, et pas seulement le serveur. Nous pourrions dire, en quelque sorte, que cela englobe tout ce que l’utilisateur ne voit pas, mais qui fait fonctionner le service.

Certaines vérifications sont refaites côté serveur à chaque requête afin de garantir la sécurité, tandis que d’autres informations peuvent être conservées côté client, comme un identifiant de session, via un cookie (cliquez sur ce lien pour comprendre l'origine et le fonctionnement des cookies).

La défense en profondeur (defense in depth)

À présent, vous êtes en mesure de faire une distinction globale entre le serveur et le client et de comprendre de manière simplifiée la logique d’interaction entre les deux.

Mais un site web ou une application, quand le service a été réfléchi, qu’il est bien conçu et sécurisé, ce n’est pas juste un serveur qui sert des pages à un client.

Il faut voir un service bien sécurisé comme une forteresse qui protège le serveur en son sein. Le Roi (le client), lui, vit une vie paisible à l’extérieur de la forteresse.

Dans une utilisation classique et bienveillante, toute requête envoyée par le Roi doit traverser la forteresse pour atteindre le serveur (même si certains systèmes (Cdn, cache, proxy (nous verrons cela très bientôt)) peuvent répondre avant d'y parvenir).

Vu du point de vue offensif, nous pouvons également dire que c’est en atteignant le serveur que l’on peut accéder aux données ou compromettre le service utilisé par le Roi. Dans les deux cas, la forteresse doit être traversée.

Il existe aussi des moyens de s’en prendre directement au Roi sans passer par la forteresse ni par le serveur, mais nous verrons ça vers la fin de cet article.

C’est justement parce que traverser cette forteresse peut être très simple par défaut, que nous allons ajouter des couches de protection entre votre requête et le serveur.

Nous ajoutons des "murs" internes, qui vont nous permettre de filtrer votre requête et la contrôler, avant qu’elle n’atteigne le cœur du système.

Autrement dit, nous faisons en sorte que votre requête n’ait pas qu’un seul mur à franchir pour atteindre le serveur. Chaque mur aura son rôle propre en termes de sécurité.

C’est ce que l’on appelle dans le jargon le principe de "defense in depth" (défense en profondeur). C’est-à-dire que si une couche est contournée ou échoue, les autres continuent à protéger le système.

Appliquer le "defense in depth" à votre service

Selon l’utilisation d’un site (les services proposés et utilisés), certaines couches de murs peuvent être inutiles, car le site en question peut tout simplement ne pas être concerné par certains cas de figure. Autrement dit, il peut ne pas être vulnérable à certains types d’attaques.

C’est justement de cela que nous vous parlions dans l’introduction.

Chaque projet nécessite une réflexion stratégique sur les risques. Ce sont précisément ces points qui doivent être discutés avec un prestataire, car selon ce que vous souhaitez faire de votre projet, il y aura une orientation technique appropriée.

Peut-être que l’utilisation que vous en aurez peut mettre le no-code hors-jeu d’emblée.

Peut-être aussi que le no-code sera pour vous le choix le plus judicieux, par exemple si vous souhaitez une simple page web (un "one page" dit dans le jargon), sans échanges de données utilisateur, avec juste une adresse mail pour vous contacter (c’est caricaturé mais c’est ce contraste idéologique qu’il faut avoir à l’esprit).

C’est ce parcours complet, de la requête du client jusqu’aux protections côté serveur, qui constitue l’essence même de la sécurité web. Comprendre ce fonctionnement est la première étape pour concevoir un site ou une application sécurisée.

La sécurité, c'est un métier

Attention, la sécurité, c’est sérieux, et c’est complexe. Il est nécessaire de prendre de la hauteur.

C’est un métier à part. Il existe des moyens de protection encore plus poussés que ceux que nous allons vous transmettre, il est même possible de mettre en place plusieurs périmètres de sécurité supplémentaires autour de notre forteresse. Il y a des entreprises spécialisées là-dedans et qui ne font que ça.

Vous pouvez en exiger beaucoup de la part de l’agence qui développe un service, mais ne vous mettez pas en tête qu’un développeur est un génie de la sécurité, ou qu’un professionnel de la sécurité est un développeur web.

Ce serait une erreur, car ce sont deux métiers très vastes et très différents, qui ne nécessitent pas les mêmes études. Nous sommes l’un ou l’autre, mais rarement les deux.

En revanche, si votre projet est lourd et complexe, vous pouvez tout à fait le concevoir avec un prestataire web et déléguer la sécurité avancée (que ne pourra pas gérer l’agence de développement) à une entreprise de cybersécurité. C’est ce que font beaucoup de grandes entreprises.

Ce que nous allons faire dans les lignes suivantes, c’est vous donner une vision globale de la sécurité d’un site ou d’une application, son fonctionnement vu de manière imagée (c’est important).

Nous allons vous donner matière à penser pour que vous puissiez "penser" la sécurité de votre infrastructure web et en discuter avec votre prestataire, que ce soit nous ou un autre.

Le plus important, c’est qu’à la fin de cet article, vous aurez compris un jargon employé très couramment dans le développement. L’apprendre par cœur ne sert absolument à rien, mais il est nécessaire de savoir en discuter si vous avez un projet web.

Nous disions un peu avant qu’un site peut ne pas être vulnérable à certains types d’attaques, et donc que certains éléments de sécurité peuvent être inutiles.

Sachez toutefois que tous les éléments de sécurité que vous allez voir dans les lignes qui suivent sont des principes que l’on pourrait dire "à ne pas manquer", et ce pour tout type de projet.

Nous vous transmettons ici des bases accessibles au public mais souvent sous-exploitées sur bien des sites modernes. Des bases qui ne sont pas systématiquement appliquées, alors qu’elles le devraient.

Pourquoi ne le sont-elles pas ? Parce que bien sécuriser un site, cela prend du temps et demande de la réflexion.

Allégorie de la forteresse

C’est parti. Nous avons exécuté une requête, puis avons été propulsés en dehors de la forteresse, et nous commençons par deux couches de défense parmi les plus courantes dans une architecture moderne bien conçue.

L’ordre peut changer selon la configuration, les besoins ou les fournisseurs utilisés (OVH, Amazon Web Services, Google Cloud Platform, etc.).

Toutes ne sont pas obligatoires, mais une partie d’entre elles est généralement installée d’office par les fournisseurs modernes (la "protection réseau", par exemple).

Ces deux couches interceptent les requêtes avant même que votre forteresse (votre site, votre application) soit atteinte. Elles appartiennent à ce que l’on nomme le côté "edge".

La protection réseau du fournisseur

Elle agit loin de votre forteresse. Ce sont des douves larges et profondes qui absorbent les attaques en volume, les tentatives de saturer votre site avec des requêtes faites en rafales (le terme technique est "DDoS" (Distributed Denial of Service).

Elle absorbe également les paquets malformés (c’est un morceau de données qui circule sur Internet, et il doit respecter un format strict pour être considéré comme valide).

Elle agit surtout au niveau réseau, avant même que votre serveur n’ait conscience de ce qui arrive.

Elle a d’autres avantages, mais ils sont globaux. Ce n’est pas qu’ils ne sont pas efficaces, mais simplement qu’il sera utile de les reprendre ailleurs, de manière plus précise.

Le CDN (Content Delivery Network)

C’est un réseau de serveurs répartis partout dans le monde. Ils gardent des copies de vos images, vidéos, fichiers ou "pages statiques", et les servent directement aux visiteurs.

C’est ce qui fait que votre site charge plus vite, que votre forteresse principale reçoit moins de monde directement, et que beaucoup de requêtes sont absorbées avant même d’arriver chez vous.

On peut imaginer ce réseau de serveurs comme des bastions avancés postés très loin de votre forteresse, capables de répondre aux visiteurs à votre place.

Ces bastions utilisent le "cache", c’est-à-dire qu’ils gardent temporairement une copie des contenus les plus demandés.

Grâce à ce mécanisme, le bastion peut répondre directement à une requête sans devoir revenir à la forteresse principale à chaque fois.

Plus le cache est efficace, moins votre forteresse est sollicitée et plus les visiteurs obtiennent rapidement ce qu’ils cherchent.

En somme, le Cdn et le cache travaillent ensemble : le Cdn est le réseau de bastions, et le cache est ce que chaque bastion garde à disposition pour accélérer les réponses.

Attention toutefois : les bastions avancés ne peuvent répondre que lorsque la demande concerne quelque chose de figé (une bannière, une image, une page publique, un fichier statique, etc.).

Mais si un visiteur demande quelque chose de personnalisé, de secret, ou nécessitant une vérification d’autorisation (l'accès à une page spécifiquement protégée, par exemple), le bastion ne peut pas deviner ce qui doit être renvoyé. Dans ce cas, il doit demander l'information directement à la forteresse principale.

À première vue, vous pouvez vous dire que tout cela à plutôt attrait à de la performance qu’à de la sécurité, mais le Cdn est bien un élément de sécurité à ne pas négliger.

En servant le contenu depuis le cache du Cdn, certaines requêtes n’atteignent jamais le serveur d’origine (le vôtre). Et moins de trafic vers le serveur, c’est moins d’opportunités pour les attaquants de trouver une faille dans le code de votre site.

Aussi, lorsqu’un site est visé par une attaque DDoS (trop de requêtes envoyées en même temps pour saturer le serveur), le trafic est absorbé et filtré par le réseau de serveurs du Cdn avant d’atteindre votre serveur. Ainsi, la forteresse principale (la vôtre) reçoit beaucoup moins de trafic malveillant.

Autre point, et peut-être l’élément le plus important lorsqu’on utilise un Cdn, c’est que sans lui, un attaquant voit directement l’adresse Ip de votre serveur et peut la cibler.

Avec un Cdn, les visiteurs (et potentiellement les attaquants) voient l’adresse Ip du Cdn, pas celle de votre serveur.

Beaucoup de serveurs n’ont pas leur adresse Ip camouflée, encore de nos jours.

Il existe des petites subtilités à connaître pour éviter que l'Ip de votre serveur fuite même avec l’utilisation d’un Cdn, mais en l’utilisant, c’est déjà une première couche de protection non négligeable.

Enfin, beaucoup de Cdn modernes intègrent un Web Application Firewall (Waf). Le Waf analyse les requêtes entrantes et bloque celles qui semblent malveillantes (les injections Sql ou Xss (nous verrons ça plus tard), et les bots malveillants).

Vous l'aurez compris, le Cdn ne sert pas qu’à stocker vos fichiers pour faire gagner de la vitesse de traitement à votre service, c’est aussi un véritable filtre.

Firewall réseau, Reverse proxy, et Load balancer

Nous commençons à présent à entrer dans ce que l'on nomme le côté "infrastructure".

Le "Firewall réseau" est un "pare-feu" qui protège la forteresse en filtrant le trafic réseau. Il décide quelles connexions sont autorisées ou bloquées (dans le cas présent on parle d'adresses Ip et de "ports"), pour entrer et pour sortir de la forteresse.

Le Reverse proxy, c’est la grande porte d’entrée de votre forteresse. Il peut aussi assurer des fonctions de Load balancing

Pour le trafic public, personne ne doit entrer sans passer par le Reverse proxy.

Après le filtrage du Firewall réseau, le Reverse proxy reçoit les requêtes des visiteurs, les oriente vers le serveur (ou vers le bon serveur quand vous en avez plusieurs) à l’intérieur et peut filtrer le trafic.

Parfois, il intègre lui aussi un Waf.

Le Load balancer est utilisé pour répartir le trafic (la charge) entre plusieurs serveurs et améliorer la disponibilité. Si vous n’avez qu’un seul serveur, il n’est pas nécessaire, mais le Reverse proxy reste utile pour la sécurité et la performance.

Le WAF (Web Application Firewall)

Vient ensuite un garde expert que nous avons déjà défini précédemment, car souvent intégré dans les premiers éléments de sécurité.

C’est un type de pare-feu, mais contrairement au Firewall réseau que l’on pourrait dire "classique", le Waf est spécialisé pour protéger le site ou l’application web. Son rôle est d’examiner chaque requête individuellement.

C’est lui qui reconnaît les tentatives d’injection Sql (c’est du code malveillant qui vise vos bases de données), les injections Xss (c’est généralement du code "JavaScript", malveillant et injecté dans une page web pour exécuter du code dans le navigateur d’un autre utilisateur), les requêtes anormales (des actions suspectes qui sortent du comportement normal d’un visiteur).

En bref, il détecte des signatures, des anomalies, des patterns d’attaque ou des comportements suspects.

On pourrait dire que c’est l’un des soldats les plus spécialisés de la forteresse.

L’avantage du Waf est qu’il filtre et bloque le trafic malveillant. Même si son rôle est très lié à l’application, son positionnement dépend de l’architecture : il est souvent placé côté Edge (notamment lorsqu’il est intégré à un Cdn), mais peut aussi être déployé au cœur de l’infrastructure.

Les middlewares

Après avoir franchi ces couches externes, la requête entre dans les couloirs internes. C’est le territoire où commence l’application elle-même, on le nomme dans le jargon le côté "applicatif". Nous avons quitté le côté "infrastructure".

Nous pouvons aussi dire que c’est ici que commence le travail de "codeur". On met dans nos middlewares toute une logique de contrôle, et on s’appuie (on "joue") sur le fait que notre requête n’a pas encore atteint la "logique métier" pour cela (oui, les middlewares s’actionnent avant).

Autrement dit : on commence à envoyer nos troupes de premières lignes, un peu comme un joueur mettrait certains de ses plus beaux atouts sur la table.

On peut vérifier plusieurs points avec un middleware :

• Êtes-vous authentifié ? ;
• Avez-vous le droit d’accéder à la page que vous demandez ? ;
• Le point de départ de votre requête (l’origine) est-il autorisé ? ;
• Vos données sont-elles valides ? ;
• Votre requête est-elle conforme aux règles prévues ? ;
• Etc.

Ces couloirs sont remplis de petites patrouilles qui interrogent, filtrent, guident. Elles veillent à ce que personne ne progresse sans respecter les règles. Si vous ne les respectez pas, votre requête est rejetée en force.

Les middlewares sont très bien connus des développeurs, nous nous en servons souvent pour lire et traiter des cookies par exemple (cliquez sur ce lien pour comprendre l'origine et le fonctionnement des cookies).

Si vous avez validé tous les points de contrôle, on injecte des éléments de sécurité dans le navigateur (une partie des fameuses protections imposées au Roi), éventuellement d’autres éléments propres à l’expérience utilisateur, puis on vous laisse passer.

La logique métier

Vous êtes à présent dans la salle centrale.

C’est ici que la requête est véritablement traitée, que l’on applique les règles fonctionnelles, que l’on décide quoi faire et comment répondre. Ici, nous agissons directement dans le code applicatif exécuté sur le serveur.

On décide comment réagir à tel ou tel comportement, en fonction de ce qui est envoyé par la requête. Par exemple, nous allons rejeter votre requête s’il manque un champ dans un formulaire que vous avez envoyé côté client (requête Post).

Littéralement, nous sommes ici au cœur de ce que l’on nomme la "programmation".

On décide de tout ce qui est à exécuter avant que le client reçoive la réponse définitive. Tout est traité dans l’ordre. Pour être tout à fait exact, selon la technologie utilisée, certaines tâches peuvent être asynchrones, mais ce n’est pas le sujet ici.

Cet ordre logique a un côté "robotique". Cela fonctionne comme un "algorithme" (une suite d’instructions systématiques permettant de traiter une requête de manière prévisible).

C’est aussi ici que nous communiquons avec la ou les bases de données. Par exemple, si votre adresse mail envoyée depuis le client ne correspond pas à celle renseignée en base de données, votre requête sera rejetée aussi.

Nous pouvons aussi vous empêcher de repasser dans cette salle après être venus nous voir un certain nombre de fois dans une période de temps donnée.

C’est ce que l’on nomme le "rate limiting", et c’est un élément très important en sécurité pour se prémunir des abus. Nous pouvons (nous devons) l’appliquer plus tôt, du côté edge et infrastructure, mais ça peut aussi être implémenté dans la partie applicative.

Le rate limiting n’est pas une option, c’est une obligation. Tout ce qui communique avec votre serveur doit être protégé contre les abus et le spam. Cela passe souvent par des limitations basées sur l’adresse Ip des utilisateurs, mais cela n'est pas suffisant en soi (nous verrons cela dans un prochain article).

Et enfin, une erreur dans le code de la logique métier (une mauvaise vérification, un mauvais ordre logique dans toutes ces opérations, un mauvais assainissement de données) et c’est une faille, une vulnérabilité qui peut être exploitée par un attaquant.

Ce sont notamment des erreurs dans cette partie applicative qui peuvent occasionner des vols de données au travers d’injections Sql.

Les bases de données

Enfin, derrière des portes massives encore plus intérieures, se trouvent les bases de données et les services privés.

C’est la chambre forte : vous n’y aurez jamais accès en tant qu’utilisateur lambda, à moins que le prestataire ait fait une erreur...

Peu de personnes y accèdent, et jamais directement.

Ce n’est pas la requête du visiteur qui entre ici, mais la requête interne générée par l’application après toutes les validations.

Ici, la moindre lacune d’authentification ou une validation insuffisante peut exposer les trésors les plus sensibles.

Les bases de données (Sql, NoSQL) ne sont pas des éléments de sécurité, mais le choix de celles-ci est vraiment très important.

Ce sujet doit être sérieusement abordé entre le client et le prestataire avant la première heure de travail consacrée à la réalisation d’un service, car selon l’ampleur de votre projet et la nature de vos données, il faudra s’orienter vers tel ou tel type de base de données.

Ne faire que du Sql pour le plaisir de ne faire que du Sql n’a pas de sens. Ne faire que du Nosql pour ce même motif n’en a pas non plus. Le choix d’une base de données doit être stratégique, décidé avec une vision à long terme.

Nous en parlons néanmoins dans les éléments de sécurité, car certains fournisseurs de bases de données proposent des sécurités avancées déjà intégrées dans leurs services, ce qui n’est pas négligeable et rajoute une couche de sécurité complémentaire quant aux risques d’injection.

Nous ne nous penchons pas ici sur la différence entre ces deux types de bases de données, simplement parce que ce n'est pas le sujet de cet article. De toutes les manières, ce questionnement se posera naturellement. La priorité se porte pour le moment sur les objectifs de votre projet.

Le Roi vous attend

Enfin, après avoir prouvé à plusieurs reprises, via votre requête, que vous étiez digne de confiance, vous avez obtenu la permission d’accéder à la cour du Roi (le client). Celui-ci vous attend, mais avec sa garde rapprochée (ses défenses injectées).

Littéralement, quand toutes les étapes ont été validées, le serveur envoie une réponse au client : un "code 200", comme pour dire "tout est OK".

C’est cette réponse qui permet au côté client d’exécuter certaines actions :

• Vous rediriger vers une page spécifique (chose que vous avez forcément déjà observée en vous connectant à un espace client) ;
• Afficher une petite "pop-up" selon le code reçu du serveur ;
• Etc.

En bref, on vous donne l’accès.

Vous êtes ensuite libre de circuler sur le site. Mais n’oubliez pas : c’est toujours le serveur qui contrôle l’accès aux ressources sensibles. Le client ne fait qu’afficher et interagir, mais ne détient pas de pouvoir de validation réel.

Enfin, au début de cet article, nous vous disions qu'il existe des moyens de s'en prendre au Roi sans passer par la forteresse ni même par le serveur, et c'est un fait.

Vous pouvez avoir sécurisé très largement votre forteresse et votre serveur, cela ne changera rien dans certains cas : l’ennemi contournera tout pour frapper directement celui qui se trouve à l’extérieur. Ou... vous.

C'est le cas notamment avec les célèbres attaques phishing qui visent à vous tromper. L'attaquant envoie une page imitant parfaitement la vôtre (une page de connexion, par exemple). La page paraît si réelle que vous y insérez vos identifiants ou données sensibles, et c'est fini. Il suffit d'une fois. Cette attaque est extrêmement répandue de nos jours.

Après avoir lu cet article, vous vous doutez bien que des services sont très bien sécurisés, et vous comprenez intuitivement la raison pour laquelle certaines personnes préfèrent tenter de s'en prendre à un service avec ce type d'attaque. Dans le cas présent, cela demande moins de réflexion voir aucune, puisqu'on joue sur la crédulité des gens, leurs faiblesses. C'est ce que l'on nomme l'ingénierie sociale.

Mais le phishing n’est qu’une des manières de viser directement le Roi.

Il en existe d'autres, comme l’environnement du Roi lui-même, par exemple un réseau Wi-Fi non sécurisé, un appareil infecté, ou un logiciel obsolète, qui peuvent tous permettre à un attaquant de contourner la forteresse sans jamais l’approcher.

Conclusion

La leçon que nous souhaitons transmettre dans cet article est la suivante :

Tous les projets, petits comme grands, doivent être sécurisés. Ils doivent simplement l’être de manière appropriée.

N’oubliez pas que la sécurité est stratégique, elle doit être adaptée à votre projet. Certains grands sites ou applications (plus que vous ne le pensez) n’ont pas de sécurités adaptées aujourd’hui.

Certains services (peu, mais ils existent) ne chiffrent pas les mots de passe. Autrement dit : un vol de données et c’est la boîte de Pandore.

La raison de ce manque de sécurité n’est pas "simple", mais elle suit une certaine logique :

Souvent, ces services ont été conçus il y a plus de 15 ans, à une époque où les risques semblaient moins tangibles. Depuis, le numérique a connu un véritable boom et s’est modernisé à une vitesse folle, tout comme les moyens d’attaque.

Beaucoup d’entreprises ont mis à jour leurs systèmes et sont aujourd’hui robustes, avec des mises à jour régulières, des correctifs et audits de sécurité, etc.

Mais d’autres restent piégées par des services vieillissants, coûteux à moderniser et tout autant à refaire.

Pour pallier ce problème, elles "bricolent" afin de gagner du temps. Une solution par-ci, une solution par-là, et "ça tient". Jusqu'au jour où elles ont l'obligation légale de déclarer une fuite de données à la Cnil, ou bien quand c'est la Cnil qui entre en contact avec elles, et là, fin de la récrée.

Pour finir, la sécurité, c’est un voyage, un processus continu, qui commence dès la conception du projet et qui doit être pensé à chaque étape. Ce processus doit être naturellement lent, réfléchi et progressif.

Chez PureKréa, nous allons au-delà des bonnes pratiques partagées dans cet article.

Les lecteurs les plus motivés pourront découvrir ces approches avancées dans un article privé.