Sécurité des applications Web : l'architecture expliquée aux débutants

Ceux qui commencent à développer pour le web ont tendance à imaginer la sécurité comme quelque chose qui s'ajoute à la fin : un antivirus, un pare-feu, un plugin. C'est une image confortable et complètement fausse. La sécurité n’est pas un élément qui s’intègre dans le produit fini, c’est une propriété de la manière dont le produit a été construit.

La différence est fondamentale. Une application Web est comme une maison. Vous ne sécurisez pas une maison en installant une serrure coûteuse sur la porte d'entrée si les murs sont en carton et les fenêtres ne ferment pas. La sécurité vient de la structure et non d’un accessoire collé dessus.

Cet article explique, sans supposer de connaissances préalables, comment l'architecture d'une application web détermine sa sécurité. Il s'adresse aux débutants qui souhaitent comprendre les bonnes bases dès le début, avant de prendre des habitudes qui coûteront cher à défaire plus tard.

L'anatomie d'une application Web

Pour parler de sécurité, il faut d’abord comprendre les parties. En termes simples, une application Web comporte trois couches, et chacune a son rôle en matière de sécurité.

Le client est ce qui s'exécute dans le navigateur de l'utilisateur : les écrans, les boutons, ce que la personne voit et touche. Le serveur est l'endroit où se déroule la véritable logique, loin des yeux de l'utilisateur. Et la base de données est l'endroit où les informations sont stockées.

Entre ces couches, les données circulent à travers le réseau. Cette structure simple contient déjà la leçon de sécurité la plus importante pour les débutants, et c'est par là que nous commencerons.

La règle d'or : ne jamais faire confiance au client

Si vous vous souvenez d'un seul principe de cet article, rappelez-vous ceci : tout ce qui s'exécute dans le navigateur de l'utilisateur est sous le contrôle de l'utilisateur et peut donc être manipulé. Le client est un territoire ennemi.

Les débutants font l’erreur de placer des contrôles de sécurité sur le client. Ils valident le formulaire dans le navigateur, cachent un bouton à ceux qui n'ont pas l'autorisation, vérifient si la valeur est valide à l'écran. Tout cela est bon pour l’expérience utilisateur et absolument inutile pour la sécurité. Un attaquant ignore simplement l'écran et parle directement au serveur, envoyant ce qu'il veut.

La conséquence architecturale est claire : chaque décision de sécurité doit être prise sur le serveur. Validation des données, vérification des autorisations, règles métier, tout cela réside sur le serveur, où l'utilisateur ne peut pas accéder. Le client suggère : c'est le serveur qui décide. Cette séparation est l’épine dorsale de la sécurité Web.

Les deux piliers : qui vous êtes et ce que vous pouvez

Pratiquement toute sécurité applicative repose sur deux concepts que les débutants ont tendance à confondre.

L'authentification prouve qui vous êtes. C'est le login : nom d'utilisateur et mot de passe, peut-être un deuxième facteur. Il répond à la question « êtes-vous vraiment celui que vous prétendez être ? ».

Autorisation définit ce que vous pouvez faire une fois identifié. Il répond à la question « êtes-vous autorisé à faire cela ? »

La confusion entre les deux génère l’un des échecs les plus courants qui soient. Un système confirme la connexion (authentification) mais oublie de vérifier, à chaque action, si cet utilisateur a droit à ces données (autorisation). Le résultat est l'attaque classique consistant à modifier un numéro dans l'URL et à accéder aux informations de quelqu'un d'autre, une faille qui figure en tête des listes de l'OWASP depuis des années.

En architecture, cela signifie deux contrôles distincts. Confirmer son identité à l'entrée ne suffit pas. L'autorisation doit être vérifiée à chaque accès à une ressource. Oublier le second, c'est comme vérifier le badge de celui qui entre dans le bâtiment mais laisser toutes les pièces ouvertes.

Protection des données en transit et au repos

Les données d'une application existent dans deux états, et tous deux doivent être protégés.

