Web Security Basics Every Developer Must Know — txt1.ai

Par Marcus Chen, Ingénieur Sécurité Senior dans une entreprise fintech Fortune 500 avec 12 ans d'expérience dans le renforcement des applications web qui traitent plus de 2 milliards de dollars en transactions quotidiennes

Il y a trois ans, j'ai vu un développeur junior pousser du code en production à 16h47 un vendredi. À 18h15, notre centre des opérations de sécurité s'est mis à clignoter comme un arbre de Noël. Une vulnérabilité d'injection SQL dans une fonction de recherche apparemment innocente avait exposé 340 000 dossiers clients. La violation nous a coûté 4,2 millions de dollars en remédiation, amendes réglementaires et affaires perdues. Le développeur ? Un ingénieur brillant qui ne savait tout simplement pas ce qu'il ne savait pas sur la sécurité web.

Cet incident a changé ma façon d'aborder l'éducation à la sécurité. J'ai réalisé que la plupart des développeurs ne sont pas imprudents — ils opèrent simplement dans un vide de connaissances. Les programmes d'informatique passent peut-être deux semaines sur la sécurité, si vous avez de la chance. Les bootcamps l'ignorent souvent complètement. Pourtant, on s'attend à ce que nous construisions des forteresses tout en ne sachant que comment empiler des briques.

J'ai passé la dernière décennie dans les tranchées de la sécurité web, de l'analyse de pénétration à la création de frameworks de sécurité utilisés par des équipes de plus de 200 développeurs. J'ai vu les attaques évoluer d'essais de script-kiddie grossiers à des opérations sophistiquées d'États-nations. Et j'ai appris que les fondamentaux — les bases que chaque développeur doit internaliser — n'ont pas changé autant que vous le pensez. Maîtrisez ces principes fondamentaux, et vous empêcherez 90% des vulnérabilités que je vois dans le code de production chaque jour.

Comprendre la surface d'attaque : Ce que vous protégez réellement

Quand je demande aux développeurs ce qu'ils protègent, j'entends généralement "données utilisateur" ou "base de données." Ce n'est pas faux, mais c'est incomplet. Votre surface d'attaque est chaque point où votre application accepte des entrées, traite des données, ou interagit avec des systèmes externes. C'est le formulaire de connexion, oui, mais c'est aussi ce point d'accès API que vous avez écrit pour un usage interne uniquement, la fonction d'upload de fichiers dans le panneau d'administration, et même les messages d'erreur que vous affichez aux utilisateurs.

Permettez-moi de vous donner un exemple concret tiré de ma propre expérience. Nous avions un point d'accès API interne qui acceptait des charges utiles JSON pour des mises à jour massives d'utilisateurs. C'était "réservé aux internes" — aucune authentification requise car il n'était accessible que depuis notre VPN. Sauf que quelqu'un a mal configuré un proxy inverse, et soudain ce point d'accès était exposé à Internet pendant environ 18 heures avant que nous le remarions. Pendant ces 18 heures, des scanners automatisés l'avaient déjà trouvé et avaient tenté 2 847 vecteurs d'attaque différents.

La surface d'attaque comprend chaque dépendance dans votre package.json ou requirements.txt. Lorsque la vulnérabilité Log4Shell a été révélée en décembre 2021, j'ai passé 72 heures consécutives à aider les équipes à identifier et à patcher les systèmes affectés. La vulnérabilité n'était pas dans le code que nous avions écrit — elle était dans une bibliothèque de journalisation qui était une dépendance d'une dépendance d'une dépendance. Votre surface d'attaque s'étend à travers tout votre arbre de dépendance, ce qui, pour une application Node.js typique, peut inclure plus de 800 paquets.

Pensez aux frontières de confiance de votre application. Où les données non fiables entrent-elles dans votre système ? Chaque champ de formulaire, chaque paramètre d'URL, chaque en-tête HTTP, chaque cookie, chaque corps de requête API. Si cela vient de l'extérieur de la mémoire de votre serveur, c'est non fiable. J'ai vu des développeurs valider soigneusement les entrées des formulaires mais ignorer complètement les paramètres d'URL, ou assainir les données POST tout en laissant les paramètres GET largement ouverts. Les attaquants ne se soucient pas de votre modèle mental de ce qui est "censé" être validé — ils sondent tout.

