Configuration Cloudflare pour les sites Web d'entreprise : vitesse et sécurité, étape par étape

Cloudflare se situe entre vos visiteurs et votre serveur. Les visiteurs se connectent au centre de données Cloudflare à proximité, qui sert directement les fichiers mis en cache, filtre le trafic hostile et transmet le reste à votre serveur. Pour une entreprise, cela signifie des pages plus rapides pour les clients éloignés de votre emplacement d'hébergement, une protection contre les simples inondations de déni de service et un endroit pour appliquer les règles de sécurité sans modifier le code de l'application. De nombreux forfaits commencent gratuitement et les forfaits payants ajoutent des fonctionnalités, alors vérifiez la comparaison des forfaits actuels avant de décider.

Il ne remplace pas les logiciels corrigés et le code sécurisé. Notre liste de contrôle de sécurité PHP s'applique toujours. Considérez Cloudflare comme une porte d'entrée solide et non comme un substitut au verrouillage des pièces à l'intérieur.

Avant de commencer

• Faites l’inventaire de votre DNS. Exportez ou capturez chaque enregistrement de votre fournisseur DNS actuel, y compris les enregistrements de courrier (MX, SPF, DKIM, DMARC) et de vérification. Un enregistrement manqué est le moyen classique de pirater le courrier électronique lors d'une migration.
• Sachez à qui appartient le compte du registraire de domaine et assurez-vous qu'il s'agit d'un compte d'entreprise avec authentification multifacteur. Vous y changerez les serveurs de noms.
• Réduisez la durée de vie de vos enregistrements de clé un jour à l'avance si vous le pouvez, afin que les modifications se propagent plus rapidement.
• Choisissez un moment calme et informez-en l’équipe. Planifiez un rollback : les anciens serveurs de noms, notés.

Étape 1 : ajoutez le site et vérifiez le DNS

Ajoutez votre domaine dans le tableau de bord Cloudflare. Il analyse les enregistrements existants. Comparez-les avec votre inventaire et corrigez les lacunes. Pour chaque enregistrement choisissez entre deux modes :

• Proxy (nuage orange) : le trafic passe par Cloudflare. À utiliser pour les noms d'hôte de votre site Web et de vos applications Web.
• DNS uniquement (nuage gris) : Cloudflare répond simplement à la requête DNS. À utiliser pour les serveurs de messagerie, les noms d'hôtes SSH ou FTP et tout ce qui n'est pas du trafic HTTP ou HTTPS.

Mettez ensuite à jour les serveurs de noms de votre registraire. Une fois que le site apparaît comme actif, vérifiez votre site et envoyez un e-mail de test.

Étape 2 : configurer correctement le cryptage

C’est le paramètre qui casse le plus de sites. Cloudflare propose plusieurs modes SSL/TLS :

• Flexible : chiffre le visiteur sur Cloudflare mais envoie le trafic vers votre serveur non chiffré. On dirait que cela fonctionne, mais le match retour est ouvert et cela provoque souvent des boucles de redirection. Évitez-le.
• Complet : chiffre les deux jambes mais ne vérifie pas le certificat de votre serveur.
• Complet (strict) : crypte les deux jambes et vérifie le certificat sur votre serveur. C'est celui-là qu'il faut utiliser.

Installez d'abord un certificat valide sur votre serveur. Un certificat Cloudflare Origin CA ou un certificat gratuit Let's Encrypt fonctionnent tous les deux. Ensuite, passez à Full (strict), activez Always Use HTTPS, définissez une version TLS minimale de 1.2 et activez HSTS uniquement une fois que tout fonctionne via HTTPS, car HSTS demande aux navigateurs de refuser le HTTP simple pendant une longue période.

Étape 3 : rendre Cloudflare impossible à contourner

Si les attaquants connaissent la véritable adresse IP de votre serveur, ils peuvent y envoyer du trafic directement et ignorer toutes les protections que vous avez configurées. Résolvez cela de deux manières :

• Autorisez le trafic Web vers votre serveur uniquement à partir des plages IP publiées de Cloudflare.
• Restaurez l'adresse IP réelle du visiteur sur votre serveur Web, car sinon, chaque demande dans vos journaux, limites de débit et analyses semble provenir de Cloudflare.

#!/usr/bin/env bash
# /opt/cf/update_cloudflare_ips.sh - run weekly from cron
set -euo pipefail
IPS="$(curl -fsS https://www.cloudflare.com/ips-v4) $(curl -fsS https://www.cloudflare.com/ips-v6)"

# 1) real visitor IP for Nginx
OUT=/etc/nginx/conf.d/cloudflare_real_ip.conf
{
  for r in $IPS; do echo "set_real_ip_from $r;"; done
  echo "real_ip_header CF-Connecting-IP;"
} > "$OUT.tmp" && mv "$OUT.tmp" "$OUT"
nginx -t && nginx -s reload

# 2) firewall: allow HTTPS only from Cloudflare (remove any generic "allow 443" rule first)
for r in $IPS; do ufw allow proto tcp from "$r" to any port 443 comment 'cloudflare'; done

Un détail important pour les utilisateurs Docker : les ports publiés par Docker contournent les règles ufw. Liez les conteneurs à localhost derrière un proxy inverse ou restreignez l'accès dans la chaîne de pare-feu DOCKER-USER de Docker. Pour une isolation plus forte, Cloudflare Tunnel permet à votre serveur d'établir uniquement une connexion sortante, il n'a donc besoin d'aucun port Web entrant ouvert. Pour les webhooks de paiement et autres intégrations de serveur à serveur, assurez-vous que les règles IP laissent toujours passer ces demandes si elles ne transitent pas par Cloudflare.

Étape 4 : règles de mise en cache

