Defaults.Exposed › Corrections › CDN / WAF et hébergement

Comment corriger CDN / WAF et hébergement

Deux lectures de la tuyauterie derrière votre site : si vous êtes derrière un bouclier protecteur (un CDN avec un pare-feu applicatif web, comme Cloudflare) qui filtre les attaques et absorbe les pics de trafic, et une cartographie de qui gère réellement votre DNS, votre site et votre messagerie. Les deux sont informatifs dans notre notation — ils ne font pas bouger votre note — mais ils décrivent à quel point votre serveur d'origine est exposé aux attaques et aux pannes, et à quel point vos fournisseurs sont enchevêtrés. Un bouclier en façade et un ensemble de fournisseurs sensément réparti, voilà à quoi ressemblent les entreprises résilientes.

En clair, pour votre entreprise : Un site sans bouclier en façade prend chaque attaque et chaque pic de trafic directement sur le serveur d'origine — donc un déferlement de bots, une ruée le jour d'un lancement, ou une seule attaque automatisée peut vous mettre hors ligne pendant des heures, et la reprise est à votre charge. Placer un CDN/WAF en façade (formule gratuite disponible) filtre la grande majorité des attaques automatisées, absorbe les ruées, et accélère le site dans le monde entier — généralement un après-midi de travail pour votre informaticien, sans coût de licence. Par ailleurs, si votre DNS, votre site et votre messagerie résident tous chez un seul fournisseur, une seule panne ou faille là-bas met toute votre présence en ligne à terre d'un coup ; connaître la carte de vos fournisseurs est la première chose dont vous avez besoin en cas d'incident. Ni l'un ni l'autre contrôle ne change votre note — mais les deux décrivent une exposition réelle aux interruptions, aux ventes perdues et à une reprise lente et douloureuse.

Ce que cela peut vous coûter

• Un déferlement de trafic de bots ou un petit DDoS frappe votre serveur sans bouclier le matin d'une grande promotion — le site rame ou s'effondre, les clients reçoivent des erreurs au paiement, et vous perdez les ventes du jour pendant que votre hébergeur se démène. Un CDN/WAF en façade l'aurait absorbé.
• Votre DNS, votre site et votre messagerie passent tous par un seul fournisseur ; ce fournisseur subit une panne et votre site, votre système de réservation ET votre messagerie s'éteignent tous au même instant — vous ne pouvez même pas envoyer « nous sommes au courant du problème » parce que la boîte de réception est aussi en panne.
• Une attaque automatisée sonde votre site toute la nuit — scripts d'injection SQL et de devinette de connexion martelant directement votre origine parce qu'il n'y a aucune couche de pare-feu pour les filtrer — et vous ne le découvrez que quand quelque chose casse. Un WAF bloque l'essentiel de ce bruit avant qu'il n'atteigne jamais votre code.
• Un incident survient et personne ne peut répondre à la question de base « qui appelle-t-on, au juste ? » — le site est-il sur le même hébergeur que la messagerie ? Qui gère le DNS ? Des heures s'écoulent juste à cartographier la tuyauterie pendant que le site reste à terre.
• L'équipe informatique d'un prospect vous scanne avant de signer et voit un serveur d'origine nu sans CDN/WAF et un en-tête de version de serveur qui fuit, annonçant exactement quel logiciel (et version) vous faites tourner — un petit signal « ces gens n'ont pas durci les bases » au pire moment possible.

Pourquoi c'est important. Les deux contrôles ici sont informatifs dans notre méthodologie — ils sont enregistrés avec zéro point et ne changent jamais votre note — car ils décrivent votre infrastructure plutôt que de tester un contrôle de sécurité réussi/échoué. Nous les faisons apparaître parce qu'ils cartographient une exposition réelle de l'entreprise. Un site sans CDN/WAF prend chaque attaque et chaque pic de trafic directement sur l'origine, sans filtrage et sans absorption des ruées ; en ajouter un (la formule gratuite de Cloudflare est la voie courante) est l'une des améliorations de résilience à plus fort effet de levier et plus bas coût qu'une petite entreprise puisse faire. Et une carte de fournisseurs claire — savoir si votre DNS, votre site et votre messagerie sont répartis ou empilés chez un seul fournisseur — est la première chose dont vous avez besoin quand quelque chose tourne mal, et la différence entre un incident contenu et un black-out total.

De quoi il s’agit, en clair

Tout site web tourne sur un serveur quelque part. La question à laquelle répond cette page est : qu’est-ce qui se tient entre l’internet ouvert et ce serveur — et qui gère réellement les pièces de votre présence en ligne ?

