WAF et protection DDoS : sécuriser son site contre les cyberattaques

Pourquoi la sécurité web est devenue une urgence absolue

En 2024, les cyberattaques visant les sites web ont atteint des niveaux records. Selon le rapport Cloudflare Radar, les attaques DDoS ont bondi de 65 % par rapport à l’année précédente, avec un pic à 5,6 Tbps pour la plus volumineuse jamais enregistrée. Côté applicatif, l’OWASP signale que les injections et les failles XSS restent dans le top 10 des vulnérabilités les plus exploitées.

Que vous gériez un site vitrine, une boutique Prestashop ou une plateforme SaaS, personne n’est à l’abri. Les attaquants ne ciblent plus uniquement les grandes entreprises : 43 % des cyberattaques visent désormais les PME, souvent moins bien protégées.

Deux technologies constituent aujourd’hui le socle de toute stratégie de défense web : le WAF (Web Application Firewall) et la protection anti-DDoS. Voyons en détail comment elles fonctionnent, comment les mettre en œuvre et comment les combiner pour une sécurité optimale.

Qu’est-ce qu’un WAF (Web Application Firewall) ?

Le rôle du WAF dans la chaîne de sécurité

Un WAF est un pare-feu applicatif qui se positionne entre l’utilisateur et votre serveur web. Contrairement à un pare-feu réseau classique qui filtre le trafic par adresse IP ou port, le WAF analyse le contenu des requêtes HTTP et HTTPS en temps réel.

Concrètement, quand un visiteur remplit un formulaire de contact ou accède à une URL de votre site, le WAF inspecte chaque paramètre de la requête pour détecter des schémas malveillants :

• Injections SQL : tentatives d’injecter du code SQL dans les champs de saisie
• Cross-Site Scripting (XSS) : insertion de scripts malveillants dans les pages
• Inclusion de fichiers distants (RFI/LFI) : accès non autorisé à des fichiers serveur
• Falsification de requêtes (CSRF) : détournement de sessions utilisateur
• Bots malveillants : scrapers, brute force, credential stuffing

Les trois modes de déploiement d’un WAF

Il existe plusieurs façons de déployer un WAF, chacune avec ses avantages :

Mode de déploiement	Principe	Avantages	Inconvénients
WAF cloud (Cloudflare, Sucuri, AWS WAF)	Proxy inverse dans le cloud	Déploiement rapide, pas d’infra à gérer, mise à jour automatique des règles	Dépendance à un tiers, latence potentielle
WAF logiciel (ModSecurity, NAXSI)	Module installé sur le serveur web	Contrôle total, gratuit (open source), personnalisation fine	Consomme des ressources serveur, maintenance manuelle
WAF matériel (F5, Fortinet)	Appliance physique devant le serveur	Performances élevées, dédié	Coût important, moins flexible

Pour la majorité des sites web, le WAF cloud offre le meilleur rapport protection/simplicité. C’est d’ailleurs la solution que nous recommandons chez Lueur Externe pour nos clients hébergés sur AWS ou sur des infrastructures classiques.

Exemple concret : bloquer une injection SQL avec ModSecurity

Voici à quoi ressemble une règle ModSecurity (le WAF open source le plus populaire, compatible Apache et Nginx) pour bloquer une tentative d’injection SQL basique :

# Activation du moteur ModSecurity
SecRuleEngine On

# Règle personnalisée : bloquer les injections SQL classiques
SecRule ARGS "(union.*select|insert.*into|delete.*from|drop.*table)" \
  "id:1001,\
  phase:2,\
  deny,\
  status:403,\
  msg:'Tentative d injection SQL détectée',\
  severity:CRITICAL,\
  log,\
  tag:'attack-sqli'"

# Charger le jeu de règles OWASP CRS (Core Rule Set)
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf

Cette configuration de base active ModSecurity en mode bloquant, ajoute une règle personnalisée et charge le Core Rule Set (CRS) de l’OWASP, un ensemble de plus de 200 règles couvrant les attaques les plus courantes. En production, il est recommandé de commencer en mode détection (SecRuleEngine DetectionOnly) pour identifier les faux positifs avant de passer en mode blocage.

Comprendre les attaques DDoS et s’en protéger

Anatomie d’une attaque DDoS

Une attaque par déni de service distribué (DDoS) vise à rendre votre site inaccessible en le submergeant de trafic illégitime. Les attaquants utilisent généralement des réseaux de machines compromises (botnets) pouvant compter des centaines de milliers d’appareils.

On distingue trois catégories principales :

• Attaques volumétriques (couche 3/4) : saturation de la bande passante par un flux massif de paquets UDP, ICMP ou SYN flood. Ce sont les plus spectaculaires en volume (plusieurs Tbps).
• Attaques protocolaires (couche 4) : exploitation des faiblesses des protocoles TCP/IP pour épuiser les ressources des équipements réseau (tables de connexion des pare-feu, load balancers).
• Attaques applicatives (couche 7) : requêtes HTTP apparemment légitimes mais envoyées en masse pour saturer le serveur web. Plus subtiles, elles nécessitent moins de bande passante mais sont plus difficiles à détecter.

