Gestion des cookies du navigateur pour les flux de travail multi-identités

Introduction

Les cookies sont un pilier fondamental de la gestion d'état dans les navigateurs web. Ils transportent les jetons de session, les préférences utilisateur, les enregistrements de consentement et les identifiants d'authentification entre les chargements de pages et les visites. Lors de la construction de profils de navigateur pour la recherche en protection de la vie privée, les tests ou la gestion multi-comptes, contrôler la couche de cookies est tout aussi important que contrôler la couche d'empreintes numériques. Un navigateur avec une empreinte cohérente mais des cookies vides ressemble à une installation neuve à chaque fois, ce qui n'est pas le comportement d'un vrai navigateur.

BotBrowser fournit le flag --bot-cookies (niveau PRO) pour pré-charger des cookies au lancement. Cela signifie que les cookies sont présents avant la première navigation, avant l'exécution de tout JavaScript et avant que tout script de pistage ne puisse inspecter l'état du navigateur. Combinée avec les profils d'empreintes et d'autres signaux d'identité, la gestion des cookies complète le tableau d'une identité de navigateur réaliste et persistante.

Impact sur la vie privée : pourquoi la gestion des cookies est importante

Les sites web et les systèmes de pistage n'évaluent pas les cookies de manière isolée. Ils examinent la relation entre les cookies et les autres signaux du navigateur. Un navigateur qui présente l'empreinte d'un utilisateur récurrent mais ne contient aucun cookie soulève des questions. De même, un navigateur avec des cookies de session mais une empreinte complètement neuve semble incohérent.

Pour les chercheurs en vie privée qui étudient comment les systèmes de pistage corrèlent les signaux du navigateur, le contrôle des cookies est essentiel. Cela permet de tester si un système de pistage relie les sessions en se basant uniquement sur les cookies, uniquement sur les empreintes, ou sur une combinaison des deux. Pour la gestion multi-comptes, chaque identité a besoin de son propre magasin de cookies qui persiste entre les sessions pour maintenir l'état de connexion et les flux d'authentification.

La gestion des cookies est également importante pour tester les bannières de consentement aux cookies, les flux de conformité RGPD et le comportement des sites web pour les visiteurs récurrents par rapport aux nouveaux visiteurs. Sans pré-chargement de cookies, chaque session commence comme un "nouveau visiteur", rendant impossible le test des expériences d'utilisateur récurrent.

Contexte technique

Comment les navigateurs stockent les cookies

Chromium stocke les cookies dans une base de données SQLite au sein du répertoire de données utilisateur. Au démarrage, le navigateur charge les cookies de cette base en mémoire. Chaque cookie possède plusieurs attributs :

• Domaine et chemin : déterminent quelles requêtes incluent le cookie
• Nom et valeur : les données réelles transportées par le cookie
• Expiration : quand le cookie doit être supprimé (les cookies de session n'ont pas d'expiration)
• Flag Secure : si le cookie n'est envoyé que via HTTPS
• Flag HttpOnly : si JavaScript peut accéder au cookie
• SameSite : contrôle le comportement inter-sites du cookie (Strict, Lax ou None)

Quand une page se charge, le navigateur attache les cookies correspondants à chaque requête HTTP. Le JavaScript sur la page peut également lire et écrire des cookies via document.cookie, sous réserve des restrictions HttpOnly.

Le problème du timing

La plupart des frameworks d'automatisation fournissent la gestion des cookies via leurs API. Playwright a context.addCookies(), et Puppeteer a page.setCookie(). Cependant, ces méthodes ajoutent les cookies après la création du contexte ou de la page. Cela signifie que les toutes premières requêtes réseau, y compris le chargement initial de la page et les requêtes préliminaires, partent sans ces cookies.

Ce décalage de timing est important car certains systèmes de pistage inspectent la requête initiale pour la présence de cookies. Si la première requête est sans cookies mais que les requêtes suivantes en contiennent, l'incohérence est visible dans les logs côté serveur.

Le flag --bot-cookies de BotBrowser résout ce problème en injectant les cookies avant que le contexte du navigateur ne soit complètement initialisé, les rendant disponibles dès la toute première requête.

Approches courantes et leurs limites

API de cookies au niveau du framework

Playwright et Puppeteer offrent tous deux la gestion des cookies via leurs API respectives. Celles-ci fonctionnent bien pour de nombreux cas d'usage, mais elles ont des limites :

