Nettoyeur de Fichiers HAR

Vue d’ensemble

Un fichier HAR est l’enregistrement que le navigateur fait lui-même d’un chargement de page, exporté depuis les DevTools. C’est la pièce jointe la plus utile que vous puissiez ajouter à un rapport de bug du genre « chez moi ça marche », et c’est aussi l’une des choses les plus dangereuses à coller dans un gestionnaire de tickets public. La capture d’une session authentifiée contient votre cookie de session, votre en-tête Authorization, le code OAuth qui se trouvait éventuellement en transit, chaque formulaire que vous avez soumis et chaque corps de réponse renvoyé par le serveur.

Cet outil réécrit la capture de sorte que la structure survive mais pas les secrets. Vous conservez la liste des requêtes, les méthodes, les codes d’état, les noms d’en-têtes, les mesures de temps et les tailles — tout ce dont un mainteneur a besoin pour raisonner sur votre problème — tandis que les valeurs qui compromettraient votre compte sont remplacées par [REDACTED].

Utilisation

1. Dans les DevTools, ouvrez Network, faites un clic droit sur la liste des requêtes et choisissez Save all as HAR.
2. Collez le JSON ici (ou ouvrez le fichier et collez son contenu).
3. Lisez le décompte des champs expurgés, puis parcourez la sortie.
4. Cliquez sur Download pour enregistrer sanitized.har, et joignez ce fichier au lieu de l’original.

Ce qui est supprimé

La capture range le même secret à plusieurs endroits, l’outil doit donc les effacer tous. En oublier un est l’échec qui compte vraiment : un fichier qui paraît assaini est pire qu’un fichier manifestement brut, parce que vous le joindrez sans y réfléchir à deux fois.

• Les en-têtes. Cookie, Set-Cookie, Authorization, et tout en-tête dont le nom contient token, secret, credential, session ou api-key. Également Location, car une redirection consécutive à un rappel OAuth transporte le code d’autorisation dans l’URL.
• Les tableaux de cookies analysés. Le format HAR enregistre les cookies deux fois — une fois comme ligne d’en-tête brute, une fois comme tableau cookies[] de paires nom/valeur. Toutes les valeurs de ces tableaux sont effacées quel que soit leur nom, parce que le nom d’un cookie ne dit pas à quoi il sert (s, _sess et SID sont tous des cookies de session dans la nature).
• Les corps de requête. postData.text et le tableau analysé postData.params[] sont effacés sans examiner les noms de champs. Le champ d’un formulaire de connexion peut s’appeler pass, otp ou cvv, et aucun de ces noms ne figurerait dans une liste de mots-clés que vous auriez pensé à écrire.
• Les corps de réponse. Effacés intégralement. C’est de loin la première source de divulgation accidentelle — une réponse JSON de /api/me contient la fiche utilisateur complète.
• Les cibles de redirection et les trames WebSocket. response.redirectURL et le champ _webSocketMessages propre à Chrome, dont la première trame est très souvent la poignée de main d’authentification.
• L’adresse IP du serveur et l’initiateur. serverIPAddress révèle l’adressage interne ; le champ _initiator de Chrome conserve l’URL complète du script à l’origine de la requête, chaîne de requête incluse.
• Les paramètres de requête. Tout paramètre dont le nom ressemble à un identifiant — token, api_key, AWSAccessKeyId, signature, code, state, sid, et tout ce qui contient key, secret ou password. Les paramètres non sensibles comme page et lang sont laissés tranquilles pour que les URL restent lisibles.
• Les titres de page et les référents. Un titre de page n’est souvent que l’URL, et un en-tête Referer émis après un rappel OAuth transporte le code d’autorisation.

Ce qui est délibérément conservé

Deux catégories sont épargnées alors qu’un filtre par mots-clés grossier les attraperait, parce que les retirer détruirait la raison pour laquelle vous partagez le fichier :

• Les en-têtes de réponse CORS. Access-Control-Allow-Origin et ses voisins ne contiennent aucun secret, et un bug CORS est l’un des motifs les plus fréquents de partager un HAR. Expurger la réponse à la question rend la capture inutile.
• Les défis d’authentification. WWW-Authenticate et Proxy-Authenticate décrivent le schéma que le serveur réclame. C’est une indication, pas un identifiant.

Ce que l’outil ne peut pas supprimer

L’expurgation fondée sur les noms a une limite dure, et il vaut mieux savoir où elle se situe avant de joindre la sortie à un ticket public.

• Les secrets dans un chemin d’URL. /reset/9f3c… et /invite/abc123 sont indiscernables de /users/42 sans connaître le routage. Les segments de chemin sont laissés intacts, car les retirer détruirait la liste des requêtes.
• Les jetons dans des en-têtes personnalisés au nom anodin. Un en-tête nommé X-Client-Id qui transporte par hasard une valeur signée ne correspondra à aucun mot-clé. Parcourez vos propres noms d’en-têtes avant de partager.
• Les données personnelles dans des paramètres non sensibles. Une adresse e-mail dans ?email= survit, parce que email est un nom de champ et non un identifiant. Que cela pose problème ou non dépend de la personne à qui vous envoyez le fichier.
• Les URL elles-mêmes. Les noms d’hôtes internes, les domaines de préproduction et les chemins d’API sont tous préservés, et réunis ils décrivent votre architecture.

La règle pratique : cet outil rend une capture joignable à un ticket fournisseur ou à une issue sur votre propre gestionnaire. Traitez « publiable sur l’internet ouvert » comme un jugement distinct, que vous portez en lisant le fichier.

Remarques

Les valeurs sont remplacées et non supprimées, si bien que la forme du JSON reste inchangée et que n’importe quel lecteur de HAR ouvrira encore le résultat. La seule exception est content.encoding : quand un corps de réponse est remplacé, la déclaration base64 qui décrivait les octets d’origine est retirée, parce que [REDACTED] n’est pas du base64 et qu’un lecteur strict échouerait dessus.

Le compteur rapporte des champs effacés ou retirés, pas des secrets trouvés. La capture d’un site statique sans aucun cookie peut légitimement afficher un nombre élevé, puisque chaque corps de réponse compte.

Une entrée qui n’est pas un HAR est rejetée plutôt que laissée passer. Une version antérieure de cet outil acceptait n’importe quel JSON, traitait zéro entrée et annonçait « 0 sensitive values redacted » comme un succès — vous rendant le fichier d’origine avec un certificat de bonne santé. Vous dire qu’une chose est sûre est ici le produit tout entier, donc l’outil refuse désormais tout ce qui n’a pas de tableau log.entries.

Si vous voulez seulement lire une capture plutôt que la partager, utilisez plutôt le visualiseur HAR. Il masque les secrets à l’écran mais ne réécrit jamais le fichier, puisque dans les deux cas rien ne quitte votre machine.