ディープリンクのセキュリティ

結論：自社アプリと自社Webを結ぶなら、可能な場合はUniversal Links / Android App Linksを優先します。custom schemeを使う場合は、同一scheme登録・不正パラメータ・機密情報流出を前提に防御します。

custom URL schemeは一意に所有できない

Appleは、複数アプリが同じcustom URL schemeを登録でき、その場合どのアプリが対象になるかは保証されないと説明しています。reverse DNS形式のscheme名は衝突を減らすベストプラクティスですが、他アプリによる同じscheme登録を技術的に禁止するものではありません。

Universal LinksはWebサーバー上のAASAとアプリ側設定を使い、WebサイトがそのアプリにURL処理を許可していることを検証します。Android App Linksも assetlinks.json と署名情報で関連付けを確認します。

この所有確認が、custom schemeに対する大きなセキュリティ上の違いです。

LINEヤフーは、特定条件下で意図しない別アプリが line:// を扱う乗っ取り攻撃を防ぐため、このschemeを非推奨にしています。現在はHTTPSベースのLINE URL schemeを案内しています。

第三者サービスの古いscheme例をWeb上からコピーして使い続けるのではなく、現行一次情報を確認する必要があります。

アプリがdeep linkから受け取るパスやquery parameterは外部入力です。Appleもcustom URL schemeについて、不正URLを捨て、ユーザーデータを危険にさらす操作を制限するよう警告しています。

避けたい例：URLに認証token・個人情報・秘密値をそのまま含める、リンクを受け取っただけで重要操作を無確認実行する、外部入力をそのままWebView/SQL/コマンドへ渡す、といった設計。

短縮URLや中間redirectは運用に便利ですが、遷移先の検証やパラメータ維持、open redirect化していないかの確認が必要です。またGoogle Adsの一部用途ではredirect型deep link自体が非対応です。

本製品のように第三者サービスのscheme/Intent候補を生成する場合、対象サービス側のscheme仕様変更もリスクになります。生成できることと安全・公式・永続対応は同じではありません。