Il y a deux parties :

1. CDN / WAF — le bouclier en façade. Un CDN (réseau de diffusion de contenu) est un réseau mondial placé en façade de votre site, qui sert votre contenu rapidement aux visiteurs où qu’ils soient, et absorbe les ruées de trafic. Un WAF (pare-feu applicatif web) est un filtre qui inspecte les requêtes entrantes et bloque les malveillantes avant qu’elles n’atteignent votre serveur. Les services populaires (Cloudflare, AWS CloudFront, Fastly, Akamai, Sucuri, et d’autres) regroupent ces deux fonctions. Nous examinons les réponses de votre site et indiquons si nous pouvons voir un bouclier en façade — et nous notons aussi quel serveur web vous faites tourner.

2. Carte d’hébergement / fournisseurs — qui gère votre tuyauterie. Nous lisons les enregistrements publics qui indiquent qui gère votre DNS (l’annuaire qui transforme votre domaine en adresse) et qui gère votre messagerie. À partir de là, nous pouvons dire si votre DNS, votre site et votre messagerie sont répartis entre fournisseurs (résilient) ou empilés chez un seul (commode, mais un point unique de défaillance).

La chose la plus importante à savoir d’emblée : dans notre notation, les deux sont informatifs. Ils n’affectent pas votre note. Nous les faisons apparaître parce qu’ils décrivent à quel point votre entreprise est exposée aux interruptions et aux attaques — une question différente, et très pratique, de la note.

Ce que cela peut vous coûter

Ce ne sont pas des risques abstraits — ce sont les façons quotidiennes dont une configuration sans bouclier et enchevêtrée transforme un petit problème en mauvaise journée.

• Mis hors ligne le jour où cela compte le plus. Votre site repose sur le serveur d’origine sans rien en façade. Le matin d’un lancement ou d’une promotion, le trafic explose — ou un déferlement de bots modeste frappe — et le serveur ne tient pas. Les pages expirent, le paiement échoue, et vous perdez le chiffre d’affaires du jour pendant que votre hébergeur éteint l’incendie. Un CDN absorbe les ruées et un WAF filtre le trafic indésirable ; ensemble ils sont la différence entre « journée chargée » et « hors ligne toute la matinée ».

• Tout s’éteint d’un coup. Votre DNS, votre site et votre messagerie passent tous par un seul fournisseur. Ce fournisseur subit une panne (cela leur arrive à tous tôt ou tard) et votre site, votre système de réservation et votre messagerie disparaissent simultanément. Vous ne pouvez pas traiter les commandes, et vous ne pouvez même pas écrire aux clients pour dire que vous êtes au courant — parce que la boîte de réception est aussi en panne. Répartir les fournisseurs signifie qu’une défaillance est contenue, pas totale.

• Votre code prend chaque attaque directement. Sans WAF, chaque sonde automatisée — tentatives d’injection, devinette de connexion, scanners d’exploits connus — frappe le code de votre application sans aucun filtrage. Vous pariez que votre logiciel est sans faille et entièrement à jour, pour toujours. Un WAF bloque l’écrasante majorité de ce bruit automatisé avant qu’il ne vous atteigne, transformant « attaque de fond constante » en « majoritairement filtrée ».

• Un incident lent et paniqué parce que personne n’a la carte. Quelque chose casse et la première heure est gaspillée sur « attends, qui gère notre DNS ? La messagerie est-elle sur le même hébergeur ? Qui appelle-t-on ? » Quand votre carte de fournisseurs est floue, chaque incident démarre de zéro. Connaître la carte d’avance transforme une débandade en un coup de fil.

• Une mauvaise première impression auprès d’un acheteur attentif. L’équipe informatique d’un prospect vous scanne avant de signer et voit une origine nue sans CDN/WAF — et un en-tête de serveur annonçant ouvertement votre logiciel et sa version exacts. C’est un petit signal, mais il vous range dans la colonne « n’ont pas durci les bases » exactement au mauvais moment.

Ce que c’est vraiment

CDN / WAF — la couche protectrice

Quand un visiteur (ou un attaquant) demande votre site, la requête peut soit aller droit à votre serveur d’origine, soit passer d’abord par un CDN/WAF. S’il y a un bouclier en façade, ce bouclier peut :

• Filtrer les requêtes malveillantes (la partie WAF) : bloquer les tentatives d’injection, les attaques de bots et les schémas d’exploitation connus avant qu’ils n’atteignent jamais votre code.
• Absorber le trafic (la partie CDN) : servir le contenu mis en cache depuis des serveurs proches de chaque visiteur et absorber les ruées, pour qu’un pic — légitime ou hostile — n’écrase pas votre origine.
• Accélérer le site : un contenu livré depuis un serveur de périphérie proche se charge plus vite pour les visiteurs du monde entier.