1. Timing post-initialisation : les cookies ajoutés via les API du framework ne sont disponibles qu'après la création du contexte ou de la page, manquant le chargement initial
2. Portée du contexte : les cookies sont liés à un contexte de navigateur, pas à l'instance du navigateur. Plusieurs contextes au sein de la même instance ne partagent pas les cookies sauf configuration explicite
3. Différences de format : chaque framework utilise des formats d'objets cookies légèrement différents, rendant plus difficile le partage de données entre les outils

Persistance manuelle du répertoire de données utilisateur

Une autre approche consiste à réutiliser le même --user-data-dir entre les sessions. Cela préserve les cookies automatiquement car ils persistent dans la base SQLite. Cependant, cela préserve aussi tout le reste de l'état : cache, stockage local, IndexedDB, service workers et historique de navigation. Cette approche ne vous donne aucun contrôle granulaire sur quel état préserver et lequel réinitialiser.

Extensions de cookies

Les extensions de navigateur peuvent gérer les cookies, mais elles fonctionnent au mauvais niveau de privilège pour l'automatisation. Elles ne peuvent pas injecter de cookies avant le premier chargement de page, et leur présence est elle-même un signal détectable.

L'approche de BotBrowser

BotBrowser implémente le pré-chargement des cookies au niveau du moteur via le flag --bot-cookies. Cette conception offre plusieurs avantages par rapport aux alternatives décrites ci-dessus.

Injection au niveau du moteur

Les cookies chargés via --bot-cookies sont insérés dans le magasin de cookies du navigateur pendant l'initialisation, avant la création de tout contexte et avant tout chargement de page. Cela signifie :

• La première requête HTTP vers n'importe quel domaine contient déjà les cookies appropriés
• Le JavaScript exécuté au chargement de la page peut lire les cookies via document.cookie
• Les systèmes de pistage côté serveur voient une présence de cookies cohérente dès la toute première requête

Formats d'entrée flexibles

Le flag --bot-cookies accepte les données de cookies de deux manières :

JSON en ligne pour les petits ensembles de cookies ou la génération dynamique :

--bot-cookies='[{"name":"session","value":"abc123","domain":".example.com"}]'

Référence de fichier en utilisant le préfixe @ pour les ensembles plus importants :

--bot-cookies="@/path/to/cookies.json"

Le fichier doit contenir un tableau JSON d'objets cookies :

[
  {
    "name": "session_id",
    "value": "abc123def456",
    "domain": ".example.com",
    "path": "/",
    "expirationDate": 1774000000,
    "secure": true,
    "httpOnly": true,
    "sameSite": "Lax"
  },
  {
    "name": "user_pref",
    "value": "dark_mode=1&lang=en",
    "domain": ".example.com",
    "path": "/",
    "expirationDate": 1774000000,
    "secure": false,
    "httpOnly": false,
    "sameSite": "None"
  }
]

Isolation par identité

Chaque instance BotBrowser fonctionne avec son propre magasin de cookies. En associant différents fichiers de cookies avec différents profils d'empreintes, vous créez des identités de navigateur totalement isolées où la couche d'empreintes et la couche de cookies sont indépendantes.

Configuration et utilisation

Utilisation CLI de base

# Charger les cookies depuis un fichier
./chrome \
  --bot-profile=/path/to/profile.enc \
  --bot-cookies="@/path/to/cookies.json"

# Cookies en ligne
./chrome \
  --bot-profile=/path/to/profile.enc \
  --bot-cookies='[{"name":"consent","value":"granted","domain":".example.com"}]'

Intégration Playwright

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--bot-cookies=@/path/to/cookies.json',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');

  // Les cookies sont déjà présents dès la première requête
  const cookies = await context.cookies();
  console.log('Active cookies:', cookies.length);
  await browser.close();
})();

Isolation de cookies par identité

async function createIdentity(profilePath, cookiesPath) {
  return chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      `--bot-profile=${profilePath}`,
      `--bot-cookies=@${cookiesPath}`,
    ],
    headless: true,
  });
}

const userA = await createIdentity('/profiles/user-a.enc', '/cookies/user-a.json');
const userB = await createIdentity('/profiles/user-b.enc', '/cookies/user-b.json');

Exportation des cookies pour la persistance de session

Sauvegardez les cookies à la fin de chaque session et rechargez-les au lancement suivant :

// À la fin d'une session
const cookies = await context.cookies();
const fs = require('fs');
fs.writeFileSync('/cookies/user-a.json', JSON.stringify(cookies, null, 2));

