WebViewは、アプリの中に埋め込まれたブラウザです。見た目はWebページですが、それを表示しているのはアプリ本体。だから通常のブラウザと違い、アプリ側が表示中のURLや受け渡される値を覗ける・介入できる。ここで「呼び出し元URLの先頭だけを確認する」ような甘い検証を挟むと、トークンを横取りされます。
先に押さえる
普通のブラウザは、サイトごとに厳密な壁（同一オリジン）があります。ところがWebViewはアプリが内側に持つ画面なので、アプリと表示中Webの境界が曖昧。アプリはWebViewの今のURLを読めるし、値の受け渡しにも割り込めます。「誰の画面で、誰が値を扱っているか」を意識するのが起点です。
トークンが渡る流れと、検証の穴
1WebView内でログイン → トークンがURLで戻る
アプリ内のWebView
↓戻り先URLにトークンが載って返る
アプリ本体URLを読み取れる
2「先頭一致だけ」の検証は途中で破れる
正規URLの先頭：https://正規ドメイン/…
↓先頭が一致すればOK、という判定
細工URL先頭は正規に見せ、実際の宛先を攻撃者側へトークンを奪う
URLの先頭が正規ドメインかだけを見る検証は、その後ろに別の宛先を紛れ込ませる細工で通ってしまいます。結果、正規のふりをした画面にトークンが渡り、横取りされます。
動きで見る
アプリ内ブラウザで認証し、戻ってきたトークンをネイティブアプリへ受け渡す流れを追うと、ホスト側アプリがブラウザ内を覗ける＝穴と、それを受け取り側の検証で塞ぐ要点が見えます。（図は横スクロールできます）
見抜きどころ
甘い検証は「先頭一致」。正しくは宛先ドメインを厳密に確定する――たとえば末尾まで含めて区切り（/）で閉じて比較し、「正規ドメインの直後が区切りである」ことまで確かめます。「どこまでを一致とみなすか」を曖昧にしないのが急所です。
つまずきやすい
「HTTPSだから安全」ではありません。TLSは途中で読まれないことを守るだけで、トークンを渡す相手が正しいかは別問題。WebViewではアプリが相手を取り違えないURL検証が守りの中心になります。
攻撃と対策をひと目で
攻撃・リスク
- ホスト側アプリがアプリ内ブラウザの中を覗けるため、コード／トークンを窃取・すり替えできる
- リダイレクト先の取り違え（先頭一致など甘い突き合わせ）で、別アプリ・別ドメインへトークンが渡る
- 「HTTPSだから安全」の思い込み（＝経路の秘匿と渡す相手の正当性は別物）
効く対策
- 宛先ドメインを区切りまで含めて厳密に確定（先頭一致にしない）
- 受け取ったトークンの発行先・用途・宛先・署名を検証してから使う
- 機微なトークンをアプリ内ブラウザに晒さない受け渡し設計（外部ブラウザ／システム連携の利用）