En 2025, les cyberattaques visant les applications web représentent le premier vecteur de compromission des systèmes d’information, devant le phishing et les ransomwares. Injection SQL, failles d’authentification, exposition de données sensibles : les vulnérabilités les plus exploitées ne sont pas des attaques sophistiquées menées par des hackers de génie. Ce sont des erreurs de développement banales, connues depuis des années, documentées par l’OWASP (Open Web Application Security Project) et pourtant toujours présentes dans une majorité de projets web. Cet article passe en revue les erreurs les plus fréquentes et les pratiques concrètes pour les éviter.
L’injection SQL reste la faille la plus exploitée, et la plus évitable
L’injection SQL consiste à insérer du code malveillant dans un champ de formulaire ou une URL pour manipuler la base de données de l’application. Malgré sa notoriété (elle figure dans le top 10 OWASP depuis sa création), elle reste l’une des vulnérabilités les plus courantes. La raison est simple : les requêtes SQL construites par concaténation de chaînes, sans échappement ni paramétrage, sont encore présentes dans de nombreux projets.
La solution est pourtant standard : utiliser des requêtes préparées (prepared statements) avec des paramètres liés, proposées par tous les frameworks modernes (PDO en PHP, SQLAlchemy en Python, Prisma en JavaScript). Cette seule pratique élimine la quasi-totalité des injections SQL. C’est une ligne de code, pas un chantier architectural.
Les failles d’authentification ouvrent la porte à toute l’application
Une authentification mal implémentée est la deuxième erreur la plus critique. Mots de passe stockés en clair ou avec un hachage faible (MD5, SHA-1), absence de limitation des tentatives de connexion (permettant le brute force), tokens de session prévisibles ou sans expiration, absence d’authentification multifacteur (MFA) pour les comptes sensibles : chacune de ces faiblesses suffit à compromettre l’ensemble du système.
Les bonnes pratiques sont documentées et accessibles : utiliser bcrypt ou Argon2 pour le hachage des mots de passe, implémenter un rate limiting sur les endpoints d’authentification, générer des tokens avec une entropie suffisante et une durée de vie limitée, et proposer (voire imposer) le MFA pour les comptes à privilèges élevés.
L’exposition de données sensibles par négligence
Beaucoup d’applications exposent des données sensibles sans que les développeurs en aient conscience. Des messages d’erreur trop détaillés révèlent la structure de la base de données. Des endpoints d’API non protégés rendent accessibles des informations personnelles. Des fichiers de configuration (.env, .git, .htaccess) restent accessibles publiquement sur le serveur. Des logs contiennent des mots de passe ou des tokens en clair.
La règle fondamentale est simple : ne jamais exposer plus d’information que ce qui est strictement nécessaire au fonctionnement de l’interface. Les API, en particulier, doivent être conçues avec le principe du moindre privilège : chaque endpoint ne renvoie que les données requises, et l’accès est contrôlé par des permissions granulaires. Notre article sur le fonctionnement des API explique ces mécanismes en détail.
Le XSS et le CSRF exploitent la confiance entre l’utilisateur et l’application
Le Cross-Site Scripting (XSS) permet à un attaquant d’injecter du code JavaScript malveillant dans une page web consultée par d’autres utilisateurs. Il peut ainsi voler des cookies de session, rediriger vers des sites frauduleux ou modifier le contenu affiché. La parade : échapper systématiquement les entrées utilisateur avant de les afficher (les frameworks modernes comme React le font par défaut), et utiliser une Content Security Policy (CSP) stricte.
Le Cross-Site Request Forgery (CSRF) exploite la session active d’un utilisateur pour exécuter des actions à son insu (modifier un mot de passe, effectuer un virement). La solution standard est le token CSRF : un jeton unique, généré côté serveur, inclus dans chaque formulaire et vérifié à chaque soumission.
La sécurité n’est pas une couche à ajouter en fin de projet
L’erreur la plus coûteuse n’est pas technique, elle est organisationnelle : traiter la sécurité comme une étape finale, un audit à passer avant la mise en production. Les vulnérabilités les plus graves s’installent dès les premières lignes de code, dans les choix d’architecture, dans les librairies sélectionnées, dans les pratiques de gestion des secrets.
La sécurité doit être intégrée dès la conception (security by design) : revue de code systématique, tests automatisés de sécurité dans la CI/CD, mise à jour régulière des dépendances, scans de vulnérabilités (OWASP ZAP, Snyk, Dependabot), et formation continue des développeurs aux pratiques sécurisées. Le coût de la prévention est toujours inférieur au coût d’une fuite de données.
À lire aussi :
Application web et rapidité : un enjeu clé
S’y retrouver dans la multiplication des outils web à l’ère de l’IA