HTTP Toolkitを使用したHTTPSリクエストの検査

APIコールが静かに失敗したり、認証が説明なく壊れたりする場合、ブラウザのDevToolsでは不十分なことがよくあります。アプリケーションから送信される実際の暗号化されたトラフィックを確認する必要があります。HTTP Toolkitは、まさにこの機能を提供します—HTTPSトラフィックを傍受し、実際にネットワーク上で何が起きているかを検査する直接的な方法です。

この記事では、HTTP Toolkitがローカルプロキシとしてどのように動作するか、プロトコルサポートについて知っておくべきこと、そしてフロントエンド開発者がHTTPSリクエストのデバッグに使用する実践的なワークフローについて説明します。

HTTP ToolkitがMITMプロキシとして動作する仕組み

HTTP Toolkitは、中間者(MITM)プロキシとして動作します。クライアント(ブラウザ、モバイルアプリ、またはデスクトップアプリケーション)とサーバーの間に位置し、通過するすべてのトラフィックを傍受します。

HTTPトラフィックの場合、これは単純明快です。HTTPS検査には追加のステップが必要です:HTTP Toolkitが生成したルート証明機関(CA)を信頼することです。この証明書を信頼すると、ツールはTLSトラフィックを復号化し、読みやすい形式で表示した後、宛先サーバーに転送する前に再暗号化できます。

証明書の信頼は、HTTP Toolkitを通じて起動されたブラウザでは自動的に行われます。他のアプリケーションの場合は、プロキシ設定を構成し、証明書を手動でインストールする必要があります。

プロトコルサポートと制限事項

HTTP Toolkitは、HTTP/1.1とHTTP/2の傍受を完全にサポートしています。これらのプロトコルは、フロントエンドデバッグシナリオの大部分をカバーしています。

HTTP/3(QUIC)は異なる状況です。クライアントが通常HTTP/3を使用する場合、HTTP ToolkitはHTTP/2またはHTTP/1.1へのフォールバックを強制します。ネイティブなQUIC傍受はまだ利用できません。ほとんどのフロントエンドデバッグ作業では、この制限はほとんど問題になりません—リクエストとレスポンスのデータは、トランスポートプロトコルに関係なく同一のままです。

このツールはWebSocket接続も処理し、標準的なHTTPトラフィックと並行してリアルタイム通信を検査できます。

ブラウザとアプリの接続

ブラウザの傍受

最もシンプルなワークフローは、HTTP Toolkitのダッシュボードから始まります。ブラウザオプション(Chrome、Firefox、またはEdge)をクリックすると、HTTP Toolkitはプロキシ設定と証明書の信頼がすでに構成された事前設定済みのインスタンスを起動します。

そのブラウザウィンドウからのすべてのリクエストが、HTTP ToolkitのViewタブに表示されます。完全なリクエスト—メソッド、URL、ヘッダー、ボディ—と完全なレスポンスを確認できます。

モバイルアプリのトラフィック

モバイルデバッグにはより多くのセットアップが必要です。Androidデバイスの場合、いくつかのオプションがあります:

• ADB接続: USB経由でデバイスを接続し、HTTP Toolkitに設定させる
• 手動プロキシ: デバイスのWiFi設定を構成して、HTTP Toolkit経由でルーティングする
• Root化されたデバイス: より広範なカバレッジのために、システムレベルで証明書をインストールする

Androidのセキュリティモデルは、ここで摩擦を生み出します。Android 7以降をターゲットとするアプリは、明示的に構成されている場合にのみ、ユーザーがインストールした証明書を信頼します。多くのアプリはユーザーCA証明書を完全に無視するため、証明書の信頼を制限していないアプリからのトラフィックのみが表示されます。

証明書ピンニングはさらに別のレイヤーを追加します。特定の証明書をピンニングするアプリは、システムの信頼設定に関係なく、HTTP Toolkitの証明書を拒否します。いくつかの回避策(Fridaスクリプト、システムCAインストールを伴うRoot化されたデバイス)が存在しますが、これらはHTTP Toolkitのコア機能の範囲外です。

デスクトップアプリケーション

Electronアプリやその他のデスクトップソフトウェアの場合、アプリケーションをHTTP Toolkitをプロキシとして使用するように構成します。正確な方法はアプリケーションによって異なります—一部はシステムプロキシ設定を尊重し、他は環境変数やコマンドラインフラグを必要とします。

トラフィックの表示と変更

トラフィックがHTTP Toolkitを通過すると、Viewページに傍受されたすべての通信が表示されます。インターフェースは、リクエストリストと詳細ペインに分割されています。

詳細ペインは、各通信を折りたたみ可能なセクションに分解します:リクエストヘッダー、リクエストボディ、レスポンスヘッダー、レスポンスボディ、タイミング情報。ボディコンテンツは、コンテンツタイプに基づいて自動的にフォーマットされます—JSONはシンタックスハイライトを取得し、ミニファイされたJavaScriptは読みやすさのために展開されます。

フロントエンドデバッグにおいて、最も有用な機能には以下が含まれます:

• フィルタリング: 特定のホスト、メソッド、またはステータスコードに絞り込む
• 検索: URLパターンまたはコンテンツでリクエストを検索する
• エクスポート: fetch、axios、curl、その他の形式でコードスニペットを生成する

受動的な検査を超えて、HTTP Toolkitはブレークポイントとルールをサポートしています。リクエストがサーバーに到達する前に一時停止し、ヘッダーやボディを変更してから、変更されたリクエストを転送できます。これは、バックエンドコードを変更せずに、アプリケーションが異なるAPIレスポンスをどのように処理するかをテストするのに役立ちます。

実践的なフロントエンドデバッグワークフロー

HTTP ToolkitによるHTTPS検査は、いくつかのシナリオで特に効果を発揮します:

• 認証のデバッグ: トークンヘッダー、Cookie値、OAuthフローを検査する
• API統合の問題: アプリが送信する実際のペイロードとサーバーが期待するものを正確に確認する
• サードパーティスクリプトの分析: アナリティクスや広告スクリプトが送信するものを監視する
• CORSのトラブルシューティング: プリフライトリクエストとレスポンスヘッダーを調査する

このツールは、ブラウザのDevToolsが見逃す可能性のあるトラフィックをキャプチャします—Service Workerからのリクエスト、バックグラウンドフェッチ、または開いている開発者ツールを検出するスクリプトなど。

まとめ

HTTP Toolkitは、フロントエンド開発者にブラウザ、モバイルアプリ、デスクトップアプリケーション全体で信頼性の高いHTTPS検査を提供します。証明書の信頼要件により復号化が可能になり、HTTP/3のフォールバック動作により最新のインフラストラクチャとの互換性が保証されます。APIコール、認証フロー、ネットワーク動作のデバッグにおいて、ブラウザツールだけでは実現できない可視性を提供します。

よくある質問

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.