En transit : les données circulent entre le client et le serveur sur le réseau. Ici, la protection est le cryptage de la communication, via HTTPS. Sans cela, n'importe qui sur un réseau partagé, un Wi-Fi public par exemple, peut intercepter et lire ce qui est transmis, y compris les mots de passe. HTTPS est aujourd’hui une norme basique et non négociable.

Au repos, c'est lorsque les données sont stockées dans la base de données. La protection la plus importante à comprendre pour les débutants est la gestion des mots de passe : ils ne doivent jamais être stockés au fur et à mesure que l’utilisateur les a saisis. Ils passent par un processus appelé hash, qui les transforme en quelque chose d'irréversible. Ainsi, même en cas de fuite de la banque, les mots de passe ne sont pas lisibles. Enregistrer les mots de passe en texte brut est peut-être le péché mortel le plus courant pour les débutants.

Les menaces classiques que l'architecture prévient

Certaines catégories d’attaques sont si courantes que tout débutant devrait les connaître par leur nom. Ils figurent sur la liste OWASP, la référence mondiale des risques applicatifs web.

L'injection se produit lorsque les données envoyées par l'utilisateur sont interprétées comme des commandes par le système. Le cas classique est l'injection SQL, où un champ de formulaire est utilisé pour tromper la base de données. La défense architecturale consiste à ne jamais mélanger directement les données utilisateur avec les commandes, en traitant toujours les entrées comme des données, jamais comme des instructions.

Le Cross-site scripting (XSS) se produit lorsqu'un code malveillant envoyé par un utilisateur finit par s'exécuter dans le navigateur d'un autre. La défense est de traiter et d'évacuer tout ce qui vient de l'extérieur avant de l'afficher à l'écran.

Le schéma commun de ces menaces est le même principe qu’auparavant : les données provenant de l’extérieur ne sont pas dignes de confiance et doivent être validées et traitées sur le serveur avant toute utilisation. L’architecture sécurisée est, dans une large mesure, une architecture qui se méfie systématiquement des entrées.

Réflexion pour ceux qui débutent

Le piège mental le plus dangereux du débutant est « mon projet est trop petit pour être attaqué ». C'est exactement le contraire. La plupart des attaques ne choisissent pas de cibles, ce sont des robots automatisés qui analysent Internet à la recherche de failles connues. Un petit projet mal protégé est précisément la cible la plus facile pour ces analyses. Personne n’a besoin de vouloir vous attaquer ; il suffit d'une porte ouverte trouvée par hasard.

Il y a aussi la dimension juridique que les débutants ignorent. Au Brésil, la LGPD rend responsables ceux qui collectent les données des personnes de leur protection, quelle que soit la taille du projet. Construire en toute sécurité dès le départ n'est pas seulement une bonne pratique technique, c'est une responsabilité juridique et éthique envers les personnes qui vous ont confié leurs données.

Vous n’avez pas besoin de tout maîtriser pour bien démarrer. Les fondamentaux architecturaux, ne jamais faire confiance au client, séparer l'authentification de l'autorisation, chiffrer la communication, protéger les mots de passe, valider toutes les entrées, placent déjà un débutant devant un grand nombre d'applications sur le marché. Au début, la sécurité consiste moins à utiliser des techniques avancées qu’à ne pas commettre les erreurs fondamentales que vous savez éviter.

Apprendre à dessiner en toute sécurité dès le premier projet est un investissement qui se rentabilise plusieurs fois. Reconstruire un système construit sans ces fondations est coûteux et douloureux ; le construire dès le départ n’est qu’une question d’habitude.

Si vous commencez à développer pour le Web et souhaitez bâtir sur de bonnes bases, il existe d'autres articles de blog sur l'authentification, l'OWASP, la LGPD et l'architecture sécurisée qui approfondissent chacun de ces points. Si c’est un moment d’apprentissage ou de prise de décision dans votre organisation, cela vaut la peine d’en parler.