Votre surface d'attaque comprend également les vulnérabilités basées sur le temps. Ce jeton de réinitialisation de mot de passe que vous générez ? S'il est prévisible ou n'expire pas, c'est un vecteur d'attaque. Identifiants de session, clés API, noms de fichiers temporaires — tout ce qu'un attaquant pourrait deviner ou forcer suffisamment longtemps. Une fois, j'ai trouvé un système où les jetons de réinitialisation de mot de passe étaient juste des entiers séquentiels. Un attaquant pouvait demander une réinitialisation pour son propre compte, voir le jeton 45231, puis essayer les jetons 45230, 45229, 45228 pour réinitialiser les mots de passe d'autres utilisateurs.

Validation des entrées : Votre première ligne de défense

Si je pouvais tatouer un principe sur le front de chaque développeur, ce serait ceci : ne jamais faire confiance aux entrées des utilisateurs. Pas l'entrée de votre application mobile. Pas l'entrée de l'API de votre partenaire "de confiance". Pas même l'entrée de votre propre JavaScript de front-end. Tout ce qui franchit une frontière de confiance doit être validé, assaini et traité comme potentiellement malveillant jusqu'à preuve du contraire.

Les vulnérabilités les plus dangereuses ne sont pas celles que les hackers découvrent — ce sont celles que les développeurs ne savent pas exister dans leur code jusqu'à ce qu'il soit trop tard.

Je vois des développeurs faire la même erreur encore et encore : ils valident les entrées sur le front-end et supposent que cela suffira. Voici la réalité — je peux contourner votre validation front-end en environ 15 secondes en utilisant les outils de développement du navigateur ou une commande curl simple. La validation front-end est pour l'expérience utilisateur, pas pour la sécurité. La véritable validation se produit sur le serveur, chaque fois, sans exception.

Une validation efficace des entrées a trois composants : vérification de type, validation de format et validation de logique métier. La vérification de type s'assure qu'un champ qui attend un nombre reçoit réellement un nombre, pas une chaîne contenant des tentatives d'injection SQL. La validation de format utilise des listes d'autorisation (pas de listes de refus) pour s'assurer que les données correspondent à des modèles attendus. Si vous attendez une adresse e-mail, validez contre une regex d'e-mail appropriée. Si vous attendez un numéro de téléphone américain, validez le format explicitement.

La validation de la logique métier est là où la plupart des développeurs cessent de penser. Ce n'est pas parce que quelque chose est techniquement valide que cela a du sens dans le contexte de votre application. Une fois, j'ai examiné du code où un panier de shopping permettait des quantités négatives. Le développeur avait validé que l'entrée était un entier, mais n'avait jamais vérifié si c'était positif. Un attaquant pouvait "acheter" -100 articles et recevoir un crédit au lieu d'être facturé. La correction était triviale, mais l'oubli a coûté à l'entreprise 23 000 dollars avant d'être découvert.

Voici mon approche pratique : définissez des schémas stricts pour chaque entrée que votre application accepte. Utilisez des bibliothèques de validation comme Joi pour Node.js, Pydantic pour Python, ou la validation intégrée dans des frameworks comme Laravel ou Django. Ces bibliothèques vous permettent de déclarer exactement à quoi ressemblent des entrées valides, et elles rejettent tout le reste par défaut. Lorsque la validation échoue, journalisez-le. Des échecs de validation répétés depuis la même adresse IP ou le même compte utilisateur peuvent indiquer qu'une attaque est en cours.

Un point encore critique : validez à chaque couche. Si les données passent de votre API à un travail en arrière-plan à une base de données, validez à chaque étape. J'ai vu des attaques qui exploitaient le fossé entre la validation API et le traitement des travaux en arrière-plan. L'API validait correctement l'entrée, mais le travail en arrière-plan supposait que les données étaient sûres parce qu'elles venaient de la base de données. Un attaquant qui pouvait écrire directement dans la base de données (via une vulnérabilité distincte) pouvait contourner toute validation.

Authentification et Autorisation : Savoir Qui et Quoi

L'authentification répond à la question "qui êtes-vous ?" L'autorisation répond à la question "que pouvez-vous faire ?" Confondre ces deux concepts, ou les mettre en œuvre de manière inadéquate, crée certaines des vulnérabilités les plus exploitables que je rencontre. J'ai vu des systèmes avec une authentification solide comme le roc qui laissaient n'importe quel utilisateur authentifié accéder aux données de n'importe quel autre utilisateur parce que l'autorisation était une réflexion après coup.