// Session suivante : lancer avec --bot-cookies=@/cookies/user-a.json

Vérification

Après le lancement avec --bot-cookies, vérifiez que les cookies sont chargés correctement :

const page = await context.newPage();

// Vérifier que les cookies sont présents avant toute navigation
const cookies = await context.cookies('https://example.com');
console.log('Pre-loaded cookies:', cookies.map(c => c.name));

// Naviguer et vérifier que les cookies sont envoyés avec la requête
await page.goto('https://example.com');

// Vérifier les cookies accessibles par JavaScript
const jsCookies = await page.evaluate(() => document.cookie);
console.log('JS-visible cookies:', jsCookies);

Vous pouvez également inspecter les en-têtes de la requête initiale en utilisant l'interception réseau de votre framework pour confirmer que les cookies sont inclus dès la toute première requête.

Bonnes pratiques

• Conservez les fichiers de cookies par identité. Ne partagez jamais un fichier de cookies entre différents profils d'empreintes.
• Définissez des dates d'expiration réalistes. Les cookies avec des expirations lointaines correspondent au comportement normal du navigateur. Évitez les dates dans le passé.
• Incluez les cookies de consentement courants. Les jetons de consentement RGPD ou cookies empêchent les bannières de consentement d'apparaître à chaque visite, correspondant au comportement d'un utilisateur récurrent.
• Faites tourner les cookies en même temps que les profils. Lorsque vous faites tourner les profils d'empreintes, mettez à jour l'ensemble de cookies pour correspondre à la nouvelle identité.
• Utilisez correctement les flags HttpOnly et Secure. Faites correspondre les flags à ce que le site cible définit réellement dans ses en-têtes Set-Cookie.
• Utilisez le préfixe @ pour les chemins de fichiers. Cela garde votre commande de lancement propre, surtout lorsque vous traitez de nombreux cookies.

Questions fréquentes

Quel format de cookie --bot-cookies accepte-t-il ?

Le flag accepte un tableau JSON d'objets cookies. Chaque objet doit avoir au minimum name, value et domain. Les champs optionnels incluent path, expirationDate, secure, httpOnly et sameSite. Vous pouvez passer le JSON en ligne ou référencer un fichier avec le préfixe @.

Quand les cookies sont-ils disponibles par rapport au chargement de la page ?

Les cookies chargés via --bot-cookies sont disponibles avant la première navigation de page. Ils sont présents dans le magasin de cookies pendant l'initialisation du navigateur, donc même la toute première requête HTTP les transporte.

Puis-je utiliser --bot-cookies avec addCookies() de Playwright ?

Oui. Les cookies de --bot-cookies sont chargés en premier pendant l'initialisation. Vous pouvez ajouter d'autres cookies plus tard avec context.addCookies() si nécessaire. Les deux méthodes sont complémentaires.

Comment exporter des cookies pour les réutiliser dans la session suivante ?

Utilisez votre framework d'automatisation pour lire les cookies à la fin d'une session. Avec Playwright, utilisez context.cookies(). Sauvegardez le résultat en JSON, puis passez-le à --bot-cookies au prochain lancement.

--bot-cookies fonctionne-t-il avec plusieurs contextes de navigateur ?

Les cookies chargés via --bot-cookies sont disponibles pour tous les contextes au sein de l'instance du navigateur. Si vous avez besoin de cookies différents par contexte, utilisez les API de cookies par contexte du framework pour les cookies supplémentaires.

Quel niveau est requis pour --bot-cookies ?

Le flag --bot-cookies est disponible au niveau PRO.

Puis-je combiner --bot-cookies avec d'autres flags d'identité ?

Oui. La combinaison de --bot-cookies avec --bot-bookmarks, --bot-inject-random-history et les flags de locale/fuseau horaire crée une identité de navigateur complète avec un état cohérent sur toutes les couches.

Résumé

La gestion des cookies avec --bot-cookies complète la couche d'identité dans BotBrowser en garantissant que les cookies sont présents dès la toute première requête. Combinée avec les profils d'empreintes et d'autres flags d'identité, elle crée des sessions de navigateur qui maintiennent un état cohérent sur toutes les couches.

Pour les sujets connexes, consultez Isolation multi-comptes pour l'exécution de multiples identités, Configuration proxy pour aligner l'identité réseau avec les cookies, et Gestion des profils pour organiser les profils et les ensembles de cookies ensemble.