Avez-vous cherché les failles de sécurité de votre site ?

Les sites web sont rarement piratés par des génies : des systèmes automatisés balaient en permanence le web public à la recherche de faiblesses connues et évitables, et beaucoup de piratages exploitent exactement celles-là. Le problème avec « avez-vous vérifié les failles de sécurité ? », c’est que c’est trop vague pour agir. Voici donc un périmètre concret à vérifier, et un rythme pour continuer à le vérifier.

Où sont vraiment les failles

• Logiciels exposés ou dépassés. Le cœur du CMS, les extensions, les thèmes et les bibliothèques avec des vulnérabilités publiées — plus les panneaux d’administration, les pages phpinfo, les dossiers .git ou les sauvegardes laissées accessibles dans la racine du site.
• Configuration du serveur et de l’application. HTTPS non imposé ou contenu mixte ; en-têtes de sécurité et attributs de cookies absents là où ils s’appliquent (un Content-Security-Policy protège les pages affichées, pas une API JSON — réglez chaque contrôle pour les réponses qu’il concerne) ; des messages d’erreur bavards qui dévoilent des chemins ; des listages de dossiers involontaires.
• Identités et permissions. Mots de passe administrateur par défaut ou réutilisés, absence d’authentification à plusieurs facteurs (MFA), freinage trop faible sur la connexion, la réinitialisation de mot de passe et d’autres opérations sensibles — et, à part, les droits excessifs : permissions de fichiers, comptes de service et utilisateurs de base de données qui ont plus que le nécessaire.
• Chaque chemin d’entrée — pas seulement les formulaires visibles. Les entrées arrivent aussi par les URL, les cookies, les en-têtes, les API, les webhooks, les imports et les données déjà stockées. Les classiques : injection par entrée mal gérée, téléversements acceptés trop largement, formulaires sans validation côté serveur, et changements d’état authentifiés par cookie sans protection CSRF.
• Dépendances tierces. Paquets Composer/npm, scripts intégrés, widgets externes et outils de build — qu’ils tournent sur votre serveur, dans les navigateurs des visiteurs ou dans votre chaîne de déploiement, chacun peut porter des failles ou un risque de chaîne d’approvisionnement.

Ces cinq domaines sont un cadre de départ, pas toute la surface : incluez chaque nom d’hôte et API, le contrôle du domaine et du DNS, les comptes et secrets de déploiement, les sessions, et les endroits où des données sensibles sont stockées ou journalisées.

Corrigez à un rythme régulier, pas une fois pour toutes

1. Cherchez — un scan autorisé et non destructif, plus un coup d’œil manuel. Ne scannez que ce qui vous appartient ou ce que vous avez le droit de tester, et prenez les résultats du scanner comme des pistes, pas comme des preuves : attendez-vous à des faux positifs, et sachez que les scans non authentifiés passent à côté des chemins protégés, des failles de logique et des bugs au niveau du code. Derrière un proxy inverse, un test TLS public note la façade — auditez séparément le saut proxy-origine et l’exposition directe de l’origine.
2. Hiérarchisez — selon l’exploitabilité, l’exposition, les privilèges requis, les données touchées et l’impact sur l’activité. L’accès public augmente l’urgence, mais une faille à fort impact derrière une page de connexion peut quand même passer en premier.
3. Corrigez — traitez les points les plus importants, pas seulement les plus faciles. Pour les téléversements, cela veut dire : n’autoriser que les types et tailles nécessaires, ne jamais faire confiance au nom de fichier ni au type MIME fournis, générer les noms de stockage, stocker hors de la racine web ou sur un hôte isolé, et servir le contenu comme non exécutable. Pour les actions authentifiées par cookie : la protection CSRF du framework, validée côté serveur, sans changement d’état via GET.
4. Revérifiez — confirmez que chaque correction a marché et que rien n’a régressé, puis planifiez le passage suivant.

Les mises à jour au quotidien et l’hygiène des comptes forment une discipline à part (traitée séparément) — ici, l’objectif est d’auditer toute la surface selon un calendrier répétable, et après chaque mise en production, avis de sécurité ou incident, plutôt que de faire confiance à la routine.

À retenir : auditez la vraie surface d’attaque — logiciels, configuration, identités, entrées, dépendances et tout ce qui s’y rattache — et menez cela comme un cycle chercher-hiérarchiser-corriger-revérifier, déclenché par le calendrier et par les événements, pas comme un scan unique.

Ce qu'il faut faire

1. Inventoriez votre surface — les cinq domaines plus chaque nom d’hôte, API, système de déploiement et espace de données. On ne peut pas sécuriser ce qu’on n’a pas listé.
2. Lancez un scan autorisé et des vérifications d’en-têtes/TLS ; contrôlez les résultats à la main, et auditez l’origine séparément si un proxy est devant le site.
3. Traitez les entrées prudemment : requêtes paramétrées pour les valeurs, listes blanches pour les identifiants dynamiques, encodage de sortie adapté au contexte, protection CSRF sur les changements d’état authentifiés par cookie, et téléversements durcis.
4. Protégez les comptes et appliquez le moindre privilège — mots de passe uniques et MFA sur les comptes privilégiés ; à part, droits minimaux pour les rôles, les fichiers, les services et les utilisateurs de base de données.
5. Hiérarchisez, corrigez et revérifiez — selon le calendrier, après les changements importants, et chaque fois qu’un avis de sécurité cite un outil que vous utilisez.
6. Gardez des sauvegardes protégées et versionnées hors de la production, avec un accès distinct et des restaurations testées, pour pouvoir récupérer si quelque chose passe quand même.