Ce projet vise à créer une mini-application volontairement vulnérable afin de passer en revue différents fondamentaux sur la sécurité des données lorsque l’on crée des API web. Il couvre, les injections SQL, la gestion des contrôles d’accès et des privilèges, l’encryptage des ID de connexion ainsi que les certificats et signatures digitales.
Sécurisation d’une API web vulnérable
Introduction
Les API (application programming interface) sont des interfaces logicielle qui permettenr de connecter un logiciel ou un service à un autre afin d’échanger des données. Quelques examples connus sont les API de Google Map, twitter ou encore Spotify, celles-ci sont de plus en plus nombreuses et offrent de multiples possibilités, telles que la lecture ou la collecte de données en temps réel.
Par conséquent, la sécurité des applications web et des API constitue aujourd’hui un enjeu majeur dans le développement logiciel. De nombreuses vulnérabilités peuvent être exploitées lorsqu’une application ne met pas en place de mécanismes de protection adaptés, notamment au niveau de l’authentification, de la gestion des accès ou encore des échanges de données sensibles.
Dans le cadre de ce projet, une mini-application PHP volontairement vulnérable a été développée afin d’illustrer plusieurs failles de sécurité courantes rencontrées dans les applications web. L’objectif était d’analyser ces vulnérabilités, de comprendre leur fonctionnement puis de mettre en place des correctifs permettant de sécuriser progressivement l’application.
Objectifs du projet
Ce projet avait pour objectif principal de comprendre les principales vulnérabilités présentes dans les applications web et de mettre en pratique différentes méthodes de sécurisation.
L’idée était de partir d’une application volontairement non sécurisée afin d’illustrer concrètement les risques liés à de mauvaises pratiques de développement, comme l’utilisation de requêtes SQL concaténées, le stockage de mots de passe en clair ou l’absence de contrôle des permissions utilisateurs.
Le projet visait également à mettre en oeuvre des mécanismes de protection conformes aux bonnes pratiques actuelles, à savoir la validation des entrées utilisateur, les requêtes préparées, la gestion sécurisée des sessions, le chiffrement des mots de passe avec bcrypt et la sécurisation des communications via HTTPS.
Enfin, ce travail avait pour but de mieux comprendre les enjeux liés à la protection des données sensibles et à la réduction de la surface d’attaque dans les applications modernes.
Architecture de l’application vulnérable
L’application développée repose sur une architecture PHP/MySQL simple permettant de simuler un environnement bancaire minimal. Elle contient plusieurs fonctionnalités classiques telles que l’authentification utilisateur, l’affichage de comptes bancaires, la modification de données et la gestion des rôles administrateurs.
Plusieurs fichiers composent l’application :
un système de connexion utilisateur
des tableaux de bord affichant les données des comptes
des modules de modification et suppression de données
un système de promotion administrateur
ainsi qu’un module de journalisation des actions sensibles
L’application est déployée dans des conteneurs Docker afin de faciliter les tests et la reproduction de l’environnement. Une base de données MySQL est utilisée pour stocker les utilisateurs, comptes et informations d’authentification.
Vulnérabilités étudiées
Plusieurs vulnérabilités classiques des applications web ont été reproduites dans cette application pédagogique.
Les injections SQL constituent la principale faille étudiée. Dans la version vulnérable, les requêtes SQL sont construites par concaténation directe des entrées utilisateur, ce qui permet à un attaquant de contourner l’authentification ou d’accéder à des données non autorisées.
Le projet met également en évidence les problèmes liés aux contrôles d’accès insuffisants. Dans la version initiale, un utilisateur peut accéder aux données d’autres comptes simplement en modifiant certains paramètres présents dans l’URL.
Des failles d’élévation de privilèges ont aussi été implémentées afin d’illustrer les risques liés à une mauvaise gestion des rôles utilisateurs. Certains utilisateurs pouvaient obtenir des privilèges administrateurs sans vérification de permissions.
Enfin, les mots de passe étaient initialement stockés en clair dans la base de données, exposant directement les informations sensibles en cas de compromission du système.
Mise en place des mécanismes de sécurisation
Une seconde version de l’application a été développée afin de corriger progressivement les vulnérabilités identifiées.
Les requêtes SQL ont été sécurisées grâce à l’utilisation de requêtes préparées avec paramètres liés, empêchant ainsi l’exécution de code SQL injecté par un utilisateur malveillant.
Des mécanismes de validation des entrées ont également été ajoutés côté serveur afin de contrôler le format, la longueur et le type des données reçues. Cette approche permet de limiter les comportements inattendus et de réduire les risques d’exploitation.
La gestion des accès a été renforcée en vérifiant systématiquement les permissions des utilisateurs avant toute opération sensible. Les utilisateurs ne peuvent désormais accéder qu’à leurs propres données, tandis que certaines fonctionnalités restent réservées aux administrateurs.
Le stockage des mots de passe a été sécurisé grâce à l’utilisation de l’algorithme bcrypt via password_hash() et password_verify(). Les mots de passe ne sont jamais stockés ni affichés en clair.
Enfin, des mécanismes de journalisation ont été mis en place afin de tracer les actions critiques et faciliter la détection d’activités suspectes.
Sécurisation des communications HTTPS
Le projet intègre également une couche de sécurisation réseau grâce à l’utilisation de certificats HTTPS et du protocole TLS.
Un certificat X.509 auto-signé a été généré afin d’activer le chiffrement des communications entre le client et le serveur web. Toutes les requêtes HTTP sont automatiquement redirigées vers HTTPS afin d’empêcher la transmission des identifiants et des cookies de session en clair sur le réseau.
Plusieurs protections supplémentaires ont été configurées :
• activation du protocole SSL/TLS
• configuration des cookies sécurisés
• utilisation des attributs HttpOnly et SameSite
• mise en place de l’en-tête HSTS
• limitation des risques de détournement de session
Le projet inclut également différentes procédures permettant de vérifier la validité et la cohérence des certificats via OpenSSL.
Résultats
Les tests réalisés sur la version vulnérable montrent qu’une simple injection SQL peut permettre de contourner complètement l’authentification et d’accéder à des données sensibles. De même, l’absence de contrôles d’accès adéquats expose rapidement l’application à des risques de compromission importants.
La mise en place des mécanismes de sécurisation a permis de bloquer l’ensemble des attaques testées dans le cadre du projet. Les requêtes préparées empêchent désormais les injections SQL, tandis que la gestion des rôles et permissions limite les accès non autorisés.
Le projet a également mis en évidence l’importance du chiffrement des mots de passe et de la sécurisation des échanges réseau afin de protéger efficacement les données utilisateurs.
Conclusion
La sécurité des applications web ne repose pas sur un unique mécanisme mais sur l’association de plusieurs couches de protection complémentaires.
Les expérimentations réalisées montrent qu’un grand nombre de vulnérabilités peuvent être évitées grâce au respect des bonnes pratiques de développement (validation des entrées, gestion des permissions, chiffrement)
Ce travail a également permis de renforcer mes compétences en développement sécurisé, en architecture web et en cybersécurité appliquée aux API et applications modernes. Il met en évidence l’importance d’intégrer la sécurité dès les premières étapes de conception d’une application afin de limiter les risques de compromission et protéger durablement les données des utilisateurs.