Sécurité dans les applications web : les fondamentaux que personne ne peut ignorer

Chaque application web est, en pratique, une porte ouverte sur le monde. Vous pouvez crocheter la serrure ou laisser la clé sous le tapis. La plupart des équipes, sans s’en rendre compte, choisissent la deuxième option, non pas par incompétence, mais parce que la sécurité est rarement considérée dès le départ comme une exigence.

La question que je pose à n’importe quelle équipe est simple : si un attaquant décidait de vous attaquer aujourd’hui, combien de temps cela prendrait-il ? La réponse honnête est souvent inconfortable. Et le problème n’est presque jamais le manque de technologie. C'est un manque de fondement.

Cet article porte sur ces bases. Il ne s’agit pas d’un outil à la mode, mais des principes qui sous-tendent une application Web digne de confiance.

Pourquoi la sécurité est devenue un problème business

Il fut un temps où la sécurité était un sujet réservé à l'équipe d'infrastructure. Aujourd’hui, c’est un problème de PDG, de conseil d’administration et de réputation.

Une fuite de données n’est pas qu’un bug. C'est un titre, c'est une amende, c'est un client perdu. Au Brésil, la LGPD a eu des conséquences concrètes pour ceux qui traitent les données personnelles avec négligence. Mais même sans réglementation, le coût d’un incident a toujours été élevé, il n’en est que devenu plus visible.

Le fait est que la sécurité n’est plus un détail technique mais est devenue une variable métier. Ceux qui dirigent des produits ou des technologies doivent comprendre cela pour décider où investir.

La thèse : la sécurité est une architecture, pas un vernis

Ma position est simple. La sécurité n'est pas une couche que vous ajoutez une fois le produit prêt. C’est une propriété qui émerge des décisions que vous prenez dès le début.

Les équipes qui considèrent la sécurité comme une tâche finale, un examen avant le lancement, un test d'intrusion hâtif, ne font qu'acheter l'illusion de la protection. Le test du stylo détecte les symptômes. L'architecture définit si la maladie existe.

Lorsque la sécurité est fondamentale, elle apparaît dans la façon dont vous modélisez les données, dans la façon dont vous authentifiez les utilisateurs, dans la façon dont vous faites confiance (ou vous méfiez) aux entrées. Lorsqu'il est vernis, il apparaît dans un rapport que personne ne lit.

Les fondamentaux qui comptent vraiment

Je serai pragmatique. Il existe des dizaines de sujets possibles, mais quelques principes fondamentaux résolvent la plupart des problèmes réels.

Ne faites jamais confiance aux entrées des utilisateurs

La plupart des vulnérabilités classiques, injection SQL, cross-site scripting, manipulation de paramètres, sont nées de la même erreur : faire confiance à des données qui viennent de l'extérieur.

La règle est simple et non négociable : toute entrée est hostile jusqu'à preuve du contraire. Validez sur le serveur, toujours. La validation dans le navigateur est une question d'expérience utilisateur, pas de sécurité, elle est trivialement contournable.

Utilisez des requêtes paramétrées dans la base de données. Sorties d'échappement en fonction du contexte. Traitez les téléchargements de fichiers comme du code potentiellement malveillant. Ces précautions semblent évidentes, mais elles continuent d’être à l’origine d’incidents qui font l’actualité.

L'authentification et l'autorisation sont des choses différentes

L'authentification répond "qui êtes-vous". L'autorisation répond "que pouvez-vous faire". Confondre les deux est une recette pour un désastre.

L'erreur la plus courante que je vois : des applications qui vérifient si l'utilisateur est connecté, mais ne vérifient pas s'il est autorisé à accéder à cette ressource spécifique. Le résultat est le problème classique dans lequel l'utilisateur A peut voir les données de l'utilisateur B simplement en modifiant un nombre dans l'URL.

L'autorisation doit être vérifiée sur le serveur, à chaque demande sensible, jamais supposée en fonction de ce que l'interface affiche. Cacher un bouton ne protège rien.

Gérer les secrets en tant que secrets

