Beaucoup de dirigeants commencent à prendre la sécurité au sérieux seulement après que leur site a été compromis, que leur back-office a été piraté ou que les données utilisateurs ont été téléchargées en masse. À ce moment-là, analyser les logs et corriger les failles coûte souvent bien plus cher que d'avoir mis en place une protection dès le départ.
Franchement, la grande majorité des vulnérabilités de sécurité courantes dans le développement web ne relève pas de techniques sophistiquées, mais d'un travail de base mal fait. Voici les pièges les plus fréquemment rencontrés en pratique, expliqués un par un.
1. Vulnérabilités d'injection : injection SQL et injection de commandes
L'injection SQL est la vulnérabilité la plus classique. La cause est simple : le programme concatène directement les entrées utilisateur dans les requêtes SQL. Par exemple, en saisissant une chaîne construite dans un champ de connexion, on peut contourner la vérification du mot de passe, voire extraire toute la table des utilisateurs.
Bonnes pratiques et pièges à éviter :
- Utiliser des requêtes paramétrées ou un ORM, ne pas écrire de concaténation de chaînes à la main
- Attribuer les comptes de base de données selon le principe du moindre privilège ; si l'activité est en lecture seule, ne pas donner de droits d'écriture
- Désactiver les messages d'erreur détaillés en production ; les messages d'erreur sont eux-mêmes une source d'information
- Valider le type des entrées, par exemple n'autoriser que des chiffres pour un ID
L'injection de commandes fonctionne de la même manière. Certains scénarios de développement de scripts nécessitent d'appeler des commandes système pour traiter des images ou générer des fichiers. Si le nom de fichier est directement concaténé dans la commande, un attaquant peut exécuter d'autres instructions au passage. Ce type de problème est particulièrement fréquent dans les systèmes de gestion back-office.
2. Permissions et contournement d'autorisation : être connecté ne signifie pas avoir les droits
C'est la catégorie la plus sous-estimée dans les sites web d'entreprise et les systèmes back-office. L'utilisateur est bien connecté, mais il accède à des données auxquelles il ne devrait pas avoir accès.
Deux cas de figure :
- Contournement horizontal : un utilisateur ordinaire A modifie le numéro de commande dans l'URL et voit la commande de l'utilisateur B
- Contournement vertical : un utilisateur ordinaire accède directement aux interfaces d'administration, par exemple pour supprimer des utilisateurs ou exporter des données
Un scénario concret : dans un projet de développement de mini-programme de réservation, l'interface est `/api/order/detail?id=1001`. Le front-end n'affiche que les commandes de l'utilisateur connecté, mais le back-end ne vérifie pas si cette commande appartient bien à l'utilisateur actuel. Il suffit de changer l'id en 1002 pour voir le numéro de téléphone et l'adresse d'autrui.
Bonnes pratiques :
- Pour chaque interface impliquant des données, vérifier côté serveur si « l'utilisateur actuel a le droit d'accéder à cette donnée »
- Ne pas se reposer sur le masquage de boutons côté front-end pour le contrôle des permissions
- Séparer les interfaces du back-office et celles côté utilisateur, avec une logique d'authentification indépendante
3. Upload et inclusion de fichiers
L'upload de fichiers en soi ne pose pas de problème ; le problème réside dans « la possibilité d'exécuter le fichier après l'upload ».
Pièges courants :
- Ne valider que l'extension côté front-end ; il suffit d'intercepter la requête et de la modifier pour uploader du PHP ou du JSP
- Le répertoire d'upload dispose de droits d'exécution ; un script uploadé permet de prendre le contrôle du serveur
- Le nom de fichier est prévisible, un attaquant peut parcourir et télécharger les fichiers
Recommandations :
- Valider le type de fichier côté serveur, avec une liste blanche plutôt qu'une liste noire
- Interdire l'exécution de scripts dans le répertoire d'upload, n'autoriser que l'accès statique
- Renommer les fichiers avec une chaîne aléatoire, sans conserver le chemin d'origine
- Retraiter les fichiers image pour éliminer au passage tout contenu malveillant éventuellement embarqué
4. Vulnérabilités des API et de la logique métier
Beaucoup de vulnérabilités ne se situent pas au niveau du code, mais dans le flux métier. Par exemple :
- Le code de vérification par SMS n'a pas de limite de tentatives et peut être énuméré par force brute
- Le callback de paiement n'est pas vérifié par signature, ce qui permet de falsifier un statut « payé »
- Les coupons peuvent être obtenus en concurrence, une personne peut en récupérer cent
- Le processus de récupération de mot de passe peut être contourné pour réinitialiser directement le mot de passe d'autrui
Ce type de problème mérite une attention particulière dans le développement d'applications mobiles et de mini-programmes, car la surface d'exposition des API est plus large que celle d'un site web traditionnel. Beaucoup pensent que « si on ne voit pas les API dans l'application, c'est sécurisé », mais dès qu'on ouvre un outil d'interception, les requêtes sont parfaitement visibles.
Recommandations :
- Ajouter des limites de fréquence et un contrôle des risques sur les interfaces critiques
- Les opérations sensibles comme le paiement et le remboursement doivent être vérifiées par signature côté serveur et confirmées en double
- Le flux des états métier doit être déterminé côté serveur, sans faire confiance à l'état transmis par le front-end
5. Composants tiers et problèmes de configuration
Beaucoup de sites web d'entreprise rencontrent des problèmes non pas à cause de failles dans leur propre code, mais parce que les frameworks open source et les plugins utilisés sont trop anciens.
- Les CMS tiers et systèmes de création de sites ne sont pas mis à jour depuis longtemps
- Les configurations par défaut des middlewares n'ont pas été modifiées, par exemple mots de passe faibles du back-office, ports par défaut ouverts vers l'extérieur
- Les groupes de sécurité du serveur cloud sont trop permissifs, la base de données est directement exposée sur Internet
- Les environnements de test, les fichiers de sauvegarde et les répertoires .git sont synchronisés en production
La démarche est simple : mettre à jour régulièrement les dépendances, effectuer une vérification de configuration avant la mise en ligne, fermer les ports qui ne devraient pas être ouverts vers l'extérieur, et supprimer les fichiers de débogage superflus en production.
Dans quels cas faire appel à MIC Studio
Si votre projet correspond à l'une des situations suivantes et que votre équipe n'a pas les ressources pour mener un audit systématique, confier une campagne de tests de sécurité à une équipe spécialisée sera plus rentable :
- Un site web d'entreprise vient d'être refondu et mis en ligne, avec des espaces membres, des formulaires et des paiements
- Le développement d'un mini-programme ou d'une application mobile entre en phase de test, avec de nombreuses API et une logique complexe
- Le système de gestion back-office implique plusieurs rôles et présente un risque élevé de contournement d'autorisation
- Vous avez besoin de tests de reverse engineering pour évaluer le risque d'appels massifs aux API et d'extraction de données
- Un incident de sécurité s'est déjà produit et vous devez en identifier la cause et renforcer la sécurité
La méthode de MIC Studio consiste d'abord à recenser les actifs et les interfaces, puis à tester selon plusieurs axes : injection, permissions, upload, logique et configuration. Nous fournissons une liste de problèmes reproductibles et des recommandations de correction, plutôt qu'un rapport de scan incompréhensible.
Conclusion : trois actions immédiates
1. Réaliser un auto-contrôle des permissions avant la mise en ligne : listez toutes les interfaces et demandez-vous pour chacune « peut-on y accéder sans être connecté » et « peut-on voir les données d'autrui en changeant l'ID utilisateur ».
2. Maîtriser les entrées et les sorties : valider toutes les entrées utilisateur, paramétrer toutes les opérations de base de données, ne jamais divulguer les messages d'erreur.
3. Faire de la sécurité une action continue : mettre à jour régulièrement les dépendances, vérifier régulièrement la configuration, effectuer une campagne de tests de sécurité avant chaque mise en production importante. N'attendez pas qu'un incident survienne pour réagir.
La sécurité n'est pas un projet ponctuel, c'est une partie intégrante du processus de développement. Y réfléchir plus tôt vous épargnera bien des tracas par la suite.