Les chiffres qui font réfléchir

Quelques données récentes pour mesurer l’ampleur du phénomène :

• Durée moyenne d’une attaque DDoS : 68 minutes (Radware, 2024)
• Coût moyen d’une heure d’indisponibilité : 22 000 € pour un site e-commerce de taille moyenne
• Temps moyen pour lancer une attaque DDoS : moins de 10 minutes grâce aux services “DDoS-as-a-Service” disponibles pour quelques dizaines d’euros
• Augmentation des attaques ciblant la couche 7 : +80 % en 2024

Autrement dit, une attaque de 68 minutes peut coûter plus de 25 000 € à une boutique en ligne, sans compter l’impact sur le référencement SEO (Google dégrade les sites fréquemment indisponibles) et la perte de confiance des clients.

Solutions de protection anti-DDoS

La protection contre les DDoS repose sur plusieurs mécanismes complémentaires :

1. Filtrage en bordure de réseau (edge)

Les services comme Cloudflare, AWS Shield ou OVH Anti-DDoS absorbent le trafic malveillant avant qu’il n’atteigne votre serveur. Cloudflare, par exemple, dispose d’un réseau de plus de 310 data centers capable d’absorber des attaques dépassant 200 Tbps.

2. Rate limiting

Limiter le nombre de requêtes par IP et par seconde permet de contrer les attaques applicatives. Voici un exemple de configuration Nginx :

# Définition de la zone de limitation
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

server {
    listen 443 ssl;
    server_name www.example.com;

    location /api/ {
        # Appliquer le rate limiting avec un burst de 20 requêtes
        limit_req zone=api_limit burst=20 nodelay;
        limit_req_status 429;

        proxy_pass http://backend;
    }

    location / {
        limit_req zone=api_limit burst=50 nodelay;
        proxy_pass http://backend;
    }
}

3. Challenge JavaScript et CAPTCHA

Les solutions cloud interposent des challenges transparents pour distinguer les humains des bots. Le Turnstile de Cloudflare ou le reCAPTCHA v3 de Google permettent de filtrer sans friction pour l’utilisateur légitime.

4. Géoblocage et listes noires IP

Si votre audience est principalement française, bloquer le trafic provenant de pays où vous n’avez aucun client réduit considérablement la surface d’attaque.

WAF + Anti-DDoS : la stratégie de défense en profondeur

Pourquoi les deux sont complémentaires

Le WAF et la protection DDoS ne couvrent pas les mêmes menaces :

Menace	WAF	Anti-DDoS
Injection SQL	✅	❌
XSS	✅	❌
Brute force login	✅	✅
SYN flood	❌	✅
UDP flood volumétrique	❌	✅
HTTP flood (couche 7)	✅	✅
Bot scraping	✅	❌
Zero-day applicatif	✅ (avec règles virtuelles)	❌

Utiliser un WAF sans protection DDoS, c’est comme verrouiller sa porte d’entrée mais laisser les fenêtres grandes ouvertes. Les deux doivent fonctionner ensemble pour une protection complète.

Comparatif des principales solutions du marché

Voici un aperçu des solutions les plus utilisées en 2025 :

Solution	WAF	Anti-DDoS	Prix mensuel (entrée)	Idéal pour
Cloudflare	✅	✅	Gratuit (limité) / 20 € (Pro)	Sites vitrines, blogs, PME
AWS WAF + Shield	✅	✅	~30 € (WAF) / 3 000 € (Shield Advanced)	Applications cloud AWS
Sucuri	✅	✅	~10 €/mois	Sites WordPress, Prestashop
ModSecurity + Fail2ban	✅	Partiel	Gratuit (open source)	Serveurs dédiés, VPS
Akamai	✅	✅	Sur devis (entreprise)	Grands comptes, e-commerce haute disponibilité

Chez Lueur Externe, en tant qu’agence certifiée AWS Solutions Architect, nous accompagnons nos clients dans le choix et la configuration de la solution adaptée à leur infrastructure, leur budget et leur niveau de risque. Un site e-commerce Prestashop traitant des données de paiement n’aura pas les mêmes exigences qu’un blog WordPress.

Les bonnes pratiques pour une sécurité web renforcée

Au-delà du WAF : les fondamentaux à ne pas négliger

Un WAF et une protection DDoS ne remplacent pas les bonnes pratiques de base. Voici les mesures complémentaires indispensables :

