Capturer des pages grâce aux cookies de session

Pourquoi les cookies débloquent les captures authentifiées

Les sites s’appuient sur des cookies pour maintenir la session : jetons opaques, identifiants ou valeurs signées renvoyés à chaque requête. Si votre worker de capture présente le même jeu de cookies qu’un utilisateur connecté, le serveur renvoie le même HTML et le même bootstrap JavaScript — les pixels reflètent donc la production.

Ce modèle convient lorsque vous disposez déjà d’un backend de confiance capable d’émettre ou de rafraîchir des sessions (échange OAuth, consommateur SAML ou API de login maison). Vous transmettez le résultat à ScreenshotCenter plutôt que d’embarquer des mots de passe dans les étapes.

Format des chaînes et paramètres

La plupart des intégrations attendent une chaîne compatible avec l’en-tête Cookie : paires nom=valeur séparées par ; . Les attributs Path, Domain, Secure ou HttpOnly sont en principe posés par le serveur lors du stockage navigateur ; en injection manuelle pour l’API, on transmet surtout les segments nom=valeur requis par l’origine.

session_id=abc123; csrf_token=xyz789; preferred_lang=fr

Encodez l’URL si vous passez la chaîne en paramètre de requête. En JSON, placez la chaîne brute et laissez le client encoder le corps.

Capturer sans rejouer l’interface de connexion

Éviter l’UI de login accélère les jobs et réduit les sélecteurs fragiles. Cela limite aussi les CAPTCHA et MFA incompatibles avec l’exécution sans surveillance. Déroulé type :

1. Votre backend authentifie l’utilisateur ou un principal de service comme d’habitude.
2. Vous lisez les cookies applicables à l’hôte cible (respect des règles Domain et Path).
3. Vous appelez l’API de capture avec ces cookies et l’URL visée.
4. Vous ajoutez si besoin Referer, User-Agent ou d’autres en-têtes pour coller à une empreinte réelle.

Si l’application émet des jetons CSRF par page, vérifiez que le cookie correspond au document sur le point d’être rendu.

Associer cookies et paramètres HTTP

Certaines SPA conditionnent les appels API aux en-têtes autant qu’aux cookies. L’API de capture peut souvent envoyer des en-têtes supplémentaires avec la chaîne de cookies. Reportez-vous à Paramètres HTTP pour les captures pour la liste exacte des champs : en-têtes personnalisés, corps POST, invalidation de cache, etc.

Check-list sécurité

Risque	Atténuation
Fuite dans les journaux	Filtrer les cookies des logs ; jetons à courte durée
Confusion inter-domaines	Vérifier que l’hôte de l’URL correspond aux règles de cookie
Sessions trop puissantes	Rôles lecture seule ou « monitoring » pour l’automatisation
Sessions périmées	Rafraîchir après 401/403 avant de relancer le job

Exemple cURL

curl -G "https://api.screenshotcenter.com/api/screenshot/create" \
  --data-urlencode "url=https://app.example.com/reports/trimestriel" \
  --data-urlencode "key=VOTRE_CLE_API" \
  --data-urlencode "cookies=auth_session=FE26.2**..."

Exemple JavaScript

import { createScreenshot } from "./lib/screenshotcenter.js";

await createScreenshot({
  url: "https://app.example.com/reports/trimestriel",
  cookies: ["auth_session=FE26.2**...", "csrf=jeton-valide"].join("; "),
  delay: 800,
});

Ajustez delay lorsque l’application hydrate depuis une API après le shell HTML initial.

Lorsque les cookies ne suffisent pas

Si le site lie les sessions à des plages d’IP, à l’empreinte matérielle ou à des canaux WebSocket, les cookies seuls peuvent encore afficher un écran de connexion. Combinez alors avec des étapes d’automatisation ou un routage géographique aligné sur vos utilisateurs.

En résumé

Les cookies de session sont la voie la plus directe pour capturer des pages authentifiées à l’échelle, à condition de les traiter comme des secrets, d’aligner les domaines et de les renouveler avant expiration. Gardez Paramètres HTTP pour les captures sous la main à côté de vos tests d’intégration.