Fingerprinting navigateur

Ce que vérifie ce contrôle

Analyse les scripts chargés et le comportement à l’exécution pour repérer les techniques de fingerprinting connues :

• SDK commerciaux — FingerprintJS Pro (fpjs.io, api.fpjs.io, CNAMEs metrics.<votre-domaine>), ThreatMetrix, IPQS, SEON.
• Abus de l’API Canvas — appels à canvas.toDataURL() ou getImageData() sur des éléments cachés, hors écran ou OffscreenCanvas juste après le rendu d’une chaîne fixe.
• Sondes WebGL — lecture de WEBGL_debug_renderer_info (chaînes vendeur/renderer GPU) sans contexte 3D visible.
• Fingerprinting AudioContext — instanciation d’un OfflineAudioContext, exécution d’un oscillateur et hachage du buffer.
• Énumération de polices — mesure de la largeur de chaînes de test sur des centaines de familles de polices pour détecter celles installées.

MetricSpot maintient une liste d’autorisation pour les SDK analytics courants (GA4, Plausible, Fathom) qui touchent certaines de ces API de manière bénigne, donc le contrôle se déclenche uniquement quand le motif correspond à un fingerprinting actif.

Pourquoi c’est important

Les régulateurs ont fermé la faille du « ce n’est pas un cookie donc le consentement ne s’applique pas ». Les lignes directrices 2023 de l’EDPB sur l’art. 5(3) ePrivacy considèrent toute technique côté client qui lit ou écrit des informations sur l’appareil d’un utilisateur — fingerprinting compris — comme nécessitant le même consentement préalable, éclairé et opt-in que les cookies. La CNIL, l’ICO et la DPC ont fait écho à cette position.

Cela signifie qu’un script de fingerprinting qui se déclenche avant que le visiteur accepte votre bannière de consentement cookies constitue la même infraction que poser un cookie _ga avant consentement — et l’application est active. La CNIL a infligé une amende de 40 M€ à Criteo en 2023 en partie sur cette base.

Au-delà de l’angle juridique : le fingerprinting identifie les utilisateurs à travers les sessions et le réseau. Si un SDK tiers fuit l’empreinte, vous avez aidé à construire un profil fantôme de chaque visiteur.

Comment corriger

C’est une règle de détection, pas un drapeau de configuration. Le correctif consiste à auditer ce qui s’exécute et à le conditionner au consentement.

1. Inventaire. Ouvrez DevTools → Network → filtrez par Initiator et cherchez les scripts signalés par MetricSpot. Remontez chacun jusqu’à une règle de tag manager ou un <script> dans votre template. Si vous ne savez pas pourquoi il est là, il ne devrait pas y être.

2. Décidez si vous en avez besoin. La détection de fraude sur une page de checkout peut justifier FingerprintJS Pro. Une landing page marketing presque jamais. L’exception EDPB pour « strictement nécessaire » est étroite — la sécurité et la prévention de la fraude peuvent qualifier, l’enrichissement analytique non.

3. Conditionnez au consentement. Si vous gardez le script, chargez-le uniquement après opt-in. Avec un CMP (OneTrust, Cookiebot, Iubenda, Klaro) :

<!-- Ne pas charger directement -->
<script src="https://fpjs.io/web/v3/<key>/loader.js"></script>

<!-- Conditionner via CMP - exemple : Klaro -->
<script type="text/plain" data-name="fingerprintjs"
        src="https://fpjs.io/web/v3/<key>/loader.js"></script>

Puis dans votre klaro-config.js :

services: [{
  name: "fingerprintjs",
  purposes: ["security"],
  required: false,
  default: false,
}]

4. Détection côté serveur. Si un fournisseur propose un SDK côté serveur (le serverApi de FingerprintJS Pro), préférez-le sur les routes authentifiées — il reste à l’intérieur de votre périmètre de confiance first-party et est plus facile à auditer.

5. Documentez-le. Mettez à jour votre politique de confidentialité pour nommer le fournisseur, la finalité (« prévention de la fraude au paiement »), les données collectées et la durée de conservation. Une formule générique ne suffit pas.

Combinez ce contrôle avec traqueurs tiers — les deux règles examinent le même inventaire de scripts sous des angles différents.

Questions fréquentes

Le « tracking sans cookies » est-il légal dans l’UE ?

Non, pas sans consentement. L’argumentaire marketing selon lequel sans cookies = sans consentement est faux selon l’interprétation actuelle de l’EDPB. Le déclencheur du consentement est la lecture ou l’écriture depuis l’appareil, quel que soit le mécanisme.

Et les analytics côté serveur comme Plausible ou Fathom ?

C’est bon. Ils dérivent un hash rotatif quotidien à partir de l’IP + user-agent sur le serveur, ne le stockent jamais et ne sondent pas les API côté client. La liste d’autorisation de MetricSpot les exclut.

Mon équipe fraude a besoin de FingerprintJS sur le checkout. Puis-je le garder ?

Probablement oui, avec un périmètre étroit : chargez-le uniquement sur /checkout et /login, documentez la finalité sécurité dans votre politique de confidentialité et appuyez-vous sur l’exception EDPB « strictement nécessaire à un service explicitement demandé par l’utilisateur ». Faites valider par un conseil juridique — la frontière dépend de la juridiction.