Déni de service : comment protéger son site ?
En bref
Une attaque par déni de service cherche à rendre un site indisponible en le saturant de requêtes. La protection combine une capacité d'absorption en amont du serveur, une mise en cache des pages, une limitation du débit par origine, et un hébergement dimensionné. Aucune mesure ne rend un site insubmersible : prévoir la procédure et le contact de l'hébergeur compte autant.
Un déni de service ne vise pas à voler des données. Il cherche à rendre votre site inaccessible, en le noyant sous un volume de demandes qu'il ne peut pas traiter. Lorsque les requêtes proviennent de très nombreuses machines réparties dans le monde, on parle de déni de service distribué. Le résultat est le même pour vos visiteurs : une page qui ne se charge plus.
Reconnaître une saturation volontaire
Toute indisponibilité n'est pas une attaque. Une campagne réussie, une mention dans la presse ou une tâche interne mal réglée produisent les mêmes symptômes. Quelques indices orientent le diagnostic :
- une montée brutale du trafic, sans campagne ni publication correspondante ;
- des requêtes concentrées sur une page coûteuse, comme une recherche interne, plutôt que réparties naturellement ;
- des visiteurs qui ne consultent jamais de seconde page et ne chargent ni images ni styles ;
- des origines très nombreuses mais au comportement identique.
La surveillance décrite dans notre article sur la disponibilité du site permet de dater précisément le début de l'épisode, information utile pour la suite.
Les mesures qui absorbent réellement la charge
| Mesure | Effet |
|---|---|
| Filtrage en amont | Un service doté d'une grande capacité réseau reçoit le trafic à votre place et n'achemine que ce qui est légitime. |
| Réseau de diffusion de contenu | Un CDN distribue les pages depuis de nombreux points, ce qui répartit la charge au lieu de la concentrer. |
| Mise en cache | Les pages servies depuis une version préparée n'appellent ni le code ni la base de données, ce qui divise fortement le coût de chaque requête. |
| Limitation du débit | Un plafond de requêtes par origine et par minute écarte les comportements les plus grossiers. |
| Dimensionnement | Une infrastructure capable d'ajouter temporairement des ressources encaisse les pics sans rupture. |
Ce qui ne protège pas
Un module installé sur votre propre serveur n'a aucun effet lorsque la saturation se produit avant lui, sur le lien réseau. Bloquer les adresses une par une est illusoire face à des milliers d'origines. Augmenter la puissance du serveur pendant l'attaque revient souvent à payer plus cher une indisponibilité. Enfin, aucune solution ne met un site totalement à l'abri : l'objectif réaliste est d'élever le coût de l'attaque et de raccourcir sa durée.
Réduire le coût de chaque requête
- Mettre en cache les pages publiques, y compris pour les visiteurs non connectés, ce qui améliore aussi les temps de chargement au quotidien.
- Protéger les pages coûteuses : recherche interne, filtres complexes, génération de documents. Ce sont les cibles privilégiées, car une seule requête y mobilise beaucoup de ressources.
- Limiter les formulaires exposés, notamment ceux qui déclenchent un envoi d'e-mail ou un calcul long.
- Séparer l'administration du site public, afin de garder la main pendant un épisode de saturation.
- Corriger les lenteurs structurelles, détaillées dans notre article sur les causes d'un site lent : un site rapide résiste mécaniquement mieux.
Préparer la réaction
Une attaque se traite rarement dans le calme. Préparez à froid les éléments suivants : le contact technique de votre hébergeur et la procédure d'escalade, le nom de la personne qui décide d'activer un filtrage renforcé, une page d'information à publier si le site reste inaccessible, et un canal de communication indépendant du site. Notez également que le déni de service sert parfois à occuper les équipes pendant qu'une autre action est menée : la surveillance des accès ne doit pas être relâchée durant l'épisode.
NexSecure dimensionne et protège les sites qu'elle héberge dans le cadre de son offre d'hébergement web.
Questions fréquentes
Faut-il payer pour une protection anti-saturation ?
Cela dépend de l'enjeu d'une indisponibilité. Beaucoup d'hébergements incluent déjà un filtrage de base. Une protection renforcée se justifie quand une coupure de quelques heures a des conséquences commerciales directes.
Un petit site est-il visé ?
Oui, souvent sans ciblage particulier : les attaques automatisées frappent ce qu'elles trouvent, et un hébergement modeste sature plus vite. Certaines attaques visent aussi l'hébergeur, avec des effets sur les sites voisins.
Que faire pendant l'attaque ?
Prévenez votre hébergeur, relevez l'heure de début et les journaux, activez le filtrage renforcé prévu à l'avance et communiquez par un canal indépendant du site. Évitez les modifications improvisées, qui compliquent souvent le retour à la normale.
Une attaque par saturation signifie-t-elle un vol de données ?
Pas directement : ce type d'attaque vise la disponibilité. Elle peut cependant servir de diversion. Vérifiez donc les accès et les journaux après l'épisode, sans vous limiter au rétablissement du service.
Sources
Service lié
Articles liés
Rédigé par l'équipe NexSecure. Responsable de la publication : Yohann Toumine. Dernière mise à jour le 11 septembre 2026.
Une question sur votre situation ? Parler de votre projet