Beaucoup de dirigeants attendent simplement de leur site officiel qu'il « s'ouvre, s'affiche et permette de laisser un numéro de téléphone ». Une fois la recette effectuée le jour de la mise en ligne, plus personne ne se connecte à l'administration pendant des années.
Jusqu'au jour où un client appelle pour dire « votre site redirige vers une page de paris en ligne », ou que vous recevez un e-mail affirmant que votre base de données est en vente sur le dark web. C'est à ce moment-là que vous découvrez que le problème existe depuis longtemps.
Les tests de sécurité de site web ne sont pas un luxe réservé aux grandes entreprises. Dès que votre site dispose d'une administration, de formulaires ou de données clients, il mérite un bilan de santé régulier.
Commençons par clarifier : que teste réellement un test de sécurité ?
Beaucoup de gens pensent qu'un test de sécurité consiste simplement à « scanner les vulnérabilités » : installer un scanner, le lancer et produire un rapport. Ce n'est que la moitié du travail.
Un test de sécurité complet doit couvrir au moins trois niveaux :
Le premier niveau concerne la configuration et la surface d'exposition. L'adresse de connexion à l'administration est-elle un chemin par défaut comme /admin ? L'environnement de test a-t-il été oublié et est-il directement exposé sur Internet ? Le port de la base de données est-il ouvert vers l'extérieur ? Les fichiers de sauvegarde traînent-ils à la racine du site et peuvent-ils être téléchargés directement ? Ce type de problème ne nécessite pas de technique avancée, mais c'est celui qui présente le plus haut risque d'incident.
Le deuxième niveau concerne les vulnérabilités Web courantes. Injection SQL, accès non autorisé, téléversement de fichiers, XSS, mots de passe faibles. En particulier pour les systèmes de gestion back-office : un compte ordinaire peut-il voir les commandes d'autres utilisateurs en modifiant un paramètre d'URL ? C'est un point que de nombreux sites d'entreprise n'ont jamais pris en compte lors du développement.
Le troisième niveau concerne la logique métier. Par exemple, dans un mini-programme de réservation, peut-on contourner les restrictions du front-end pour soumettre plusieurs fois ? L'interface de coupons peut-elle être exploitée par un script ? Le captcha est-il purement décoratif ? Ce type de problème ne peut pas être détecté par un scanner ; seul un test manuel le permet.
Il faut avoir passé ces trois niveaux pour savoir où l'on se situe réellement.
Pourquoi faut-il le faire « régulièrement » et non « une seule fois »
Un test de sécurité n'est pas un vaccin qui immunise à vie. Il ressemble plutôt à un bilan de santé : être normal cette année ne garantit pas de l'être l'année prochaine.
Les raisons sont très concrètes :
Le système évolue. Votre site d'entreprise a peut-être ajouté un service client en ligne ce trimestre, intégré un paiement le trimestre suivant, puis changé de version de CMS en fin d'année. Chaque modification de code peut introduire une nouvelle faille. Si le dernier test n'a rien révélé, c'est simplement que cette fonctionnalité n'existait pas encore.
Les composants évoluent. Les frameworks, plugins et SDK tiers utilisés par le site font l'objet de divulgations continues de nouvelles vulnérabilités par leurs éditeurs. Vous n'avez rien modifié, mais ce dont vous dépendez a changé.
Les méthodes d'attaque évoluent. Des outils automatisés scannent chaque jour l'ensemble des adresses IP du réseau à la recherche de sites qui n'ont pas été mis à jour depuis six mois. L'attaquant ne vous choisit pas vous ; il choisit ce qui est facile à pénétrer.
Un rythme pragmatique consiste à : tester les systèmes métier critiques tous les six mois, les sites d'entreprise ordinaires au moins une fois par an, et refaire un test après chaque refonte majeure ou ajout de fonctionnalité. Si vous avez des paiements, des inscriptions d'utilisateurs ou un système de gestion back-office, rapprochez-vous du rythme semestriel.
Cas concret : ce qui a été oublié après une refonte de site officiel
Prenons un exemple courant.
Une entreprise refait son site officiel : mise à niveau visuelle, ajout d'un filtre de produits, ajout d'un formulaire « laissez-nous un message », et migration de l'administration de l'ancien système vers un nouveau CMS. Le cycle de développement dure un mois. La recette vérifie l'affichage des pages et la soumission des formulaires : tout fonctionne, on valide.
Trois mois plus tard, les problèmes apparaissent : la connexion administrateur du nouveau back-office n'a ni limitation du nombre d'échecs ni captcha. Autrement dit, un script peut essayer des mots de passe à l'infini. Par ailleurs, l'interface du formulaire de message n'a pas de limitation de fréquence et a été inondée de dizaines de milliers de données indésirables, ralentissant la base de données.
Ces deux problèmes auraient pu être détectés en dix minutes par un test de sécurité de base. Mais dans le processus de refonte, personne n'était responsable de cette étape.
C'est pourquoi les tests de sécurité doivent être intégrés au processus de mise en ligne, et non ajoutés après coup. La checklist de livraison d'un développement de site web devrait inclure une ligne « tests de sécurité validés ».
Tester soi-même ou faire appel à un prestataire : comment décider
Tout ne doit pas être externalisé. Certaines actions de base peuvent être réalisées par l'équipe elle-même :
- Imposer des mots de passe forts pour l'administration et activer la double authentification
- Désactiver les environnements de test, pages d'exemple et comptes par défaut inutilisés
- Vérifier que les fichiers de sauvegarde et les répertoires de logs ne sont pas accessibles depuis Internet
- Surveiller régulièrement les vulnérabilités connues des composants tiers
Ces mesures relèvent de la discipline d'exploitation : coût faible, bénéfice élevé, aucune raison de s'en passer.
En revanche, les aspects impliquant des accès non autorisés, des injections, des contournements de logique ou des tests d'intrusion nécessitant la construction de chemins d'attaque requièrent généralement des personnes spécialisées. Ce n'est pas parce que vos équipes sont incompétentes, mais parce que les développeurs et testeurs connaissent trop bien leur propre système et ont tendance à suivre les « chemins normaux », sans imaginer par où un attaquant pourrait bifurquer.
Dans quels cas faire appel à MIC Studio
Si votre situation correspond aux points suivants, vous pouvez envisager de nous confier cette mission :
Premièrement, votre site web ou mini-programme vient d'être mis en ligne, ou vient de subir une refonte majeure, et vous avez besoin d'un regard indépendant pour vérifier l'absence de failles évidentes.
Deuxièmement, votre système de gestion back-office implique plusieurs rôles et niveaux de permissions, par exemple distributeurs, employés et administrateurs, et vous craignez des problèmes d'accès non autorisé.
Troisièmement, vous avez déjà été piraté, inondé de données indésirables ou avez reçu des e-mails de rançon, et vous devez d'abord localiser le problème avant de parler de renforcement.
Quatrièmement, vous avez une activité App ou script, et vous avez besoin de tests d'intrusion au niveau des interfaces pour vérifier la fiabilité du transfert de données et de l'authentification.
Lorsque MIC Studio réalise du développement de sites web d'entreprise, de mini-programmes ou d'App, les tests de sécurité font partie intégrante de la livraison ; nous acceptons également des missions indépendantes de tests de sécurité de site web. À l'issue des tests, nous fournissons une liste de corrections exécutables, et non un rapport de scan incompréhensible.
Trois recommandations applicables immédiatement
Premièrement, intégrez les « tests de sécurité » à la checklist de recette de votre prochaine refonte. Pas besoin d'attendre l'année prochaine : faites-le dès la prochaine modification de code, c'est le moment où le coût est le plus faible.
Deuxièmement, vérifiez dès aujourd'hui trois choses : l'adresse de connexion à l'administration est-elle devinable, l'environnement de test est-il désactivé, y a-t-il des fichiers suspects à la racine du site. Cela prend une demi-heure.
Troisièmement, fixez une date de retest régulière pour les systèmes critiques. Inscrivez-la dans le calendrier, tous les six mois, et faites-le à échéance, sans compter sur votre mémoire.
En matière de sécurité, tant qu'aucun incident ne survient, cela peut sembler un gaspillage d'argent ; mais le jour où l'incident arrive, on réalise que c'était la dépense la moins chère.