Nous détectons un bouclier en examinant les empreintes que ces services laissent dans les en-têtes de réponse de votre site — par exemple un en-tête cf-ray (Cloudflare), x-amz-cf-id (Amazon CloudFront), x-served-by (Fastly), x-akamai-transformed (Akamai), ou x-sucuri-id (Sucuri). Nous lisons aussi l’en-tête Server pour identifier votre serveur web sous-jacent (nginx, Apache, IIS, LiteSpeed, Caddy, etc.), et nous signalons tout en-tête X-Powered-By qui en dit trop.

À quoi ressemble une situation « correcte » : un CDN/WAF détecté en façade de votre origine, et un en-tête Server qui n’annonce pas un numéro de version précis.

Carte d’hébergement / fournisseurs — vos dépendances d’infrastructure

Votre domaine pointe discrètement vers plusieurs services différents :

• DNS — l’annuaire qui transforme votreentreprise.com en l’adresse réelle du serveur. Nous lisons vos enregistrements de serveurs de noms (NS) et reconnaissons les fournisseurs courants (Cloudflare, AWS Route 53, Azure DNS, GoDaddy, Namecheap, DigitalOcean, Hetzner, Linode, et des bureaux d’enregistrement régionaux parmi eux).
• Messagerie — où votre courrier est géré. Nous lisons vos enregistrements MX et reconnaissons les fournisseurs courants (Google Workspace, Microsoft 365, Proofpoint, Mimecast, Barracuda, Zoho, et d’autres).

À partir de là, nous pouvons voir si ces responsabilités sont réparties entre fournisseurs (une défaillance chez l’un ne fait pas tomber les autres) ou empilées chez un seul fournisseur (commode, mais une seule panne ou faille emporte tout).

À quoi ressemble une situation « correcte » : au minimum, un DNS détenu par un fournisseur dédié et fiable plutôt que regroupé dans le même compte que tout le reste — pour que l’annuaire de votre domaine ne partage pas le sort de votre site et de votre boîte de réception.

Comment corriger (gratuit, ~1 après-midi)

Transmettez ceci à votre informaticien ou développeur web — le correctif est gratuit. Placer un CDN/WAF en façade de votre site ne coûte rien sur les formules gratuites courantes, et supprimer la version de votre serveur est un réglage d’une ligne. Il n’y a aucune licence à acheter. (Les options payantes ici ne sont que la surveillance, le suivi de portefeuille et les audits — jamais le correctif lui-même.) La seule décision du dirigeant est : oui, mettre un bouclier en façade du site.

Comme les deux contrôles sont informatifs, rien de tout cela n’est noté — mais un CDN/WAF est l’une des améliorations de résilience à plus forte valeur qu’une petite entreprise puisse faire, donc cela vaut la peine.

1. Mettre un CDN/WAF en façade de votre site

La voie la plus courante et gratuite est Cloudflare :

1. Créez un compte Cloudflare gratuit et ajoutez votre domaine.
2. Cloudflare lit vos enregistrements DNS existants ; vérifiez qu’ils ont été importés correctement.
3. Changez les serveurs de noms de votre domaine (chez votre bureau d’enregistrement) pour les deux que Cloudflare vous donne. C’est la bascule qui route le trafic à travers Cloudflare.
4. Réglez le mode SSL/TLS sur Full (strict) pour que le chiffrement reste de bout en bout entre visiteur → Cloudflare → votre origine. (Évitez « Flexible », qui laisse le dernier tronçon non chiffré.)
5. Le CDN et un WAF de base sont désormais actifs. Vous pourrez ajuster les règles WAF plus tard, mais les valeurs par défaut filtrent déjà beaucoup.

Autres voies, selon votre stack :

• AWS CloudFront — créez une distribution pointant vers votre origine ; associez-la à AWS WAF pour le filtrage. Idéal si vous êtes déjà sur AWS.
• Sucuri WAF — basé sur le DNS, ne nécessite aucun changement sur votre serveur ; bien si vous ne pouvez pas toucher à l’origine.
• Fastly / Akamai — CDN/WAF de niveau entreprise, généralement pour des sites plus grands ou à plus fort trafic.

Après la bascule, testez le site, confirmez que le HTTPS fonctionne partout, et surveillez-le un jour. Ne mettez pas en cache de façon agressive les pages qui doivent rester personnelles ou en direct (zones connectées, paniers, paiements).

