Catégories d’attaques de sites web : risques et protections

Résumé : Les attaques contre un site web peuvent viser sa disponibilité, ses données, son code ou les personnes qui l’utilisent. Déni de service, injection SQL, scripts intersites et hameçonnage ne désignent pas tous le même mécanisme. Les distinguer permet de choisir des protections adaptées, de la mise à jour des composants aux sauvegardes et au filtrage des requêtes.

Un site peut rester en ligne tout en exposant ses données, ou devenir inaccessible sans qu’aucune information ne soit volée. Pour réduire ces risques, il faut d’abord comprendre ce que recouvrent les catégories d’attaques visant un site web. Si vous étudiez les protections au niveau des requêtes, notre article sur le pare-feu applicatif WAF présente ce mécanisme de filtrage.

Les attaques se classent selon leur cible et leurs effets : disponibilité du service, base de données, code de l’application, comptes ou échanges avec les visiteurs. Certaines notions désignent plutôt un vecteur d’intrusion ou un logiciel malveillant. Faire cette distinction aide à traiter la cause, et pas seulement le symptôme visible.

Comment classer les attaques visant un site web ?

Pourquoi une attaque par déni de service ne se confond-elle pas avec une injection SQL ? La première vise principalement à perturber l’accès au service, tandis que la seconde cherche à exploiter la manière dont l’application traite les données. Le classement le plus pratique repose donc sur la cible et l’effet observé.

Une attaque peut toucher la disponibilité du site, l’intégrité de ses pages ou la confidentialité des données stockées. Elle peut aussi compromettre un compte administrateur ou viser les visiteurs à travers leur navigateur. Ces objectifs peuvent se combiner au cours d’un même incident.

Il est également utile de distinguer une attaque de son point d’entrée. Le phishing, par exemple, est une technique de tromperie qui peut servir à dérober des identifiants. Un rançongiciel est un logiciel malveillant, tandis qu’une vulnérabilité zero-day désigne une faille exploitée avant qu’un correctif soit disponible. Ces termes ne sont donc pas des catégories mutuellement exclusives.

Quelles attaques menacent la disponibilité d’un site ?

Imaginez qu’un site de réservation reçoive soudainement un volume de requêtes qu’il ne peut pas traiter. Une attaque par déni de service, ou DoS, cherche à épuiser les ressources d’un serveur ou d’une application pour ralentir ou interrompre le service. Le trafic légitime risque alors de ne plus obtenir de réponse.

Une attaque DDoS poursuit le même objectif, mais s’appuie sur plusieurs machines pour envoyer le trafic. Ces appareils peuvent former un réseau de machines zombies, contrôlé à l’insu de leurs propriétaires. La défense relève notamment de la surveillance du trafic et de l’architecture capable d’absorber ou de filtrer les requêtes anormales.

Un rapport du Sénat publié en 2021 cite un baromètre portant sur 2020 : 57 % des entreprises interrogées déclaraient avoir subi au moins une cyberattaque cette année-là. Cette donnée historique concerne les cyberattaques en général, et ne mesure pas spécifiquement les attaques de sites web ni la situation actuelle.

Comment les injections SQL et les XSS ciblent-elles les applications ?

Que se passe-t-il lorsqu’un site incorpore sans précaution le contenu d’un formulaire dans une instruction destinée à sa base de données ? Une injection SQL exploite cette faiblesse pour tenter de lire, modifier ou supprimer des informations. Le risque concerne le traitement des entrées et les autorisations accordées à l’application.

Les scripts intersites, ou XSS, reposent sur un autre mécanisme. Du code malveillant est injecté dans une page, puis exécuté dans le navigateur d’un visiteur lorsque celle-ci est affichée. Selon la faille et le contexte, l’attaque peut compromettre des informations liées à la session ou modifier le contenu vu par l’utilisateur.

Les protections se construisent dans le code : validation des entrées, requêtes paramétrées pour l’accès à la base, encodage du contenu affiché et limitation des privilèges. Un WAF peut ajouter une couche de filtrage, mais ne remplace pas la correction des vulnérabilités. La documentation technique de BunkerWeb décrit, par exemple, des règles capables de repérer des tentatives d’injection SQL et de XSS dans les requêtes.

Lorsque votre solution comporte des comptes clients, des échanges métier ou plusieurs niveaux d’accès, les contrôles doivent aussi correspondre à son fonctionnement réel. Nous détaillons ces enjeux dans notre ressource sur la sécurité d’une application B2B.

Quelles menaces peuvent compromettre le site ou ses visiteurs ?

Un site piraté peut être modifié, rediriger ses visiteurs ou servir à diffuser un logiciel malveillant. Les logiciels malveillants peuvent viser le serveur, un poste d’administration ou l’appareil d’un visiteur. Un rançongiciel, par exemple, peut chiffrer des fichiers et perturber l’exploitation si l’infrastructure compromise y donne accès.

Les attaques contre les comptes constituent une autre voie d’accès. Le vol d’identifiants, leur réutilisation ou des tentatives automatisées peuvent conduire à l’usurpation de compte, notamment si les accès sont faiblement protégés. L’hameçonnage peut contribuer à cette compromission en incitant une personne à transmettre ses identifiants sur une fausse page.

Enfin, une attaque de l’homme du milieu cherche à intercepter ou modifier des échanges entre deux parties. Le tunneling DNS, lui, détourne le fonctionnement des requêtes DNS pour transporter des données ou communiquer avec un système compromis. Ces méthodes concernent parfois l’infrastructure et les communications associées au site plutôt que son code seul.

Quelles mesures réduisent les risques d’attaque ?

Par où commencer si vous gérez un site professionnel ? Appliquez les mises à jour du CMS, des extensions, des dépendances et du serveur, puis retirez les composants qui ne sont plus nécessaires. Les correctifs réduisent l’exposition aux failles connues, sans empêcher toute exploitation d’une vulnérabilité inconnue.

Renforcez ensuite les accès : comptes individuels, mots de passe robustes, authentification multifacteur lorsqu’elle est disponible et droits limités au besoin de chaque utilisateur. Surveillez les journaux et les alertes pour repérer des connexions ou des changements inhabituels. Le guide de réduction de la surface d’attaque recommande également l’application régulière des correctifs et la limitation des services exposés.

Prévoyez des sauvegardes régulières et vérifiez qu’elles peuvent être restaurées. Gardez une copie protégée de l’environnement de production afin qu’une compromission ne puisse pas détruire simultanément le site et toutes ses sauvegardes. Pour un site sous WordPress, notre ressource explique comment sauvegarder un site WordPress.

Enfin, adaptez les contrôles à la fonction du site. Un espace membre, une boutique ou une application métier n’expose pas les mêmes parcours ni les mêmes données. Un WAF, des tests de sécurité et une procédure de réponse aux incidents complètent les mesures de développement et de maintenance. Aucun outil ne remplace la correction des failles dans l’application elle-même.