Détecteur de CDN

Colle une URL et découvre qui la sert : Cloudflare, Fastly, Akamai, CloudFront, Vercel, Netlify et 20 autres, avec la ligne de header ou de DNS exacte qui a vendu la mèche.

Ce détecteur de CDN lit les response headers et le DNS de n'importe quelle URL publique, puis nomme le content delivery network posé devant. Colle un lien et c'est le serveur qui envoie la requête à ta place, donc le CORS n'entre jamais en jeu et ton navigateur reste hors du coup. Il récupère chaque response header plus les enregistrements A, AAAA et CNAME, puis les compare à un catalogue de 25+ providers : Cloudflare, Fastly, Akamai, Amazon CloudFront, Azure Front Door, Google Cloud CDN, BunnyCDN, KeyCDN, Vercel, Netlify, Shopify, jsDelivr et d'autres. Un hit fort sur un header comme cf-ray ou x-amz-cf-id est classé confirmed, un indice DNS faible redescend à suspected, et dans les deux cas tu vois la ligne exacte qui a flaggé le provider. Des onglets séparent le résultat, toutes les preuves, les headers bruts, les enregistrements DNS et le catalogue de signatures complet. Pratique pour la due diligence fournisseur, le diagnostic de latence, le démontage concurrentiel et la vérification de migration.

Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.

Détecteur d'empreinte CDN

Ça t'est déjà arrivé de fixer un site en te demandant qui le sert vraiment ? Moi, j'en avais marre de deviner, alors j'ai construit ça. Tu colles une URL. Mon serveur récupère les response headers et les enregistrements DNS, puis il les compare à un catalogue que je tiens à jour de 25+ providers : Cloudflare, Fastly, Akamai, Amazon CloudFront, Google Cloud CDN, Azure Front Door, BunnyCDN, KeyCDN, StackPath, Cloudinary, Imgix, jsDelivr, GitHub Pages, Netlify, Vercel, Shopify, WP Engine, et toute la suite. Et tu repars avec une réponse claire. Qui est devant, à quel point j'en suis sûr, et la ligne exacte qui a vendu la mèche.

URL à inspecter

Mode d'inspection

C'est mon serveur qui envoie la requête, pas ton navigateur, donc le CORS n'entre jamais en jeu. Et une fois la réponse revenue, l'URL est partie. Je ne la garde pas.

Ce qu'un détecteur de CDN te dit sur un site

Un détecteur de CDN lit les response headers et le DNS de n'importe quelle URL publique, puis nomme le content delivery network qui se trouve devant. Un CDN se glisse discrètement entre un site et ses visiteurs. Il met en cache les fichiers statiques au plus près de la personne qui charge la page. Il termine le TLS à l'edge, applique des règles de firewall, encaisse les vagues de DDoS bien avant qu'elles n'atteignent l'origin. Les visiteurs ne le voient jamais. Mais il ne peut pas s'empêcher de laisser des traces partout dans les response headers et le DNS, et une fois qu'on sait où regarder, franchement, elles crient. Un header cf-ray balance Cloudflare en une ligne. Un x-served-by qui transporte une chaîne cache-bos ? Ça, c'est Fastly. x-amz-cf-id veut dire CloudFront, et un CNAME qui se termine en .azureedge.net te livre Azure Front Door. Cet outil lit tout ça d'un coup et le condense en une seule réponse, au lieu de te faire plisser les yeux sur un dump de headers.

Il attaque sous deux angles à la fois. D'abord la couche HTTP : mon serveur balance une requête sur l'URL et lit en retour chaque header qui en sort. Puis la couche DNS. Il résout les enregistrements A, AAAA et CNAME, puis vérifie si l'un de ces hostnames retombe dans des plages que je sais appartenir à un CDN. En retour, tu obtiens une liste de providers confirmés, plus la preuve exacte qui a flaggé chacun d'eux. Moi, je m'en sers quand je passe un fournisseur au crible, ou que je démonte la stack d'un concurrent, ou que je traque un bug de latence bizarre. Ou, souvent, juste parce qu'un collègue a collé une URL dans le chat et que la curiosité m'a pris.

Comment la détection de CDN fonctionne vraiment

Normaliser l'URL. Je vire le path, la query, le fragment. Je garde le scheme et le hostname. Si ce que tu as collé ne se parse pas, tu reçois un avertissement plutôt que du n'importe quoi.
Lancer une requête HTTP via un endpoint côté serveur et choper tout le jeu de headers. Surtout les bizarres, les non-standard, ceux qui parlent vraiment : via, x-served-by, cf-ray, fly-request-id, x-amz-cf-id, x-vercel-id.
Résoudre le DNS via un second endpoint. L'apex d'abord, puis le sous-domaine www quand il y en a un, en récupérant les enregistrements A, AAAA et CNAME.
Comparer au catalogue. Chaque provider trimballe ses propres empreintes : tokens de header, patterns de réponse, suffixes CNAME, parfois une plage d'IP. Un hit fort et je le classe confirmed. Que des hits faibles ? Ça redescend à suspected. Dans les deux cas tu vois la ligne exacte qui a déclenché ça. Je ne te demande pas de me croire les yeux fermés.
Résumer. Le provider le plus fort devient le titre. Tout le reste atterrit sous « Evidence », pour que tu repères quand un site est servi par plus d'un CDN, ou posé sur un truc comme Vercel qui en enveloppe un autre par-dessous.

