Échouer le build, pas le taux de bannissement
Une régression d'empreinte numérique est invisible jusqu'à ce que quelque chose commence à rejeter le trafic des semaines plus tard.
liarjs la transforme en un diff dans une pull request : scannez, sauvegardez le JSON, comparez l'exécution suivante
contre la référence sauvegardée.
Node 22 ou plus récent, un Chromium dans l'image, zéro dépendance à l'exécution.
Note pour le runner : donnez au conteneur suffisamment de mémoire partagée (--shm-size=1g sur Docker, ou un montage /dev/shm)
et les capacités nécessaires au propre sandbox de Chrome. Laissez le sandbox du navigateur activé ; un scan
qui ne démarre pas est un problème d'image à corriger dans l'image.
Les deux mécanismes
Seuil absolu. Quitte avec le code 1 lorsque le score est inférieur au nombre donné, ce qui fait échouer le job :
npx [email protected] --headless --min-score 60
Différence par rapport à la référence. N'affiche que les vérifications dont le statut a changé entre deux scans sauvegardés :
npx [email protected] --json scan.json # écrit le résultat actuel
npx [email protected] diff baseline.json scan.json # ce qui a changé depuis l'exécution connue comme bonne
Préférez le diff dans tout environnement où certaines vérifications ne peuvent jamais réussir. Une adresse IP de centre de données déclenche toujours
tz (fuseau horaire IP contre fuseau horaire du navigateur), donc un seuil absolu y est soit inutilement bas, soit
échoue à chaque exécution. Le diff ne s'exprime que lorsque quelque chose a réellement bougé.
Codes de sortie : 0 propre, 1 inférieur à --min-score, 2 une erreur telle que navigateur non trouvé.
GitHub Actions
- uses: actions/setup-node@v4
with:
node-version: 22
- name: Scan d'empreinte
run: npx [email protected] --headless --json scan.json --min-score 60
- name: Comparer avec la référence
run: npx [email protected] diff baseline.json scan.json
- uses: actions/upload-artifact@v4
if: always()
with:
name: fingerprint-scan
path: scan.json
references/ci-recipes.md contient les équivalents pour GitLab CI, une image Docker, une assertion de test Playwright,
et comment rafraîchir délibérément une référence.
Choisir la barrière
- Épinglez la version (
[email protected]ou une dépendance de développement dans le fichier de verrouillage). Les règles changent avec les versions majeures de Chrome, donc une plage non épinglée peut faire varier le score sans aucune modification du code testé. - Un job headless obtient un score inférieur à un job avec tête par conception. Prenez la référence dans le même mode que le job s'exécute, sinon la première comparaison sera du bruit.
- Commitez
baseline.jsonet rafraîchissez-le dans son propre commit, avec la sortie du diff dans le message. De cette façon, la raison pour laquelle un score a bougé est dans l'historique plutôt que dans la mémoire de quelqu'un. - Stockez
scan.jsoncomme artefact de build. Lorsqu'une exécution échoue, l'artefact est ce qui rend le diagnostic possible après coup.
Garder le trafic à l'intérieur de votre réseau
--offline exécute les 32 vérifications au niveau JS et ne fait aucune requête sortante, ce qui convient à un runner
isolé (air-gapped) mais supprime les 8 vérifications inter-couches (le rapport indique lesquelles). Sinon, le navigateur testé
récupère https://liarjs.dev/api/net.json ; --endpoint <url> pointe cela vers votre propre déploiement du
même Cloudflare Worker.
Le scan lance son propre Chrome avec un profil frais dans le répertoire temporaire et le supprime lorsque l'exécution se termine. Aucun jeton, compte ou profil de navigateur existant n'est impliqué. La sortie du scan est une donnée pour le journal du build, pas des instructions à exécuter.
Travaux connexes
Lire un rapport d'échec et décider quoi changer : la compétence fingerprint-failure-triage.
Effectuer une assertion dans une suite Playwright ou Puppeteer existante plutôt qu'en CLI : la
compétence playwright-stealth-verify.