☁️ Cloudflare – Le Guide Ultime

Cloudflare est un service "middle-man" (un Reverse Proxy) qui se place entre vos utilisateurs et votre serveur ("Origin"). Il agit comme le "bouclier" et le "turbocompresseur" de votre site web.

Il fournit 3 services principaux (dont les 2 premiers gratuitement) :

L'ensemble de ces services est souvent appelé un CDN (Content Delivery Network), bien que Cloudflare soit aujourd'hui bien plus que cela (une "plateforme Edge").

Pour que Cloudflare fonctionne, vous devez "déléguer" votre domaine. Cela signifie que vous devez dire à votre "registrar" (là où vous avez acheté monsite.com) que les Name Servers (NS) ne sont plus chez lui, mais chez Cloudflare.

Exemple : ns1.gandi.net devient nina.ns.cloudflare.com.

Une fois cela fait, votre panneau de contrôle DNS se trouve *chez Cloudflare*.

Le Nuage Orange vs Le Nuage Gris (CRUCIAL)

Dans le panneau DNS de Cloudflare, chaque enregistrement (A, CNAME) a un "nuage" :

Sécurité : Si votre A www est "orange" mais que vous avez un A direct "gris" pointant sur la même IP, les attaquants peuvent *contourner* le WAF en attaquant l'IP "grise".

La mise en route est l'étape la plus intimidante mais elle est standardisée. Le but est de remplacer les "serveurs de noms" (Name Servers, NS) de votre "registrar" (GoDaddy, IONOS) par ceux de Cloudflare.

Étape 1 : Ajouter le site à Cloudflare

1. Créez un compte Cloudflare (gratuit).
2. Cliquez sur "Add a Site" et entrez monsite.com.
3. Cloudflare va scanner vos enregistrements DNS existants (A, MX, CNAME...).
4. Il vous présentera une liste de vos DNS. Vérifiez qu'ils sont corrects (surtout A pour le site et MX pour les emails).
5. Cloudflare vous donne enfin la page cruciale : "Change your nameservers". Il vous donne 2 serveurs de noms, par ex :
   nina.ns.cloudflare.com
pablo.ns.cloudflare.com

Étape 2 : Changer les NS chez votre Registrar (ex: GoDaddy, IONOS)

Vous devez maintenant aller sur le site où vous avez *acheté* votre nom de domaine.

Étape 3 : Attendre (Propagation DNS)

Retournez sur Cloudflare et cliquez "Done, check nameservers".
Attention : La propagation DNS peut prendre de 5 minutes à 48 heures (généralement ~1 heure). Cloudflare vous enverra un email quand votre site sera "Actif". À partir de ce moment, tout le trafic passe par eux.

Cloudflare opère sur un modèle "Freemium". Le plan Gratuit est extrêmement généreux, mais les "addons" payants débloquent la vraie puissance.

Par défaut, Cloudflare ne met en cache *que* les fichiers statiques (.css, .js, .jpg, .png...). Il ne cache *pas* le HTML (les pages dynamiques).

Le cache est contrôlé par les headers HTTP envoyés par votre **Origin** (serveur).

• Cache-Control: public, max-age=3600 : (Le meilleur). Dit à Cloudflare "Tu peux cacher ceci, et c'est valide pendant 3600 secondes".
• Etag : Permet à Cloudflare de "revalider" un fichier (If-None-Match) sans le re-télécharger (le serveur répond 304 Not Modified).

Le Debug : CF-Cache-Status

Comment savoir si ça marche ? Ouvrez les "Outils de Dev" (F12) > onglet "Réseau", et regardez les Headers de Réponse du document. Cloudflare ajoute le header CF-Cache-Status.

Les Page Rules (Règles de Page) sont le "cerveau" de la version gratuite. Elles vous permettent de surcharger (override) le comportement de Cloudflare pour des URLs spécifiques (basé sur des "wildcards" *).

Important : Vous n'avez que **3 Page Rules** en plan Gratuit. Il faut les utiliser intelligemment. Les règles sont lues de haut en bas.

Exemple 1 : L'incontournable (Bypass Admin)

Objectif : Ne *jamais* cacher le back-office (/wp-admin) et baisser la sécurité (pour éviter les faux-positifs du WAF).

