ByteScope

HAR File Sanitizer

DevTools から書き出した .har を開いて、入っている Cookie、Authorization、トークン、JWT、秘密鍵をすべて確認し、値を置き換えたコピーを保存する。サポートに渡す前、issue に貼る前に。

ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。

HAR ファイルには、ログイン中の Cookie やトークンがそのまま記録されています。手に入れた人は、あなたとしてログインできてしまいます。送る前に、ここで消しておきましょう。

.har ファイルをここにドロップ

ブラウザの DevTools から書き出した .har または .json。クリックして選ぶこともできます。このタブの中で読むだけで、アップロードはしません。

HAR の JSON を貼り付ける

いろいろな種類のファイルをまとめて調べたいなら メタデータ一括確認へ

このツールについて

サポートから「HAR を書き出して送ってください」と言われて書き出すファイルは、その間にブラウザが行った通信の完全な記録です。URL、ヘッダー、Cookie、リクエストとレスポンスの本文が全部入っています。ログイン状態を保っているセッション Cookie も、アプリが毎回付けている Authorization ヘッダーも、ログインのレスポンスで返ってきたトークンも。そのファイルを手にした人は、値が失効するまであなたとして振る舞えることが少なくありません。公に報じられているところでは、2023 年の Okta サポートシステムの事件では、顧客がサポート案件に添付した HAR ファイルからセッショントークンが取り出されました。ファイルは本来の仕事をしただけです。このページは最大 200 MiB の .har をブラウザの中で開き、見つかったものを並べ、それらの値を置き換えたコピーを作ります。送信はしません。ページの裏にサーバーはありません。

見つけるもの

リクエスト側の Cookie（Cookie ヘッダーと cookies 配列）とレスポンス側の Set-Cookie。HttpOnly や Secure が付いたものはセッション Cookie の可能性が高いと印を付けます。Authorization と Proxy-Authorization：Bearer、Basic（ハッシュではなく、そのまま戻せるユーザー名とパスワードです）、Digest。URL に埋め込まれた user:pass@。x-api-key、x-csrf-token、x-amz-security-token、x-goog-api-key などの既知のトークンヘッダー。リクエスト URL、リダイレクト、Location と Referer ヘッダーに含まれる秘密らしいパラメータ。token、access_token、id_token、code、state、signature、X-Amz-Signature、password の類で、フラグメントの #access_token も含みます。フォームと JSON の本文に入ったパスワードとトークン。access_token と refresh_token を返す OAuth のトークンレスポンスも対象です。ファイル中のどこにあっても JWT は alg、iss、sub、有効期限つきで表示します。署名は検証しません。秘密鍵（-----BEGIN … PRIVATE KEY-----）。レスポンス本文に含まれる個人情報らしいもの：メールアドレス、E.164 形式の電話番号、Luhn チェックを通るカード番号、チェックディジットが合う台湾の身分証番号。そして内部ホスト：localhost、127/8、10/8、172.16/12、192.168/16、file:// の URL。これらは社内ネットワークの形を外の人に教えてしまいます。

置き換えたコピーで変わるもの

チェックを付けたままの項目は、値が [REDACTED] に置き換わります。名前は残るので、ここに Cookie ヘッダーや access_token フィールドがあったことはサポート側にも分かります。内部ホスト名は redacted.invalid に、書き換えたリクエストやレスポンスのヘッダーと本文のサイズは -1（不明）になります。元の数字は書き換え後の中身と合わなくなるからです。コピーは保存前にもう一度スキャンされ、置き換え前 N 件・後 M 件がページに出ます。このページが見つけられるものがまだ残っていれば、必ず目に入ります。個人情報は一覧に出ますが、最初はチェックが外れています。レスポンス本文のメールアドレスを消すと、ベンダーに見てほしいバグそのものが隠れてしまうことがあるからです。その判断は一件ずつあなたに任せます。ファイルに Cookie も Authorization ヘッダーも一つもないときは、ページがそう伝えます。Chrome DevTools は機密データを含めずに HAR を書き出すこともでき、そのように書き出されたファイルに見えます。

できないこと

見つけられるのは既知の形だけです。アプリが x という名前の本文フィールドにトークンを入れていたり、ここが知らない形式だったりすれば、見逃すことがあります。だからレポートは「このファイルは安全です」とは言いません。何を消したか、何をあなたが残したかを言うだけです。個人情報の検出は「かもしれない」止まりで、漏れもあります。共有する前に自分でファイルを読むことの代わりにはなりません。置き換えたリクエストは再送できません。それが目的です。base64 で格納されたバイナリのレスポンス（画像、フォント、ダウンロード）はスキャンしません。逆向きにも使えます。人から送られてきた HAR を開いて、相手が何を渡してきたのかを転送する前に確かめてください。

