ディープリンクはブラウザ、メッセージ、他のアプリから画面遷移を呼び出せる。注文詳細には便利だが、未知のパス、期限切れ ID、二重遷移、URL に含めてはならない認証情報も入口に届く。
解析してから遷移する
登録済みの scheme と host のみ受け入れ、許可したパスを照合し、引数の長さと形式を検証する。外部 URL をそのまま画面遷移命令に変えない。URL の token はログインの証明ではない。注文 ID を受け取っても現在のセッションで再取得し、サーバーに権限を確認させる。
コールドスタートと前景で同じリンクが二度届くことがある。重複を除き、セッション初期化後に遷移先を一度だけ消費する。ログアウト時は保留中の遷移も消す。
外部アプリから検証する
未ログイン、ログイン途中、ログイン済み、アカウント切り替えを試す。削除済みの注文、不正なエンコード、連続タップも確認する。アプリ内部の画面遷移だけでは OS のリンク設定を検証できない。
招待リンクの信頼境界
https://example.com/invite?code=... を押すと OS がアプリへ渡す場合がある。しかし OS のコールバック経由というだけで URL は信用できない。許可したホストとパスだけを解析し、パラメータの長さと符号化を制限する。現在ログイン中の利用者について、招待の存在、有効期限、受諾権限をサーバーで確認する。role=admin、価格、対象アカウントを URL から直接権限付き状態へ昇格させない。ログインが必要なら最小限の遷移先だけを保存し、ログイン後に再取得・再認可する。
副作用のあるリンクでは「詳細を開く」と「操作を実行する」を分ける。招待画面にはサーバーから返された組織と権限を表示できるが、受諾には利用者の明示的な操作が必要だ。決済、送金、削除を URL の解析時に実行してはいけない。外部の遷移先は固定の許可リストを使い、任意の redirect パラメータへ飛ばさない。ログにも完全なトークンや招待コードを残さない。
OS コールバック → URL 正規化 → ホスト/パス/引数の許可リスト → セッション
→ サーバー照会と認可 → 確認画面 → 利用者による送信
設定と異常入力を検証する
iOS の Universal Links にはドメイン関連ファイルとアプリの entitlement の一致が必要で、Android App Links には検証可能なドメイン関連付けが必要だ。コールドスタート、起動中、ログイン済み、未ログインを分けて試す。重複引数、長すぎる符号化、大小文字、取り消された招待、別アカウント向けリンク、悪意ある外部遷移も入力する。権限のない対象は内容を見せず、サーバーへの書き込みも起こさない。参考：Apple Associated Domains、Android App Links。