Un développeur m'a envoyé un message à 23h un mardi : « quelqu'un vient de vider la table users de notre prod ». Verdict le lendemain matin, une injection SQL trois lignes plus bas dans le formulaire de contact. La chaîne de connexion traînait dans un fichier .env à la racine du dépôt. Le truc n'avait rien d'un scénario de film. Et c'est justement ça qui fait mal : sécuriser une application web contre les failles, ce n'est presque jamais un problème de génie. C'est une somme de petites décisions prises tôt, ou pas prises du tout.
Je vais être direct : la plupart des brèches que je croise dans mon travail pourraient se résumer à cinq négligences qui reviennent en boucle. Pas des zéros days exotiques. Des choses que vous pouvez corriger cette semaine si vous savez où regarder. Voyons lesquelles, et surtout comment.
Points clés à retenir
- La majorité des attaques réellement observées visent des failles connues depuis des années : injection SQL, XSS, mauvaise gestion des sessions.
- Un pare-feu réseau ne protège pas votre application : une requête malveillante bien formée passe par le port 443 comme n'importe quelle autre.
- La validation doit se faire côté serveur. Toujours. Le JavaScript côté client est un confort, jamais une défense.
- Les en-têtes HTTP de sécurité (HSTS, CSP, X-Content-Type-Options) coûtent une ligne de configuration et bloquent des familles entières d'attaques.
- Aucune contre-mesure ne remplace le principe du moindre privilège : votre base de données ne devrait jamais avoir le droit de faire plus que nécessaire.
Sécuriser une application web commence par nommer les failles
La question qu'on me pose le plus souvent, dans les conférences ou par mail, c'est simplement : « Comment puis-je sécuriser une application ? ». Et à chaque fois je réponds la même chose. On ne sécurise pas « une application » dans l'abstrait, on sécurise des points d'entrée précis contre des classes d'attaques précises. Tant que ces deux colonnes ne sont pas écrites noir sur blanc, vous pilotez à l'aveugle.
Voici le tableau que j'utilise en audit, à peu près tel quel. Il tient sur une page et il a rendu plus de services que n'importe quelle documentation que j'ai lue.
| Faille | Mécanisme | Contre-mesure technique |
|---|---|---|
| Injection SQL | Une entrée utilisateur est concaténée dans une requête et interprétée comme du code | Requêtes paramétrées (requêtes préparées), jamais de concaténation de chaînes |
| XSS | Du script injecté s'exécute dans le navigateur d'un autre utilisateur | Échappement contextuel à l'affichage + en-tête Content-Security-Policy |
| CSRF | Le navigateur d'une victime connectée envoie une requête non désirée à votre site | Jeton anti-CSRF unique par session, attribut SameSite sur les cookies |
| SSRF | Le serveur est forcé d'appeler une URL interne (métadonnées cloud, réseau privé) | Liste blanche de domaines autorisés, blocage des plages IP privées |
| Session mal gérée | Identifiant prévisible, jamais renouvelé après connexion, transmis en clair | Régénération de session à l'authentification, cookie HttpOnly + Secure |
| Désérialisation non sécurisée | Un objet forgé par l'attaquant déclenche du code au moment de la reconstruction | Refuser les formats binaires externes, valider le schéma avant reconstruction |
Ceux qui ont bossé sur des applications web reconnaîtront des noms familiers. Et c'est tout le problème : ces failles ne sont pas nouvelles, elles sont anciennes et toujours exploitées. L'attaquant ne cherche pas l'élégance. Il cherche la porte non verrouillée.
Pourquoi un WAF ne suffit jamais
On me vend souvent la protection périmétrique comme solution complète. Un pare-feu applicatif, une liste de blocage d'IP, une limitation de débit. Franchement, ces outils ont leur place — mais ils filtrent des signatures, pas de la logique métier.
Je me souviens d'un test où j'ai contourné un WAF en une après-midi. Pas par talent, par paresse du configurateur : la règle bloquait le mot-clé union select mais pas sa version encodée. Le WAF a laissé passer trois requêtes d'affilée avant que je n'arrête. Le correctif n'a pas été de renforcer le WAF. Il a été de passer à des requêtes paramétrées. La vraie protection se trouve dans le code, pas devant lui.
Les défenses techniques qui tiennent vraiment
Trois volets, dans cet ordre d'impact : les entrées, les en-têtes, les secrets. Si vous ne faites que ces trois-là correctement, vous éliminez déjà la majorité de ce que je vois passer.
Valider et échapper les entrées, côté serveur uniquement
Une règle que je répète jusqu'à l'écoeurement : toute donnée venant de l'extérieur est hostile par défaut. Formulaire, paramètre d'URL, en-tête, fichier uploadé. Le contrôle côté client (ce joli champ qui refuse les caractères spéciaux) ne compte pas. Un attaquant envoie sa requête avec curl et votre validation JavaScript n'existe plus.
Concrètement : validez le format attendu (une date ressemble à une date), puis échappez à l'affichage selon le contexte où la donnée atterrit. Un texte inséré dans du HTML ne s'échappe pas comme un texte inséré dans un attribut ou dans du JavaScript. Ce détail est la cause n°1 des XSS que j'ai corrigés.
Les en-têtes HTTP de sécurité, une ligne pour beaucoup
Peu de gens y pensent, et c'est du travail quasi gratuit :
- Strict-Transport-Security : force le navigateur à ne plus jamais revenir en HTTP.
- Content-Security-Policy : dit au navigateur quelles sources de script sont légitimes. Mal configurée, elle casse votre site ; bien configurée, elle tue la plupart des XSS.
- X-Content-Type-Options: nosniff : empêche le navigateur de deviner un type de fichier, ce qui évite quelques surprises désagréables.
J'ai mis en place une CSP stricte sur un projet, et j'ai cassé deux intégrations tierces. Il m'a fallu trois jours pour reconstruire la liste blanche proprement. Résultat : plus aucun script non autorisé ne s'exécute, et je dors mieux. Avouons-le, la CSP est pénible à régler — mais c'est l'un de ces rares réglages qui paient immédiatement.
Gérer les secrets et appliquer le moindre privilège
Le fichier .env à la racine dont je parlais au début ? C'est un classique. Les secrets (clés API, mots de passe de base de données, jetons de signature) ne doivent jamais être dans le dépôt Git, jamais dans le code front, jamais dans un log. Ils vivent dans un coffre ou des variables d'environnement injectées au déploiement.
Et surtout : demandez-vous ce que votre compte de base de données a le droit de faire. Si l'application ne se contente que de lire et écrire dans trois tables, donnez-lui uniquement ces droits. Pas de suppression, pas d'accès aux tables système. Le jour où l'injection passe, l'attaquant se retrouve avec un compte myope. C'est frustrant pour lui, et c'est exactement le but.
Sécuriser sur tout le cycle, pas juste avant la mise en ligne
L'erreur que j'ai commise le plus longtemps, c'est de croire que la sécurité était une étape. Un sprint « durcissement » avant la prod, puis on n'en parle plus. Grosse erreur.
Une application sécurisée se surveille en continu, parce que le code change, les dépendances changent, et une faille corrigée dans une bibliothèque ne l'est que si vous mettez à jour. Trois pratiques qui changent la donne :
- Analyser son propre code (SAST) à chaque commit, pour attraper les erreurs de motif avant la revue.
- Scanner l'application en fonctionnement (DAST) pour voir ce qu'un attaquant verrait depuis l'extérieur.
- Tenir à jour les dépendances, parce qu'une bibliothèque obsolète est une porte laissée entrouverte sans que personne ne s'en aperçoive.
Un référentiel m'a beaucoup aidé au début, quand je ne savais pas par quel bout prendre le sujet : la liste des risques applicatifs la plus courante sert de checklist. Elle recense les familles de failles à couvrir. Ce n'est pas une garantie, c'est un point de départ honnête.
Ce qui compte vraiment
Aucune de ces failles ne relève de la magie noire. Toutes sont documentées, comprises, et corrigeables avec des techniques qui existent depuis des années. Ce qui manque le plus souvent, ce n'est ni l'outil ni le budget. C'est la discipline de traiter la sécurité comme une propriété de chaque ligne de code, plutôt que comme un vernis appliqué à la fin.
Alors voilà la question que je vous laisse : dans votre application, à quand remonte la dernière fois où quelqu'un a vraiment essayé de la casser ? Si la réponse est « jamais », ce n'est pas parce qu'elle est solide. C'est juste que personne ne l'a encore testée.