よくある質問

HAR ファイルをそのまま共有しても大丈夫ですか？

書き出したままでは危険です。HAR はすべてのリクエストのヘッダーと Cookie を記録するので、ログイン中に書き出したファイルには、そのセッションが頼っている Cookie やトークンが入っています。ファイルを持った人は、失効するまでそれを使い回せることが少なくありません。まずここで開いてください。識別できる Cookie、Authorization ヘッダー、トークン、JWT、秘密鍵、内部ホストがすべて並び、それらの値を置き換えたコピーを保存できます。コピーが「安全」だと宣言することはありません。レポートが言うのは何を消し、何を残すことにしたか。最後に目を通すのはあなたです。

HAR ファイルはどこかへ送信されますか？

されません。File API で開き、このタブの中で解析し、置き換えたコピーはブラウザがメモリから作るダウンロードです。ページの裏に API はないので、ファイルの行き先がそもそも存在しません。サーバーに置きたくないファイルの筆頭、つまり生きているセッションが入ったファイルにこそ、これが効きます。

HAR ファイルには具体的にどんな機密情報が入っていますか？

記録したページでブラウザが送受信したものすべてです。各リクエストの Cookie ヘッダー、各レスポンスの Set-Cookie、Authorization と Proxy-Authorization、x-api-key のような独自のトークンヘッダー、URL やリダイレクトの Location ヘッダーに入ったトークン（OAuth は code、state、ときには #access_token をそうやって渡します）、ログインフォームのパスワード、JSON のトークンレスポンス、そしてときどきレスポンス本文の秘密鍵や個人情報。リクエスト URL からは社内にどんなホストがあるかも分かります。localhost、10.x、192.168.x、file:// のパス。他人に渡すべきでない地図です。

Cookie だけ消して、ほかはそのまま残せますか？

できます。見つかった項目は一つずつチェックボックスです。個人情報らしいもの以外は最初からチェックが入っています。残したいもの、たとえばサポートが再現に使う公開 API キーはチェックを外してください。値は [REDACTED] に置き換わり、名前は残るので、各リクエストの構造はそのまま読めます。コピーは保存前にもう一度スキャンされ、前後の件数が並んで表示されます。

メールアドレスや電話番号が最初から消される対象になっていないのはなぜ？

サポート案件はたいていそのデータの話だからです。プロフィール画面に間違ったメールアドレスが出るというバグなら、メールアドレスを [REDACTED] に置き換えた HAR は、エンジニアが見たい一点を隠してしまいます。だからレスポンス本文の個人情報、つまりメールアドレス、E.164 の電話番号、Luhn を通るカード番号、チェックディジットの合う台湾の身分証番号は「個人情報かもしれない」として並べ、チェックするかどうかはあなたに任せます。検出は意図的に不完全です。名前や住所を見ても、それと分かりません。

JWT が見つかりました。alg、iss、有効期限とは何で、そのトークンはまだ使えますか？

JWT は base64 の三つの部分、ヘッダー、クレーム、署名でできています。このページは前の二つをデコードし、アルゴリズム（alg）、発行者（iss）、主体（sub）、有効期限を表示します。ファイルの中のトークンが生きているのか、何週間も前に失効しているのかが分かります。署名は検証しません。検証に使う鍵がないからです。だからサーバーが受け付けるかどうかは言えません。有効期限が未来にある JWT は、ファイルを持つ人なら使えるものとして扱ってください。

置き換えた HAR をサポートはまだ使えますか？

読む用途なら使えます。URL、リクエストの順番、ステータスコード、タイミング、すべてのヘッダーとフィールドの名前、機密でない本文は変わりません。リクエストの再送はできません。資格情報が消えているからで、置き換えたファイルを渡す目的はそこにあります。エンジニアがある呼び出しを再現する必要があるなら、あなたのではなく自分の資格情報で行うべきです。

何も見つかりませんでした。このファイルには問題がないということ？

このページが知っている形のものが入っていなかった、というだけです。HAR に Cookie も Authorization ヘッダーも一つもないときは、機密データを除いて書き出されたファイルに見えるとページが伝えます。Chrome DevTools にはその書き出し方があります。珍しいヘッダーに入ったトークン、予想外の名前のフィールドに入ったパスワード、バイナリのレスポンスに隠れた秘密は見えません。大事なファイルなら、共有する前に本文を自分で読んでください。

関連ツール