• Maintenir vos CMS et plugins à jour : 56 % des attaques WordPress exploitent des plugins obsolètes
• Utiliser HTTPS partout : certificat SSL/TLS correctement configuré avec HSTS activé
• Mettre en place une politique de mots de passe robustes : minimum 12 caractères, authentification à deux facteurs (2FA) pour les accès admin
• Sauvegarder régulièrement : sauvegardes automatiques quotidiennes sur un stockage externe (Amazon S3, par exemple)
• Appliquer le principe du moindre privilège : chaque compte utilisateur ne doit avoir accès qu’à ce dont il a strictement besoin
• Surveiller les logs en continu : un outil comme Fail2ban analyse les logs en temps réel et bannit les IP suspectes

Configurer les headers de sécurité HTTP

Les en-têtes de sécurité HTTP renforcent la protection côté navigateur. Voici une configuration recommandée pour Nginx :

# Headers de sécurité essentiels
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://trusted-cdn.com; style-src 'self' 'unsafe-inline';" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Ces headers empêchent le clickjacking, le sniffing MIME, les attaques XSS réfléchies et forcent l’utilisation de HTTPS. Ils sont souvent absents sur les sites que nous auditons.

Monitoring et alertes : détecter avant qu’il ne soit trop tard

Une attaque détectée en 5 minutes cause infiniment moins de dégâts qu’une attaque découverte après 3 heures. Mettez en place :

• Des alertes sur le taux d’erreur : si les erreurs 403, 429 ou 503 augmentent brutalement, c’est un signal
• Un monitoring de la bande passante : un pic anormal de trafic entrant indique souvent une attaque volumétrique
• Des dashboards temps réel : Cloudflare, AWS CloudWatch ou Grafana permettent de visualiser le trafic filtré par le WAF
• Des tests de pénétration réguliers : au moins une fois par an, faites tester votre infrastructure par des professionnels

Cas pratique : sécuriser une boutique Prestashop

Prenons l’exemple concret d’une boutique Prestashop hébergée sur un serveur AWS EC2 — un cas que nous traitons régulièrement chez Lueur Externe.

La stratégie de sécurisation en couches pourrait ressembler à ceci :

1. Couche 1 — CDN et anti-DDoS : Cloudflare en proxy devant le site, avec le mode “Under Attack” disponible en un clic en cas d’urgence
2. Couche 2 — WAF cloud : règles Cloudflare WAF activées (OWASP Core Ruleset) + règles personnalisées pour bloquer l’accès au back-office depuis des pays non autorisés
3. Couche 3 — WAF serveur : ModSecurity sur Nginx avec le CRS de l’OWASP en complément
4. Couche 4 — Rate limiting : limitation à 30 requêtes/seconde par IP sur les pages produit, 5 requêtes/seconde sur la page de login admin
5. Couche 5 — Sécurité applicative : Prestashop à jour, modules vérifiés, 2FA sur le back-office, headers de sécurité configurés
6. Couche 6 — Sauvegarde et recovery : snapshots EC2 quotidiens + export base de données sur S3 avec versioning

Cette architecture multicouche garantit que même si une ligne de défense est contournée, les suivantes prennent le relais. C’est le principe fondamental de la défense en profondeur.

Les erreurs les plus courantes à éviter

Après plus de 20 ans d’expérience dans la sécurisation de sites web, voici les erreurs que nous constatons le plus fréquemment :

• Activer un WAF sans le monitorer : un WAF mal configuré génère des faux positifs qui bloquent des clients légitimes, ou des faux négatifs qui laissent passer des attaques
• Négliger les attaques couche 7 : se protéger uniquement contre les attaques volumétriques est insuffisant. Les HTTP floods représentent la majorité des attaques DDoS modernes
• Faire confiance uniquement au pare-feu de l’hébergeur : la protection de base fournie par OVH ou AWS est un minimum, pas une solution complète
• Oublier la page de login : /admin, /wp-admin, /administrator sont les premières cibles des attaquants. Changez l’URL par défaut, ajoutez du rate limiting et du 2FA
• Ne pas tester la restauration de sauvegarde : une sauvegarde qui ne fonctionne pas le jour J, ce n’est pas une sauvegarde

Conclusion : la sécurité n’est pas une option, c’est un investissement

Dans un contexte où les attaques se multiplient et se sophistiquent, la question n’est plus de savoir si votre site sera attaqué, mais quand. Un WAF correctement configuré, couplé à une protection anti-DDoS robuste et à des bonnes pratiques de sécurité, constitue la meilleure assurance contre les temps d’arrêt, les pertes de données et les atteintes à la réputation.

L’investissement dans la sécurité web est toujours inférieur au coût d’une attaque réussie. Entre la perte de chiffre d’affaires, les pénalités RGPD potentielles, le travail de remédiation et l’impact SEO, une seule attaque peut coûter des dizaines de milliers d’euros.

Vous souhaitez sécuriser votre site web ou e-commerce ? L’équipe de Lueur Externe, forte de plus de 20 ans d’expertise en hébergement, sécurité et performance web, réalise des audits de sécurité complets et met en place des architectures de protection adaptées à vos enjeux. Contactez-nous pour un diagnostic personnalisé.