Cas d'usage courants pour un détecteur de CDN

Due diligence fournisseur. Avant de signer avec un éditeur SaaS, vérifie qu'il est bel et bien derrière un vrai CDN. Pas juste un origin à poil exposé en plein internet.
Diagnostic de performance. Une page rame depuis une région mais vole depuis une autre ? Un CDN mal configuré, c'est le suspect habituel. Trouve lequel sert le site avant de griller un après-midi à ouvrir un ticket chez le mauvais fournisseur.
Démontage concurrentiel. L'engineering comme le marketing deviennent curieux de ce que fait tourner un concurrent. Cet outil te donne la réponse en quelques secondes.
Audit de posture sécurité. Aucun signal de CDN, ça veut dire qu'un site est grand ouvert au DDoS volumétrique. C'est exactement pour ça que ça vit dans mon check de santé mensuel.
Vérification de migration. Tu viens de changer de CDN ? Confirme que le nouveau prend vraiment le trafic et que l'ancien enregistrement DNS n'a pas été laissé à pourrir derrière.
Recon bug bounty et red team. Le CDN façonne l'essentiel de ta surface d'attaque. Connaître le provider, ses règles, le WAF posé devant un asset, c'est par là que démarre toute mission honnête.

Limites et notes sur la vie privée

Sois honnête avec toi-même sur ce que c'est. De la déduction éclairée, pas parole d'évangile. Certains providers retirent leurs headers révélateurs exprès. Certains noeuds edge auto-hébergés se déguisent volontairement en Cloudflare ou en Akamai. Et pas mal de « CDN » sont en réalité d'autres CDN qui portent un logo emprunté, parce qu'un tas de produits enterprise sont bâtis sur Fastly ou CloudFront en dessous. Donc « aucun CDN détecté » ne veut pas toujours dire qu'il n'y a rien. Parfois ça veut juste dire que les headers ont été nettoyés et que le DNS se planque derrière un CNAME privé. Le revers, par contre, je lui fais plutôt confiance, et de loin : un hit fort sur un header, c'est du solide. Une valeur cf-ray, un champ x-amz-cf-id, un x-vercel-id de Vercel. Le provider lui-même émet ces trucs pour le diagnostic. On n'en fabrique pas un par accident.

Encore un truc bon à savoir. C'est mon serveur qui émet la requête, pas ton navigateur. Donc le CORS reste hors du coup, et ton IP n'est jamais refilée à l'origin que tu sondes. L'URL ? Lâchée à la seconde où la réponse revient. Le catalogue d'empreintes est livré là, directement dans la page, et je le rafraîchis chaque fois qu'un provider change discrètement ses signatures.

Questions fréquentes

Pourquoi le même site rapporte-t-il des CDN différents à des moments différents ?

Les gros sites éclatent leur trafic plus que tu ne le crois. Les pages marketing sur un CDN, l'API sur un autre, les assets statiques encore ailleurs. Ou alors tu les as attrapés en pleine migration, le DNS encore en train de basculer entre l'ancien et le nouveau. Pointe le détecteur sur le path exact qui t'intéresse vraiment, relance-le, puis lis l'onglet Evidence pour voir ce qui a matché.

Un site peut-il cacher son CDN à ce détecteur ?

Ouais. Un opérateur déterminé en est tout à fait capable. Retirer les headers de diagnostic, se planquer derrière un CNAME privé, mettre devant tout son propre sous-domaine, et il ne reste presque plus rien à choper pour moi. À ce stade, le détecteur se rabat sur les indices DNS, et ceux-là peuvent être neutralisés aussi. Quelqu'un qui ne veut vraiment pas que tu saches ce qu'il fait tourner gagne en général ce bras de fer.

« Aucun CDN détecté », est-ce pareil que « aucun CDN » ?

Pas tout à fait. Plein de petits sites tournent vraiment à nu, sans CDN nulle part. Mais un gros site enterprise peut être garé derrière un CDN rendu volontairement invisible. Donc quand la cible n'est clairement pas petite, lis « aucun signal » comme non concluant. Pas comme une preuve qu'il n'y a rien.

L'outil détecte-t-il les WAF et les produits de sécurité ?

Jusqu'à un certain point. Quand le WAF voyage avec un CDN majeur (Cloudflare, Akamai, Fastly, AWS WAF), repérer le CDN repère le WAF gratos. Un WAF autonome sans CDN derrière, ou un filtre on-prem ? Pas encore dans le catalogue. C'est sur ma liste. Juste pas dans l'outil aujourd'hui.

L'URL que j'inspecte est-elle loggée ?

Non. L'URL ne voyage que jusqu'aux endpoints REST publics du site, uniquement pour récupérer les headers et le DNS de cette seule recherche. Je ne la logge pas. La réponse disparaît à la seconde où la session de ta page se termine. Rien de ta recherche ne reste après coup.