2. Cessez d’annoncer la version de votre serveur

Que vous ajoutiez ou non un CDN, supprimez la version que votre serveur annonce — c’est de l’information gratuite que vous offrez aux attaquants.

Nginx :

server_tokens off;

Apache (dans la configuration principale) :

ServerTokens Prod
ServerSignature Off

Retirez un en-tête X-Powered-By qui en dit trop (par ex. de PHP ou d’un framework applicatif) au niveau du serveur ou du CDN — sur Cloudflare, vous pouvez le retirer avec une règle de transformation d’en-tête de réponse.

3. Vérifiez la cohérence de votre carte de fournisseurs (optionnel, ~10 minutes)

Regardez où résident réellement votre DNS, votre site et votre messagerie :

• Si les trois sont dans un seul compte fournisseur, envisagez au moins de déplacer le DNS vers un fournisseur dédié (le DNS de Cloudflare est gratuit et rapide). Cette seule séparation signifie que l’annuaire de votre domaine survit à une panne d’hébergement.
• Notez la carte par écrit — fournisseur DNS, hébergeur web, fournisseur de messagerie, bureau d’enregistrement, et le contact de connexion/support pour chacun. Cette page unique est la chose la plus utile que vous puissiez avoir sous les yeux pendant un incident.

Notes par plateforme

• Google Workspace / Microsoft 365 : ce sont vos fournisseurs de messagerie, pas votre site. Mettre un CDN/WAF en façade du site ne touche pas la messagerie, et vice versa — ce sont des décisions distinctes. (Avoir la messagerie chez Google/Microsoft et le site derrière Cloudflare est une configuration parfaitement bonne et délibérément répartie.)
• Créateurs de sites gérés (Wix, Squarespace, Shopify) : ils incluent leur propre CDN et un niveau de protection WAF dans le cadre de la plateforme, donc vous êtes peut-être déjà protégé même si notre contrôle d’en-têtes ne nomme pas de fournisseur. Vous ne pouvez généralement pas ajouter votre propre Cloudflare en façade ; ce n’est pas grave — la plateforme s’en charge.
• WordPress sur votre propre hébergement : candidat idéal pour une couche Cloudflare gratuite en façade. Combinez-la avec le pare-feu d’une extension de sécurité pour les règles au niveau applicatif.

Erreurs courantes

• Faire tourner une origine nue « parce que le site est petit ». Les petits sites subissent les mêmes attaques automatisées et déferlements de bots que les grands — les bots ne vérifient pas votre chiffre d’affaires d’abord. La formule gratuite CDN/WAF existe précisément pour les petits sites ; ne pas l’utiliser, c’est laisser un gain facile sur la table.
• Utiliser le SSL « Flexible » de Cloudflare. Il affiche un cadenas mais laisse la connexion entre Cloudflare et votre origine non chiffrée. Utilisez toujours Full (strict) pour que ce soit chiffré de bout en bout.
• Mettre en cache les mauvaises choses. Mettre en cache de façon agressive les pages connectées, paniers ou paiements peut montrer à un client le contenu d’un autre ou des prix périmés. Mettez en cache le contenu statique ; laissez les pages personnalisées et transactionnelles non mises en cache.
• Empiler tout chez un seul fournisseur sans s’en rendre compte. La commodité est très bien si c’est un choix conscient — mais beaucoup d’entreprises ne découvrent que le DNS, le site et la messagerie partagent un compte que pendant la panne qui fait tomber les trois. Faites-en une décision, pas une découverte.
• Laisser la version du serveur affichée. C’est une étape de durcissement gratuite, d’une ligne, facile à oublier. Désactivez-la.

Une note sur la note

Pour être tout à fait clair : aucun de ces deux contrôles n’affecte votre note. Ils sont enregistrés dans notre méthodologie comme informatifs, avec zéro point, et nous ne vous pénalisons jamais pour une origine sans bouclier ou une configuration à fournisseur unique. Nous en rendons compte parce qu’ils décrivent une exposition réelle aux interruptions, aux attaques et à une reprise d’incident lente — et parce qu’ajouter un CDN/WAF gratuit est l’une des améliorations au meilleur rapport qualité-prix qu’une petite entreprise puisse faire. Si vous ne faites rien ici, votre note est inchangée. Si vous mettez un bouclier en façade de votre site et séparez votre DNS, vous avez rendu l’entreprise sensiblement plus résiliente, gratuitement. C’est la bonne manière de lire cette page : non pas un chiffre à défendre, mais une amélioration de résilience qui vaut la peine d’être prise.

FAQ