Beaucoup de dirigeants ne pensent à la sécurité qu'après l'incident : un back-office piraté où les prix ont été modifiés, des numéros de téléphone d'utilisateurs extraits en masse, la page d'accueil du site officiel affichant des liens suspects. Quand on pose la question, le développeur répond : « toutes les fonctionnalités ont été testées ». Le problème est là : réussir les tests fonctionnels ne signifie pas que la sécurité est assurée.
La plupart des vulnérabilités de sécurité dans le développement web ne relèvent pas d'attaques sophistiquées, mais de quelques étapes fondamentales mal exécutées. Voici, point par point, les pièges les plus fréquents dans les projets réels.
1. Contournement d'autorisation : être connecté ne signifie pas tout voir
C'est le problème le plus courant dans les sites d'entreprise et les systèmes de gestion back-office. Après connexion, l'utilisateur A modifie l'ID de commande dans la barre d'adresse de 1001 à 1002 et peut voir la commande de l'utilisateur B. Le développeur a souvent seulement masqué le bouton côté front-end, mais l'API back-end ne vérifie pas « si cette donnée vous appartient ».
La solution est simple : chaque API doit vérifier si la personne connectée a le droit d'opérer sur cette donnée, et non pas seulement « si elle est connectée ». Les rôles et permissions doivent aussi être clairement séparés : les menus visibles et les API accessibles à un employé ordinaire et à un comptable doivent être différents.
Piège à éviter : ne placez pas la vérification des permissions côté front-end. L'utilisateur peut modifier le code front-end ; le back-end est la dernière porte. Avant la mise en ligne, demandez au développeur de lister chaque API impliquant un ID et de confirmer une par une la vérification de propriété.
2. Vulnérabilités d'injection : concaténer des chaînes finit toujours par poser problème
L'injection SQL est un problème ancien, mais elle existe encore aujourd'hui. Le scénario typique est la barre de recherche ou les filtres : le développeur insère directement la saisie utilisateur dans la requête SQL, et un attaquant peut contourner les conditions et extraire toute une table avec une chaîne de caractères spéciale.
La bonne pratique est d'utiliser systématiquement des requêtes paramétrées ou des paramètres liés d'ORM, sans concaténation manuelle. Il en va de même pour l'exécution de commandes et l'injection de templates : partout où la saisie utilisateur est exécutée comme du code, une validation par liste blanche est nécessaire.
Piège à éviter : si du SQL concaténé par chaînes apparaît dans le code, on peut généralement le renvoyer directement. Par ailleurs, n'utilisez pas le compte root pour la base de données ; accordez uniquement les permissions nécessaires selon le métier, et les dégâts en cas d'incident seront réduits de moitié.
3. Téléversement et téléchargement de fichiers : l'entrée la plus souvent négligée
Les sites d'entreprise doivent téléverser des images de produits et des pièces jointes de contrats ; le développement de mini-programmes doit téléverser des avatars et des photos d'identité. Si l'API de téléversement ne vérifie que l'extension, un attaquant peut renommer un script en .jpg, le téléverser, puis chercher à le faire exécuter.
Méthode : vérifier le type de fichier selon le contenu réel et non l'extension, interdire l'exécution de scripts dans le répertoire de téléversement, renommer les fichiers avant stockage. L'API de téléchargement doit également vérifier les permissions, pour éviter qu'en changeant un chemin on télécharge le fichier de configuration du serveur.
Piège à éviter : séparez le répertoire de téléversement du répertoire du programme du site. Beaucoup d'incidents surviennent parce que les images et le code sont placés dans le même répertoire exécutable.
4. Authentification des API et exposition d'informations sensibles
Dans le développement d'App et de mini-programmes, les API constituent la principale surface d'attaque. Trois problèmes sont fréquents : absence de limitation de fréquence sur les API, permettant de tester les codes de vérification à l'infini ; des données renvoyées contenant des champs non nécessaires, comme un numéro d'identité dans une liste d'utilisateurs ; des messages d'erreur trop détaillés, exposant directement les erreurs de base de données au front-end.
Méthode : les API de connexion, de SMS et de paiement doivent appliquer une limitation de débit et une protection contre le rejeu, les champs renvoyés doivent être filtrés selon le besoin, et les messages d'erreur doivent être uniformisés. Ne consignez pas non plus les mots de passe et les numéros de téléphone complets en clair dans les journaux.
Piège à éviter : ne synchronisez pas directement les données de l'environnement de test vers la production. Beaucoup de fuites proviennent du fait que la base de test contient de vraies données utilisateur, alors que la protection de l'environnement de test est quasi nulle.
5. La mise en ligne n'est pas la fin : les tests de sécurité doivent entrer dans le processus
Beaucoup d'équipes considèrent la sécurité comme une vérification ponctuelle et ne s'en occupent plus après la mise en ligne. En réalité, la mise en ligne de nouvelles fonctionnalités, la mise à jour des dépendances ou le changement de configuration du serveur peuvent réintroduire des problèmes.
Il est recommandé d'intégrer les tests de sécurité dans le processus de publication : une revue des API et des permissions à chaque refonte majeure, une analyse régulière des vulnérabilités des dépendances, et un test d'intrusion annuel pour les systèmes critiques. Pour un projet comme la refonte d'un site officiel, après les modifications, passez en revue les formulaires, la recherche et la connexion au back-office : le coût est faible et cela bloque la plupart des problèmes basiques.
Piège à éviter : ne regardez pas seulement le nombre de résultats du rapport de scan. Les vulnérabilités critiques détectées par les outils doivent être confirmées manuellement quant à leur exploitabilité réelle ; les faux positifs et les faux négatifs sont courants, et en fin de compte, c'est toujours à l'humain de juger les vulnérabilités de logique métier.
Dans quels cas faire appel à MIC Studio
Si votre équipe n'a pas de personnel dédié à la sécurité, ou si vous préparez une refonte de site officiel, un mini-programme de réservation, un système de gestion back-office, et que vous ne voulez pas devoir éteindre des incendies après la mise en ligne, vous pouvez confier cette partie sécurité.
MIC Studio réalise des sites d'entreprise, du développement de mini-programmes, du développement d'App, ainsi que du développement de scripts et des tests de sécurité de sites web et des tests d'ingénierie inverse. Nous avons l'habitude de passer en revue, dès la phase de développement, les problèmes de permissions, de téléversement et d'API selon une liste de contrôle, plutôt que d'attendre qu'un incident survienne pour corriger.
Trois recommandations concrètes
1. Établissez une liste des API avant la mise en ligne, et confirmez une par une si les trois points suivants sont en place : vérification de connexion, vérification de propriété des données et limitation de débit. S'il en manque un, notez une tâche à faire.
2. Traitez le téléversement et le téléchargement comme des points de risque distincts lors de la revue : confirmez que le répertoire de stockage n'est pas exécutable, que le type de fichier est déterminé par le contenu et que le téléchargement passe par une vérification de permissions.
3. Prévoyez un budget et du temps pour les tests de sécurité : effectuez une vérification avant la publication des versions importantes, et ne considérez pas la sécurité comme une option après la mise en ligne.