Mots de passe, clés API, jetons d'accès. Ces données n'ont pas leur place dans le code source, elles n'ont pas leur place dans le référentiel et elles n'ont certainement pas leur place dans un fichier de configuration versionné.

Les mots de passe des utilisateurs doivent être stockés avec des algorithmes de hachage conçus à cet effet, et non avec un cryptage réversible, et encore moins en texte brut. Utilisez des bibliothèques consolidées. Le cryptage fait maison est l’un des moyens les plus rapides de créer un problème que vous ne détecterez que lorsqu’il sera trop tard.

Le cryptage en transit n'est pas facultatif

Tout le trafic doit utiliser HTTPS. Il n’existe aujourd’hui aucune justification raisonnable pour justifier le contraire. Les données qui voyagent sans cryptage peuvent être interceptées, y compris les informations d'identification.

Mais attention : HTTPS protège le chemin, pas la destination. Une application peut avoir un verrou vert dans le navigateur tout en stockant les mots de passe en texte brut. Le chiffrement en transit et au repos sont des couches distinctes, et les deux sont importants.

Ce que l'OWASP nous apprend

Quand quelqu’un me demande par où commencer, ma réponse est presque toujours la même : commencer par OWASP.

Le Top 10 OWASP est une liste des vulnérabilités les plus critiques dans les applications Web, maintenue par la communauté et mise à jour périodiquement. Il ne s’agit pas d’une norme bureaucratique, mais d’une cartographie des menaces qui causent réellement du tort.

Sa valeur ne réside pas dans la mémorisation de la liste, mais dans son utilisation comme langage commun au sein de l’équipe. Lorsque tout le monde comprend ce qu’est un contrôle d’accès défaillant ou une configuration de sécurité défaillante, les conversations techniques deviennent plus objectives et les décisions plus éclairées.

Je recommande d'intégrer le Top 10 au processus : un examen léger mais cohérent qui demande "sommes-nous exposés à l'un de ces risques ?" avant chaque livraison concernée.

Des erreurs culturelles qui sabotent la sécurité

La partie la plus difficile de la sécurité n’est pas technique. C'est culturel.

La première erreur est de considérer la sécurité comme la responsabilité d’une seule personne ou d’une équipe isolée. La sécurité relève de la responsabilité de ceux qui écrivent le code, de ceux qui conçoivent les produits et de ceux qui priorisent le backlog. Quand cela devient le travail de quelqu’un, cela ne devient le travail de personne.

La deuxième erreur est le théâtre de sécurité : des politiques étendues que personne ne suit, des processus qui existent dans le document mais pas quotidiennement. La vraie sécurité est discrète et opérationnelle, pas un manuel dans un tiroir.

Le troisième, et peut-être le plus dangereux, est le faux sentiment que « cela ne m’arrivera pas ». Les petites applications sont constamment attaquées, souvent par une automatisation qui ne choisit pas de cible. Être petit n’est pas une protection.

La sécurité comme un avantage, pas comme un coût

Il existe une meilleure façon de voir tout cela. Une sécurité bien faite n’est pas seulement une défense, c’est une différence.

Dans les secteurs qui traitent des données sensibles, comme la santé, la finance et le secteur public, la confiance est une monnaie d'échange. Un produit qui prend soin des données obtient un avantage sur un concurrent qui traite le sujet avec mépris. Pour les gestionnaires publics, c’est encore plus critique : les données citoyennes ne sont pas un atout de l’organisation, c’est une responsabilité.

Investir dans les fondamentaux de la sécurité n’arrête pas l’innovation. Au contraire, cela vous donne une base solide sur laquelle vous pouvez construire rapidement sans craindre que tout s’effondre.

La sécurité n’est pas une chose que l’on fait quand on a le temps. C'est ce qui détermine si le produit que vous créez mérite d'exister.

Si votre organisation développe des applications Web et que la sécurité est encore un sujet laissé pour compte, cela vaut la peine de revoir cette priorité. J'ai d'autres articles sur le blog sur LGPD, la cryptographie et l'architecture sécurisée, et je suis toujours ouvert à échanger des idées avec quiconque prend ce sujet au sérieux.