Un cadenas vert dans la barre d’adresse ne garantit pas grand-chose. Des certificats SSL gratuits, n’importe quel site peut en obtenir un, y compris les pages de phishing. Vérifier la sécurité d’un site internet demande d’aller plus loin que ce simple indicateur visuel, en examinant des couches que ni le navigateur ni l’utilisateur moyen ne voient.
Sécurité des API : l’angle mort d’un audit de site web
Vous consultez une page web, vous voyez du texte, des images, un formulaire. En coulisses, cette page interroge souvent plusieurs API pour récupérer ou envoyer des données. Ces interfaces programmatiques sont devenues une cible prioritaire pour les attaquants.
Les rapports de 2024 confirment que les attaques visant les API représentent une part croissante des incidents sur les applications web. Le problème : la plupart des vérifications classiques se limitent aux pages visibles. Les endpoints d’API, eux, restent dans l’ombre.
Un audit efficace commence par un inventaire complet de ces endpoints. Certains ont été créés pour un besoin ponctuel, puis oubliés. D’autres sont documentés de manière incomplète. Ce sont précisément ceux-là qui posent problème, parce que personne ne pense à vérifier leur authentification ou leurs autorisations.
Concrètement, chaque point d’entrée d’API doit être testé individuellement. On vérifie que l’authentification fonctionne objet par objet (un utilisateur A ne doit pas pouvoir accéder aux données de l’utilisateur B), que des limites de débit sont en place et que les API dépréciées ont bien été retirées. Plusieurs outils permettent d’automatiser une partie de cette vérification de la sécurité des sites internet, mais la revue manuelle reste nécessaire pour les contrôles d’autorisation.
Prioriser les failles : pourquoi le score CVSS ne suffit pas
Quand un scanner remonte une liste de vulnérabilités, chacune est accompagnée d’un score de gravité (CVSS). La tentation est de traiter d’abord les scores les plus élevés. Cette approche semble logique, mais elle rate une donnée capitale : les attaquants exploitent surtout des failles connues et documentées, pas nécessairement les plus sophistiquées.
La CISA maintient un catalogue appelé Known Exploited Vulnerabilities (KEV). Il recense les failles activement exploitées dans la nature. Une vulnérabilité avec un score CVSS moyen mais présente dans ce catalogue mérite une correction immédiate. À l’inverse, une faille théorique cotée très haut mais jamais exploitée peut attendre.
Pour une vérification réellement utile, croisez trois critères :
- La gravité technique donnée par le score CVSS, qui mesure le potentiel de dommage de la faille.
- La présence dans le catalogue KEV de la CISA, qui indique si la faille est activement exploitée par des attaquants.
- L’exposition réelle du composant concerné : un service accessible depuis internet est plus urgent qu’un outil interne derrière un VPN.
Croiser gravité technique, exploitation active et exposition réelle change radicalement l’ordre de priorité des corrections. Sans ce tri, une entreprise peut passer des semaines sur une faille théorique pendant qu’une brèche exploitée reste ouverte.
Composants open source et modèles d’IA dans l’analyse de sécurité
La majorité des sites web modernes reposent sur des bibliothèques open source. Un CMS, un framework JavaScript, un module de paiement : chacun embarque du code tiers avec ses propres vulnérabilités potentielles.
Vérifier ces composants demande un inventaire précis, souvent appelé Software Bill of Materials (SBOM). Ce document liste chaque dépendance, sa version et son état de maintenance. Un composant abandonné par ses mainteneurs est un risque silencieux : aucune mise à jour ne viendra corriger les failles découvertes après l’abandon.
Les fonctionnalités intégrant de l’intelligence artificielle posent un problème supplémentaire. Un modèle d’IA exposé via une API peut être manipulé par des requêtes conçues pour extraire des données d’entraînement ou contourner des filtres. Ces vecteurs d’attaque sont encore mal couverts par les scanners classiques.
Vérifier la configuration serveur et les en-têtes HTTP
Avant même de chercher des failles dans le code, la configuration du serveur révèle souvent des problèmes simples à corriger. Les en-têtes HTTP, par exemple, contrôlent comment le navigateur interagit avec le site.
Un en-tête Content-Security-Policy bien configuré bloque la majorité des attaques XSS. À l’inverse, certains en-têtes autrefois recommandés sont désormais obsolètes. X-XSS-Protection, par exemple, n’est plus utile dans les navigateurs modernes selon la documentation MDN. Copier-coller une configuration trouvée sur un forum de 2018 peut donner un faux sentiment de sécurité.
Les points à vérifier côté serveur :
- Le protocole HTTPS est actif avec un certificat valide, et les redirections HTTP vers HTTPS fonctionnent sans boucle.
- Les fichiers sensibles (sauvegardes, fichiers de configuration, répertoires .git) ne sont pas accessibles publiquement.
- Les en-têtes de sécurité sont à jour et adaptés au contexte du site, pas simplement copiés depuis un modèle générique.
- Les messages d’erreur du serveur ne divulguent pas d’informations techniques (versions de logiciels, chemins de fichiers).
Vérification après correction : l’étape que la plupart des entreprises sautent
Détecter une faille, la corriger, passer à la suivante. Ce cycle semble complet, mais il manque une étape formelle : confirmer que la correction fonctionne réellement.
Les données de 2024 montrent que des vulnérabilités connues restent ouvertes pendant des périodes prolongées, même dans des entreprises équipées de scanners. Le correctif a été déployé sur un environnement de test mais pas en production. Ou bien la mise à jour a été appliquée, mais une version vulnérable du composant tourne encore sur un autre serveur.
La vérification après correction doit inclure un nouveau scan ciblé sur la faille traitée, une vérification manuelle que le correctif n’a pas créé de régression (une fonctionnalité cassée, un formulaire qui ne valide plus les entrées) et un contrôle que les versions vulnérables ont été retirées de tous les environnements exposés.
Cette étape transforme un rapport d’audit en amélioration mesurable. Sans elle, le rapport reste un document PDF classé dans un dossier, et la faille reste exploitable.
