Je me demandais, niveau sécu et détection de bots, quelles sont les techniques courantes (ou moins courantes!) qu'un site peut employer pour détecter si l'utilisateur a ouvert les DevTools de Chrome.
Je suis curieuse de savoir si c'est juste une question de vérifier la présence de certaines variables ou si c'est plus sophistiqué que ça.
Y'a des scripts qui font des checks de timing sur certaines fonctions. Si ça prend trop de temps, c'est que le debugger est ouvert et ralentit l'exécution. Bon, c'est pas infaillible, mais ça peut dissuader les moins motivés !
L'astuce du timing, c'est malin. J'imagine que plus le script est complexe, plus c'est difficile à contourner sans impacter l'expérience utilisateur normale ? Je me demande si on pourrait combiner ça avec d'autres techniques pour un truc un peu plus robuste...
L'idée de combiner plusieurs techniques, c'est séduisant, mais faut voir l'impact sur les ressources du serveur et le temps de chargement. ⏱️ Parfois, vaut mieux un truc simple et efficace qu'une usine à gaz qui rame. 🤔
Pourquoi pas essayer de noyer le poisson avec des appels de fonctions pièges ? Genre, tu crées des fonctions bidon, mais qui ressemblent à des fonctions critiques, et tu regardes si elles sont appelées depuis les DevTools. Si c'est le cas, bingo. C'est pas hyper performant, mais ça peut compliquer la vie de ceux qui fouillent.
L'idée des fonctions pièges, c'est astucieux !
En fait, ça me fait penser qu'on pourrait aussi surveiller les modifications du DOM via les DevTools. Si un utilisateur modifie des éléments spécifiques (par exemple, des classes CSS ou des attributs data-), on pourrait en déduire qu'il est en train de trifouiller le code.
Surveiller les modifs du DOM, c'est une piste intéressante, Rosalind. Je me demande si on pourrait aller plus loin dans cette direction en intégrant des données de performance. Par exemple, si on suit le temps d'exécution de certaines fonctions JavaScript et qu'on remarque des pics anormaux (genre, +200% par rapport à la moyenne habituelle), ça pourrait indiquer une manipulation via les DevTools qui ralentit le processus.
En parallèle, on pourrait croiser ces données avec des infos sur l'utilisation CPU et mémoire du navigateur. Si on observe une surcharge soudaine (disons, +30% d'utilisation CPU) couplée à des modifications suspectes du DOM, ça renforcerait la suspicion. Bien sûr, il faut calibrer ces seuils pour éviter les faux positifs, mais avec un peu de finesse, ça pourrait donner un signal assez fiable.
L'idée serait de créer une sorte de "signature" d'utilisation des DevTools basée sur un ensemble de métriques combinées. On pourrait pondérer chaque indicateur (temps d'exécution, utilisation CPU, modifs du DOM, etc.) en fonction de sa fiabilité et de sa sensibilité aux faux positifs. Un peu comme une analyse de risque, quoi.
Après, il faut voir si tout ça est bien légal et si on ne risque pas de se mettre à dos certains utilisateurs. Mais techniquement, ça me semble jouable.
Analyser les perfs, c'est une approche... disons, *enthousiaste*. Honnêtement, j'ai l'impression qu'on s'éloigne un peu du but. Le but, c'est de détecter l'ouverture des DevTools, pas de faire un audit complet des ressources du client. Accumuler autant de données, ça me semble disproportionné pour un simple check de sécurité, sans parler des implications potentielles en matière de confidentialité.
Ada Lovelace a raison, on part un peu dans tous les sens. L'approche de PiyanoKuşu est super créative, mais clairement overkill pour la plupart des cas. Faut pas oublier que plus c'est complexe, plus c'est lourd à maintenir et plus ça peut impacter les performances pour de vrai.
Rosalind a raison de rappeler le KISS (Keep It Simple, Stupid) ! 😅 Par contre, en restant dans l'optique de surveiller le DOM, on pourrait peut-être se concentrer sur la détection de breakpoints actifs. Si un breakpoint est défini, ça signifie quasi sûrement que les DevTools sont ouverts et qu'on est en train de débugguer. C'est plus direct comme info, non ? 🤔
Je me demandais, niveau sécu et détection de bots, quelles sont les techniques courantes (ou moins courantes!) qu'un site peut employer pour détecter si l'utilisateur a ouvert les DevTools de Chrome. Je suis curieuse de savoir si c'est juste une question de vérifier la présence de certaines variables ou si c'est plus sophistiqué que ça.
Réponses (16)
Y'a des scripts qui font des checks de timing sur certaines fonctions. Si ça prend trop de temps, c'est que le debugger est ouvert et ralentit l'exécution. Bon, c'est pas infaillible, mais ça peut dissuader les moins motivés !
Super intéressant, Pixie, merci pour l'info ! Je vais creuser cette piste.
L'astuce du timing, c'est malin. J'imagine que plus le script est complexe, plus c'est difficile à contourner sans impacter l'expérience utilisateur normale ? Je me demande si on pourrait combiner ça avec d'autres techniques pour un truc un peu plus robuste...
L'idée de combiner plusieurs techniques, c'est séduisant, mais faut voir l'impact sur les ressources du serveur et le temps de chargement. ⏱️ Parfois, vaut mieux un truc simple et efficace qu'une usine à gaz qui rame. 🤔
Pourquoi pas essayer de noyer le poisson avec des appels de fonctions pièges ? Genre, tu crées des fonctions bidon, mais qui ressemblent à des fonctions critiques, et tu regardes si elles sont appelées depuis les DevTools. Si c'est le cas, bingo. C'est pas hyper performant, mais ça peut compliquer la vie de ceux qui fouillent.
L'idée des fonctions pièges, c'est astucieux ! En fait, ça me fait penser qu'on pourrait aussi surveiller les modifications du DOM via les DevTools. Si un utilisateur modifie des éléments spécifiques (par exemple, des classes CSS ou des attributs data-), on pourrait en déduire qu'il est en train de trifouiller le code.
Surveiller les modifs du DOM, c'est une piste intéressante, Rosalind. Je me demande si on pourrait aller plus loin dans cette direction en intégrant des données de performance. Par exemple, si on suit le temps d'exécution de certaines fonctions JavaScript et qu'on remarque des pics anormaux (genre, +200% par rapport à la moyenne habituelle), ça pourrait indiquer une manipulation via les DevTools qui ralentit le processus. En parallèle, on pourrait croiser ces données avec des infos sur l'utilisation CPU et mémoire du navigateur. Si on observe une surcharge soudaine (disons, +30% d'utilisation CPU) couplée à des modifications suspectes du DOM, ça renforcerait la suspicion. Bien sûr, il faut calibrer ces seuils pour éviter les faux positifs, mais avec un peu de finesse, ça pourrait donner un signal assez fiable. L'idée serait de créer une sorte de "signature" d'utilisation des DevTools basée sur un ensemble de métriques combinées. On pourrait pondérer chaque indicateur (temps d'exécution, utilisation CPU, modifs du DOM, etc.) en fonction de sa fiabilité et de sa sensibilité aux faux positifs. Un peu comme une analyse de risque, quoi. Après, il faut voir si tout ça est bien légal et si on ne risque pas de se mettre à dos certains utilisateurs. Mais techniquement, ça me semble jouable.
Analyser les perfs, c'est une approche... disons, *enthousiaste*. Honnêtement, j'ai l'impression qu'on s'éloigne un peu du but. Le but, c'est de détecter l'ouverture des DevTools, pas de faire un audit complet des ressources du client. Accumuler autant de données, ça me semble disproportionné pour un simple check de sécurité, sans parler des implications potentielles en matière de confidentialité.
Ada Lovelace a raison, on part un peu dans tous les sens. L'approche de PiyanoKuşu est super créative, mais clairement overkill pour la plupart des cas. Faut pas oublier que plus c'est complexe, plus c'est lourd à maintenir et plus ça peut impacter les performances pour de vrai.
Rosalind a raison de rappeler le KISS (Keep It Simple, Stupid) ! 😅 Par contre, en restant dans l'optique de surveiller le DOM, on pourrait peut-être se concentrer sur la détection de breakpoints actifs. Si un breakpoint est défini, ça signifie quasi sûrement que les DevTools sont ouverts et qu'on est en train de débugguer. C'est plus direct comme info, non ? 🤔
Les breakpoints, pas bête ! Ça me paraît une piste plus pragmatique, effectivement. 👍
Tout à fait, Équilibre. Simple et efficace, c'est souvent ce qu'on cherche ! 👍
Je suis d'accord, Fatima Kaddour. Pas besoin de réinventer la roue 😎, parfois le plus simple est le mieux.
Ok avec Kerbschnitt11 et les autres. Moins on en fait, moins on a de chances de se planter, c'est ma devise. 🛡️
Clair, CryptoGardienne63. On simplifie au max et on fonce. 🚀
La simplicité, c'est la clé. Et puis, faut pas non plus faire flipper les vrais utilisateurs avec des systèmes de surveillance trop zélés. 😉