Cloudflare est souvent perçu comme une protection magique. On active le proxy, l'icône devient orange, le site passe derrière un réseau mondial, et l'entreprise se sent protégée. C'est une bonne base, mais ce n'est pas suffisant. Cloudflare protège ce qui passe réellement par lui, selon les règles configurées, et seulement si le serveur d'origine n'est pas exposé d'une autre manière. Une mauvaise entrée DNS, un ancien sous-domaine, une interface oubliée ou une règle trop permissive peut réduire fortement l'intérêt du proxy.
Pour une TPE ou une PME, le sujet doit être expliqué simplement : votre domaine raconte des choses. Il indique où se trouve votre site, quels services existent, parfois quels outils vous utilisez, quelles anciennes plateformes traînent encore, et quelles parties de l'infrastructure sont joignables. Un audit Cloudflare et DNS sert à vérifier ce récit public. L'objectif est de réduire ce qu'un inconnu peut découvrir et tester sans avoir d'accès interne.
Le DNS, c'est le carnet d'adresses de l'entreprise
Le DNS relie un nom lisible, comme entreprise.fr, à des services techniques. Il peut pointer vers le site, la messagerie, un outil de paiement, un stockage, un espace client, une plateforme de support, un serveur de test ou un outil interne. Avec le temps, les entrées s'accumulent. Une agence crée un sous-domaine, un prestataire ajoute une vérification, un ancien outil reste en place, une adresse IPv6 est oubliée, un environnement de test devient public.
Le risque n'est pas que le DNS existe. Le risque est qu'il révèle des services qui n'ont plus de raison d'être accessibles. Un sous-domaine oublié peut pointer vers une ancienne application. Une entrée peut exposer directement le serveur d'origine. Une redirection peut envoyer vers un outil abandonné. Un CNAME peut révéler un prestataire. Un audit commence donc par l'inventaire : qu'est-ce qui existe, à quoi cela sert, qui en est responsable, et peut-on le supprimer ou le protéger ?
Cloudflare ne protège pas ce qui le contourne
Le proxy Cloudflare est utile quand le trafic passe bien par lui. Mais si le serveur réel est accessible directement par son adresse IP, certains visiteurs ou robots peuvent contourner les règles Cloudflare. Cela peut exposer des interfaces, des ports, des headers, des versions ou des chemins qui devraient rester cachés. Dans certains cas, l'entreprise pense être protégée alors que l'origine répond encore en direct.
Un audit doit donc vérifier si l'origine peut être atteinte autrement. Il ne s'agit pas de publier des informations sensibles, mais de savoir si un attaquant pourrait éviter la protection principale. La correction peut passer par le pare-feu du serveur, des règles d'autorisation, la limitation des IP Cloudflare, la fermeture de ports inutiles, ou la suppression d'anciens services. Le principe est simple : si Cloudflare est la porte d'entrée prévue, l'arrière-boutique ne doit pas rester ouverte.
Les sous-domaines oubliés
Les sous-domaines sont l'une des sources les plus fréquentes d'exposition. Une entreprise peut avoir app.entreprise.fr, admin.entreprise.fr, test.entreprise.fr, old.entreprise.fr, api.entreprise.fr, storage.entreprise.fr, ou des noms liés à des prestataires. Certains sont utiles. D'autres ne servent plus. D'autres sont protégés par mot de passe mais visibles. D'autres encore affichent des messages d'erreur qui révèlent un framework, une version ou un environnement.
Le dirigeant n'a pas besoin de connaître chaque détail technique. Il doit surtout savoir si des portes existent sans raison claire. Un audit classe les sous-domaines : actifs et utiles, actifs mais à protéger, inconnus à investiguer, obsolètes à supprimer. Cette approche évite de laisser un historique technique devenir une surface d'attaque.
Les pages sensibles
Certains chemins ne devraient pas être librement accessibles : administration, fichiers de configuration, exports, sauvegardes, documentation interne, endpoints d'API, outils de monitoring, espaces de test. Cloudflare peut aider à les protéger avec des règles, mais il faut savoir qu'ils existent. Une règle générique ne suffit pas toujours, surtout si le site contient plusieurs applications ou si l'administration utilise des chemins particuliers.
L'audit vérifie donc les chemins classiques et les chemins spécifiques à l'entreprise. L'objectif est de limiter l'accès aux pages sensibles, de bloquer ce qui n'a pas de raison d'être public, et de s'assurer que les redirections ne créent pas d'exposition inattendue. Une bonne règle est simple : le client doit pouvoir utiliser le service, mais l'inconnu ne doit pas pouvoir parcourir les coulisses.
Le WAF : utile seulement s'il est adapté
Le WAF, ou pare-feu applicatif, peut bloquer des requêtes suspectes. Mais il doit être configuré avec le contexte du site. Une boutique, un formulaire de contact, une API, un espace client et un blog n'ont pas les mêmes besoins. Des règles trop faibles ne protègent pas assez. Des règles trop agressives peuvent bloquer de vrais clients. L'audit consiste à trouver un équilibre.
Pour une PME, les règles prioritaires sont souvent très concrètes : protéger l'administration, limiter les robots agressifs, bloquer les chemins sensibles, surveiller les tentatives évidentes sur des fichiers de configuration, et durcir les endpoints qui reçoivent des données. Il ne faut pas chercher la règle parfaite. Il faut mettre en place une protection lisible, testée et compatible avec l'activité.
Les emails et le domaine
Le domaine ne sert pas seulement au site. Il sert aussi aux emails. Une mauvaise configuration peut faciliter l'usurpation : quelqu'un envoie un email qui semble venir de votre entreprise, demande un paiement, envoie une fausse facture ou récupère un mot de passe. Les réglages SPF, DKIM et DMARC permettent de réduire ce risque. Ils ne sont pas visibles pour le client final, mais ils protègent la confiance autour du domaine.
Un audit Cloudflare et DNS doit donc vérifier la messagerie autant que le site. Le dirigeant doit savoir si son domaine peut être utilisé facilement pour tromper des clients ou partenaires. La correction peut être rapide, mais elle doit être faite proprement pour ne pas casser l'envoi d'emails légitimes.
IPv6 et anciennes adresses
De plus en plus d'infrastructures utilisent IPv6. C'est normal, mais cela peut créer des surprises. Une entreprise peut avoir protégé son IPv4 tout en laissant une adresse IPv6 répondre différemment. Elle peut aussi avoir des anciennes adresses qui pointent encore vers un serveur, ou des services accessibles sur un port inattendu. Ces détails ne sont pas toujours visibles dans les interfaces de gestion habituelles.
Un audit doit vérifier les deux mondes : IPv4 et IPv6. Il doit aussi regarder les certificats, les réponses serveur, les redirections et les ports exposés quand c'est pertinent. L'objectif n'est pas de scanner au hasard, mais de vérifier que l'architecture publiée correspond bien à ce que l'entreprise pense exposer.
Les certificats et les informations révélées
Les certificats TLS peuvent révéler des noms de domaines ou sous-domaines. Les headers HTTP peuvent révéler des technologies. Les pages d'erreur peuvent indiquer un framework, un serveur ou un environnement. Ces informations ne sont pas forcément des failles, mais elles aident à comprendre l'infrastructure. Il faut donc décider ce qui est acceptable et ce qui doit être réduit.
Une entreprise n'a pas besoin de cacher toute son existence. Elle doit surtout éviter de publier des indices inutiles sur les outils sensibles. Si une page d'erreur indique un environnement de développement, si un certificat révèle un service interne, ou si un header annonce une version ancienne, cela mérite une correction ou au moins une décision.
Quand Cloudflare donne une fausse impression de sécurité
Cloudflare est excellent pour beaucoup d'usages : performance, protection basique, filtrage, TLS, DNS, règles de sécurité. Mais il ne corrige pas une application vulnérable, un compte faible, une sauvegarde exposée, un serveur accessible en direct ou un mauvais choix d'architecture. Le danger est de croire que le proxy rend tout le reste secondaire.
Un audit remet les choses dans l'ordre. Cloudflare est une couche. Le domaine est une couche. Le serveur est une couche. L'application est une couche. Les comptes sont une couche. La sécurité vient de l'alignement de ces couches, pas d'un seul bouton activé.
Ce que le rapport doit rendre clair
Le rapport ne doit pas simplement dire que tel enregistrement DNS existe. Il doit expliquer s'il sert encore, ce qu'il expose, quel risque il crée, et quelle décision prendre. Supprimer, protéger, documenter, surveiller ou accepter : chaque entrée importante doit mener à une action. C'est ce qui transforme un inventaire technique en outil de décision.
Pour une TPE ou PME, les corrections prioritaires sont souvent très concrètes : retirer les anciens sous-domaines, protéger l'administration, empêcher le contournement du proxy, corriger les emails du domaine, fermer les services inutiles, vérifier l'IPv6, et clarifier qui possède les accès Cloudflare et registrar. Ces actions réduisent immédiatement la surface visible.
Pourquoi faire cet audit avant un incident
Le meilleur moment pour regarder le domaine est avant qu'il serve de point d'entrée. Après un incident, chaque indice public devient une urgence. Avant un incident, c'est simplement un nettoyage organisé. L'entreprise garde le contrôle, corrige calmement, et comprend mieux son exposition.
Un audit Cloudflare et DNS bien mené apporte donc une chose simple : une carte propre de ce que l'entreprise montre au monde. À partir de là, il devient beaucoup plus facile de fermer ce qui n'a rien à faire dehors, de protéger ce qui doit rester visible, et de garder un domaine qui inspire confiance.
Ressources utiles pour le domaine et l'exposition web
Le domaine est souvent le point de départ d'une vérification. Ces ressources aident à compléter l'audit avec les bons réflexes officiels et les lectures internes pertinentes.
- ANSSI : guide d'hygiène informatiquePour replacer le domaine, les comptes et les services exposés dans une base de sécurité complète.
- Cybermalveillance.gouv.frRessources de prévention et fiches utiles pour dirigeants, salariés et prestataires.
- CNIL : violation de donnéesÀ consulter si une exposition web a pu rendre accessibles des données personnelles.
- Audit cyber TPE PMEPour élargir l'analyse au-delà du domaine : comptes, sauvegardes, prestataires et données sensibles.
- Sécuriser les accèsÀ lire si Cloudflare ou le domaine sont contrôlés par plusieurs comptes ou prestataires.
- Checklist cyberPour vérifier les autres priorités après le nettoyage des entrées publiques.