Chargez une capture HAR, lancez les règles par nom de champ et relisez la sortie avant de la partager : en-têtes, cookies, chaînes de requête, formulaires et corps JSON sont couverts, les corps de réponse si la case est cochée, et ce qui n’a pas de nom reconnaissable reste tel que capturé.
Fonctionne localement dans votre navigateurCollez une capture HAR ou déposez le fichier .har : la page lit log.entries, remplace par [REDACTED] les valeurs qui correspondent à ses règles et réécrit la capture en JSON indenté dans cet onglet. Une capture de test à trois entrées a signalé 22 valeurs remplacées sans toucher aux corps de réponse et 24 en les incluant ; une capture compacte de 3.9 Ko est revenue à 6.4 Ko parce que la sortie est formatée.
Les règles travaillent par nom de champ — Authorization, X-Api-Key, Cookie, Set-Cookie, api_key, access_token, refresh_token, id_token, token, password, secret, session, jwt, csrf, signature et leurs variantes — dans les en-têtes et cookies de requête, les chaînes de requête, les paramètres d’URL, les champs de formulaire, les corps JSON, les en-têtes et cookies de réponse, les URL de redirection et les champs propres au HAR. Les valeurs sont aussi reconnues à leur forme : les identifiants Bearer et Basic et un JWT commençant par eyJ sont remplacés où qu’ils apparaissent.
Un en-tête, un cookie ou un champ de formulaire est réécrit quand son nom correspond à la liste, quelle que soit la valeur. Un paramètre de requête est réécrit quand son nom correspond, y compris un token= isolé et le code= OAuth d’une redirection ; le reste de l’URL conserve son ordre, ses autres paramètres et son #fragment, et le remplacement s’écrit littéralement [REDACTED], sans encodage. Un en-tête Location contenant une URL suit les mêmes règles de requête.
Les corps JSON sont parcourus clé par clé, donc les objets et tableaux imbriqués sont couverts : dans la capture de test, password, un api_key imbriqué, un token isolé et un secret dans un tableau sont revenus en [REDACTED], tandis que des valeurs sans rapport comme une adresse e-mail et une note restaient lisibles. Les champs propres au HAR commençant par un souligné suivent les mêmes règles de nom, donc un jeton stocké à côté de la capture est masqué lui aussi.
Le contenu de réponse n’est touché que si la case est cochée. Cochée, un corps base64 est d’abord décodé, masqué, puis réencodé en base64 avec son champ encoding intact : un access_token dans un corps JSON en base64 est devenu [REDACTED] et le corps restait décodable en JSON valide. Un corps sans correspondance revient octet par octet comme capturé, avec ses retours à la ligne base64 d’origine.
Tout le reste voyage sans changement : nombre d’entrées, titres et temps de page, statuts HTTP, tailles d’en-tête et de corps, adresses IP du serveur et heures de début. Repasser la sortie dans l’outil signale 0 occultation : une capture déjà assainie peut donc être revérifiée sans autre modification.
Les règles visent des noms de champ et des formes d’identifiant, pas des valeurs qui semblent suspectes. Un secret sans nom — dans le chemin d’une URL, dans un champ de commentaire HAR ou comme valeur d’un champ ordinaire comme note — reste tel quel, tout comme un corps de réponse tant que sa case est décochée. La ligne de constats indique le nombre de valeurs remplacées ; elle n’affirme jamais que le fichier est anonyme, d’où l’intérêt d’un second regard avant de le joindre à un ticket.
Une entrée vide, un JSON mal formé et un JSON sans tableau log.entries se terminent chacun par leur propre phrase et sans téléchargement : un document tronqué est signalé avec la ligne et la colonne où l’analyse s’est arrêtée, et un JSON qui n’est pas une capture HAR est nommé comme tel au lieu de produire un fichier vide. Tout le traitement reste dans le navigateur : la page n’envoie la capture dans aucune requête.