Le signal a 0 euros que personne ne regarde
On a contourne tous les checks de ton WAF. Tous. Le seul truc qu’on ne peut pas contourner coute 0 euros et ne necessite aucun JavaScript.
Un vrai navigateur Chrome qui charge une page, voila ce que ton serveur voit dans ses access logs :
GET /page -> 200 (12KB)
GET /css/main.css -> 200 (8KB)
GET /js/app.js -> 200 (45KB)
GET /js/vendor.js -> 200 (92KB)
GET /img/hero.webp -> 200 (124KB)
GET /fonts/inter.woff2 -> 200 (18KB)
GET /favicon.ico -> 200 (1KB)7 requetes. ~300KB. Pour une seule page.
Un bot sophistique, meme celui qui passe ton WAF, tes checks toString, ta detection behavioral, tout - voila ce que ton serveur voit :
GET /page -> 200 (12KB)1 requete. 12KB. C’est tout.
Pas pour une raison technique. Pour une raison economique.
Charger les 300KB de ressources de chaque page comme un vrai navigateur, multiplie par des milliers de pages, sur des proxies residentiels factures au gigaoctet.. ca multiplie le cout de l’operation par 25. Aucun bot ne survivra longtemps a x25 sur ses couts de bande passante juste pour charger des images qu’il ne regardera jamais.
C’est une contradiction structurelle. Tu ne la resous pas avec du meilleur code.
Pendant ce temps, la correlation cote serveur est triviale. Une IP qui fait 100 GET de pages HTML et 0 GET de CSS/JS/images, c’est un bot. Un script de 20 lignes sur tes access logs. Gratuit. Passif. Et structurellement resistant.
Ton WAF a six chiffres tourne chez l’adversaire. Tes access logs tournent chez toi.
C’est quand la derniere fois que quelqu’un a regarde le ratio HTML/assets dans vos logs ?
Le trafic a un rythme circadien
Un humain browse vite le matin. Routine, scan, clic rapide. 1 a 3 secondes entre les pages.
Le soir il ralentit. Lecture approfondie, scroll lent, pauses. 4 a 8 secondes.
A 3h du matin, s’il est encore debout, c’est tres lent. Fatigue, relecture, hesitations.
Un bot crawle a la meme vitesse a 10h, a 15h, a 3h du matin. La distribution de ses delais inter-pages est plate. Meme cadence, meme rythme, quelle que soit l’heure.
C’est un signal que tres peu de WAF exploitent. La plupart se contentent de verifier le delai moyen entre les requetes. Presque aucun ne correle ce delai avec le fuseau horaire de l’IP.
Et pourtant le check est trivial : tu geolocalises l’IP, tu en deduis l’heure locale, et tu verifies que le rythme de navigation est coherent. Une IP francaise qui crawle a 3h du matin avec des delais de 1,5 secondes entre les pages.. c’est pas un insomniaque, c’est un bot.
En testant, on a contourne en assignant un “fuseau horaire simule” a chaque IP et en variant les delais en fonction. Matin simule = rapide. Soir simule = lent. Mais ca rajoute une couche de complexite que la plupart des bots ne gerent pas.
Le trafic a un rythme circadien. Si ton bot n’en a pas, les bons WAF le voient.
Pourquoi ces signaux tiennent
Deux points communs entre le ratio HTML/assets et le rythme circadien :
Ils vivent cote serveur. Le bot n’y a pas acces. Il ne peut pas falsifier ce que tes logs enregistrent. Il ne peut pas modifier l’heure a laquelle ta geolocalisation le place. Le terrain est le tien.
Ils exploitent l’economie, pas la technique. Le ratio HTML/assets tient parce que charger toutes les ressources coute trop cher. Le rythme circadien tient parce que le simuler correctement ajoute de la complexite operationnelle. Chaque signal structural qu’un bot doit simuler est un cout supplementaire. Empile suffisamment de couts, et l’operation ne tient plus financierement.
Ton WAF est un ralentisseur. Tes logs sont un mur. Combine les deux.