Par défaut, Cloudflare met en cache les fichiers statiques tels que les images, CSS et JavaScript, mais pas HTML. Une politique judicieuse pour un site PHP typique :

• Actifs statiques : cache pendant une longue période (un mois ou plus). Utilisez des noms de fichiers versionnés ou une chaîne de requête telle que app.css?v=123 afin qu'un nouveau déploiement soit immédiatement récupéré.
• Pages HTML publiques (pages marketing, blog) : peuvent être mises en cache pendant quelques minutes, voire quelques heures, avec une règle de cache. Testez soigneusement.
• Ne mettez jamais en cache : administrateur, compte, panier, paiement, points de terminaison de l'API et toute page qui dépend d'un cookie de connexion. Créez une règle de contournement pour ces chemins et pour les requêtes portant votre cookie de session.

Purgez automatiquement après chaque déploiement afin que les clients ne voient jamais les fichiers périmés. Créez un jeton API avec uniquement l'autorisation « Cache Purge » pour cette zone et appelez-le depuis votre script de déploiement :

# purge selected files after a deployment
curl -sS -X POST "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/css/app.css","https://example.com/js/app.js"]}'

Des pages plus rapides facilitent également la recherche et les conversions. Consultez notre guide Core Web Vitals pour les sites PHP pour savoir ce qu'il faut corriger côté serveur une fois le CDN en place.

Étape 5 : pare-feu, robots et limitation de débit

• Activez les règles WAF gérées disponibles sur votre forfait. Ils bloquent les modèles d'attaque courants avant qu'ils n'atteignent votre code.
• Activez une protection contre les robots adaptée à votre plan et surveillez les analyses avant de resserrer quoi que ce soit.
• Points de terminaison sensibles à la limite de débit : connexion, réinitialisation du mot de passe, inscription et paiement. Les attaques par force brute et par tests de cartes ciblent exactement ces éléments.
• Exonérer le trafic des machines de confiance : les webhooks des fournisseurs de paiement, les services de surveillance et vos propres intégrations ne doivent pas être touchés par les défis du navigateur, car une page de défi renvoyée à un webhook ressemble à un échec.

# Custom rule 1: block probes for secrets and repositories (action: Block)
(http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git" or http.request.uri.path contains "wp-config")

# Custom rule 2: let payment webhooks through (action: Skip, security features)
(http.request.uri.path in {"/webhooks/stripe" "/webhooks/paypal"})

# Rate limiting rule: at most 10 login attempts per minute per IP
(http.request.uri.path eq "/login" and http.request.method eq "POST")  =>  10 requests / 1 minute / IP

La syntaxe des règles et les champs disponibles varient selon le plan, alors traitez-les comme des modèles et testez-les d'abord en mode « journal ». Conservez également les protections au niveau des applications : les vérifications de signature des webhooks, comme dans notre guide des webhooks Stripe, ne dépendent jamais uniquement des règles du réseau.

Étape 6 : vérifiez la configuration

# is traffic going through Cloudflare?
curl -sI https://example.com | grep -iE "^(server|cf-cache-status|cf-ray)"

# does the origin refuse direct access? (replace with your server IP; expect a timeout or refusal)
curl -sI --max-time 8 https://203.0.113.10 -H "Host: example.com" -k

# are the nameservers and mail records right?
dig NS example.com +short
dig MX example.com +short
dig TXT example.com +short

Vérifiez deux fois un fichier statique : la deuxième réponse doit afficher cf-cache-status: HIT. Vérifiez les flux de connexion, de paiement et d'administration avec un vrai navigateur, et envoyez et recevez un e-mail de test.

Erreurs courantes

• SSL flexible et les boucles de redirection qui suivent.
• Proxy du nom d'hôte du courrier (il doit s'agir uniquement de DNS) ou oubli d'un enregistrement de courrier lors du déplacement.
• Mise en cache des pages privées afin qu'un client voie la page du compte d'un autre. Contournez toujours le cache pour le trafic connecté.
• Laisser l'origine exposée: la véritable IP est visible dans les anciens enregistrements DNS, les en-têtes d'e-mails ou les journaux de certificats. Restreignez le pare-feu et envisagez de changer l'adresse IP en cas de fuite.
• Ne pas restaurer la véritable adresse IP, ce qui dépasse les limites de débit, les journaux et les contrôles de fraude.
• Webhooks et API difficiles, qui provoquent des échecs silencieux dans les paiements et les intégrations.
• Limites de taille des requêtes : les requêtes proxy ont une taille de corps maximale en fonction du plan. Vérifiez la limite actuelle si votre application accepte des téléchargements volumineux.
• Oublier la surveillance. Ajoutez des alertes pour l'expiration des certificats et des domaines et effectuez des contrôles de disponibilité, comme décrit dans notre guide de sauvegarde et de surveillance.

Une liste de contrôle d'une page

1. Inventaire DNS exporté, compte registraire sécurisé.
2. Site ajouté, enregistrements examinés, proxy uniquement pour les noms d'hôtes Web.
3. Certificat d'origine installé, mode SSL complet (strict), toujours utiliser HTTPS activé.
4. Firewall limité aux gammes Cloudflare, véritable IP visiteur restaurée.
5. Règles de cache pour les actifs statiques, contournement des chemins privés, purge dans le script de déploiement.
6. WAF géré activé, limites de débit pour la connexion et le paiement, webhooks exemptés.
7. Les commandes de vérification sont exécutées, les alertes configurées, la restauration documentée.

Comment pouvons-nous vous aider

Nous configurons Cloudflare, les pipelines d'hébergement et de déploiement pour les applications PHP et les connectons aux systèmes de paiement, CRM et de messagerie. Découvrez notre service d'intégration ou réservez un court appel et nous examinerons votre configuration DNS, SSL et de mise en cache par rapport à cette liste de contrôle.