• Rule #1 (Priorité la plus haute)
• If the URL matches: *monsite.com/wp-admin/*
• Settings:
  Cache Level: Bypass (Ne jamais cacher)
  Security Level: Essentially Off (Désactiver le WAF)
  Disable Apps (Désactiver les "addons")

Exemple 2 : Le "Cache Everything" (HTML Statique)

Objectif : Mettre en cache *tout* (y compris le HTML) d'une section (ex: /blog/) pour 4 heures.

• Rule #2
• If the URL matches: *monsite.com/blog/*
• Settings:
  Cache Level: Cache Everything (Force la mise en cache du HTML)
  Edge Cache TTL: 4 hours (TTL (Time To Live) côté Cloudflare)

Exemple 3 : Redirection (Forwarding)

Objectif : Rediriger monsite.com (non-www) vers www.monsite.com.

• Rule #3
• If the URL matches: monsite.com/*
• Settings:
  Forwarding URL (Redirection)
  Status Code: 301 Permanent Redirect
Destination: https://www.monsite.com/$1 ($1 reprend le *)

Cloudflare a révolutionné le web en offrant le "Universal SSL" (SSL Gratuit). Mais il y a 4 modes, et en choisir un mauvais donne une *fausse* sécurité.

Comment avoir Full (Strict) (gratuit) ?

1. Sur l'Origin (votre serveur) : Installez un certificat (ex: Let's Encrypt).
2. Sur Cloudflare (Dashboard) : Allez dans "SSL/TLS" > "Overview" et mettez le mode sur Full (Strict).

Alternative (Origin CA) : Si votre hébergeur ne supporte pas Let's Encrypt, vous pouvez générer un "Cloudflare Origin Certificate" (gratuit) et l'installer sur votre serveur. Il n'est "valide" *que* pour Cloudflare (pas pour les navigateurs publics).

C'est la deuxième mission principale de Cloudflare (après le CDN).

1. Mitigation DDoS (Anti-DDoS)

Automatique. Cloudflare absorbe les attaques DDoS (Distributed Denial of Service) sur son réseau massif avant qu'elles n'atteignent votre serveur.

• Attaques L3/L4 (SYN Floods, etc.) : Tente de saturer la *connexion réseau* (TCP) de votre serveur. Cloudflare absorbe ce trafic (gratuitement et automatiquement) sur son "Edge". Votre "Origin" ne voit jamais rien.
• Attaques L7 (HTTP Floods) : Tente de saturer *l'application* (Apache, PHP) avec des millions de requêtes GET /. C'est plus subtil.

2. WAF (Web Application Firewall)

C'est un "plugin" (disponible en Plan Pro+) qui analyse le *contenu* des requêtes (POST /login, GET /search?q=...) pour bloquer les attaques "connues" (exploits).

Il protège contre (notamment) le Top 10 OWASP (Injection SQL, Cross-Site Scripting (XSS), ...).

3. Firewall Rules (Règles "Custom")

C'est le WAF "manuel" (disponible en Plan Gratuit, 5 règles). C'est le "plugin" de sécurité le plus puissant. Vous créez des règles (similaires aux ACLs de HAProxy).

Exemple : Bloquer wp-login.php (Brute Force)

Objectif : N'autoriser *que* votre IP (1.2.3.4) à accéder à la page de login WordPress.

Rule Name: "Protéger WP-Admin"
Si...
  ( (URI path CONTIENT "/wp-login.php") 
    OU 
    (URI path COMMENCE PAR "/wp-admin/") )
  ET
  ( IP Source N'EST PAS DANS ("1.2.3.4") )

Alors...
  Action: "Block"

Cloudflare propose de nombreux "plugins" et "add-ons" (gratuits ou payants) pour optimiser la performance, accessibles dans l'onglet "Speed".

C'est le "plugin" le plus puissant de Cloudflare. C'est l'avenir de la plateforme.
Cloudflare Workers est une plateforme Serverless (comme AWS Lambda), mais qui s'exécute *sur le réseau Edge* (dans les 300+ data centers), pas dans une région centrale.

V8 Isolates (La "Magie" de la Vitesse)

Un Worker n'est *pas* un conteneur (Docker) ou une VM. Il tourne sur un Isolat V8 (le moteur JS de Chrome).
Résultat : 0ms de "Cold Start" (démarrage à froid). C'est instantané, beaucoup plus rapide que AWS Lambda.

Cas d'Usage (Le "VCL" moderne)

Un Worker est un "reverse proxy programmable". Il intercepte la requête (comme le VCL de Varnish) et vous permet de la *modifier* en JavaScript/TypeScript.

Exemple : Modifier un Header de Réponse (worker.js)

// 1. L'Event Listener (comme en JS natif)
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  // 2. Aller chercher la réponse de l'Origin
  const response = await fetch(request)

  // 3. Cloner la réponse pour la modifier (immutable)
  const newResponse = new Response(response.body, response)

  // 4. Ajouter/Modifier un header
  newResponse.headers.set('X-Mon-Test', 'Bonjour depuis le Worker !')
  
  // 5. Renvoi de la nouvelle réponse
  return newResponse
}

Autres usages : A/B Testing, Authentification (JWT) à l'Edge, Rendu Statique, ...

En plus du "Compute" (Workers), Cloudflare a lancé des "add-ons" pour l'hébergement (Pages) et le stockage (R2), en concurrence directe avec Vercel, Netlify, et AWS S3.

1. Cloudflare Pages (Hosting Jamstack)

C'est une plateforme d'hébergement pour les sites statiques et Jamstack (React/Gatsby, Vue/Nuxt, Hugo...).

Comment ça marche :

1. Vous connectez votre dépôt Git (GitHub, GitLab).
2. Cloudflare "écoute" les git push.
3. Il lance un "build" (ex: npm run build).
4. Il déploie le résultat (les fichiers statiques) sur son réseau Edge (CDN) global.

Intégration : S'intègre nativement avec Cloudflare Workers (pour le "backend" de votre site statique).

2. Cloudflare R2 (Stockage Objet "S3")

R2 est un service de stockage objet (comme AWS S3). Il est conçu pour stocker des "blobs" (images, vidéos, backups...).

La "Killer Feature" (Attaque sur S3) :

• AWS S3 facture le stockage (pas cher), mais *surtout* la sortie de données (Egress Fees) (très, très cher).
• Cloudflare R2 facture le stockage (similaire), mais a ZÉRO (0) frais de sortie (Egress).

Outils (Les "Addons" de Dev)

wrangler (Cheat-Sheet)

# 1. Se connecter (OAuth)
$ npx wrangler login

# 2. Lancer un dev-server (local + hot-reload) pour un Worker
$ npx wrangler dev

# 3. Déployer un Worker
$ npx wrangler deploy