# HAR File Sanitizer > HAR ファイルにはログイン中の Cookie、トークン、パスワードが入っています。中身をブラウザで確かめ、値を [REDACTED] に置き換えたコピーを保存。送信しません。 - URL: https://bytescope.dev/ja/har-sanitizer/ - Locale: ja · Also: [en](https://bytescope.dev/en/har-sanitizer.md) · [zh-Hant](https://bytescope.dev/zh-Hant/har-sanitizer.md) - Runs: ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。 - Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile. - Updated: 2026-09-08 ## What it does サポートから「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 を開いて、相手が何を渡してきたのかを転送する前に確かめてください。 ## Limits Does not verify JWT signatures, replay requests or draw a timing waterfall, and does not scan base64 binary responses (images, fonts). It finds known shapes only — a custom token format can be missed — and it never says a HAR is safe: it lists what was replaced and what you kept. ## FAQ ### 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 にはその書き出し方があります。珍しいヘッダーに入ったトークン、予想外の名前のフィールドに入ったパスワード、バイナリのレスポンスに隠れた秘密は見えません。大事なファイルなら、共有する前に本文を自分で読んでください。 ## Related tools - [Invisible Character Checker](https://bytescope.dev/ja/invisible-characters.md) — これから貼り付けたり送ったりするテキストに隠れた、ゼロ幅・bidi・タグ文字を見つけます。 - [Office Document Inspector](https://bytescope.dev/ja/office-inspector.md) — Word・Excel・PowerPoint 版です。作成者、変更履歴、ファイルパスなどを確認できます。 - [Redact Screenshot](https://bytescope.dev/ja/redact-screenshot.md) — スクリーンショットに写ったトークンや名前を、共有する前に塗りつぶします。 - [HTTP Status Code Reference](https://bytescope.dev/ja/http-status.md) — HAR に出てくるステータスコードの意味を調べられます。