モバイルアプリでAPIキーてどうするのが正しいんすか
はじめに
GoogleなどのWeb APIを呼び出す際にはAPIキーを使うことが多いと思います。
APIキーは課金とかと紐付いていたりするので、漏れると大変です。
Webサービスのサーバサイドから呼び出す場合は、比較的対策しやすいですよね。
- そもそもクライアントサイドからAPIキーが見えない
- Web API側に、特定のアドレスからのアクセスしか受け付けないなどの制限をかけられる
- 仮に漏洩しても、(漏洩対策した上で)APIキーの再発行などして差し替えができる
モバイルアプリで直接Web APIを呼び出す場合、APIキーをモバイルアプリ自体が使って呼び出す必要があります。
これって、普通どうするのが正しい、というかベストというか、そういうもんなんでしょうか。
問題点
モバイルアプリ自体がAPIキーを使ってWeb APIを呼び出す際の問題点には以下のようなものがあります。
- アプリを解析された場合、APIキーが漏洩してしまう
- 呼び出し元(モバイルアプリ)のアドレスが一定ではないので、アクセス制限がかけられない
- Bundle Identifierなどでも制限できるが、偽装も可能なので万全ではない
- 漏洩した場合、漏洩対策・APIキー差し替え版をリリースするにしても、パブリッシャの審査〜配布開始〜ユーザへの浸透まで時間がかかる
検討した内容
以下を検討しました。
- APIキーをどこかのWebサービスから取得する
- APIキーの難読化・暗号化
内容を説明します。
APIキーをどこかのWebサービスから取得する
モバイルアプリにAPIキーを埋め込むことで問題点4の話が出てきてしまっているのだから、APIキーはサーバに置いておいて、漏洩したら即座に差し替えしよう、ということです。
ただしよくよく考えると、そうしたところで漏れるルートがモバイルアプリ側に見つかってしまっているのだから、差し替えたところで再度漏れる可能性が非常に高いと言えます。
漏洩対策版のリリースは必須です。
ちょっとした時間稼ぎにはなるのかも知れませんが。
また、このWebサービスの利用の際の認証はどうするのかという問題があります。
このWebサービスのAPIキーを発行しましょうか?ってなって堂々巡りです。
ChatGPTに聞いたら「OAuth2で」とか言っていましたが、ユーザを認証する意味はあまりないでしょう。捨てアカでこられたらどうしようもありません。
APIキーの難読化・暗号化
モバイルアプリ側にAPIキーの難読化・暗号化処理を入れると問題点1を軽減できます。完全に解消、まではできません。
このWebサービスのAPIキーを発行しましょうか?ってなって堂々巡りです。
堂々巡りとは言え、本当のAPIキーはWebサービスから取得することにして、APIキー取得用Webサービス用APIキーを難読化・暗号化して保持したほうがよさそうな気はしています。
本当のAPIキー漏洩時に無効化・差し替えして対策への時間稼ぎができるからです。
ただそうしたところで、これで漏洩したときの対策は「より高度な難読化・暗号化を使う」ぐらいしかない気がしており、それができるんだったら最初からそうするんじゃないのかという疑問が残ります。
というわけで
みなさんどうしてるんですかね、という疑問でした。
問題点2と3は「モバイルアプリからは直接呼ばない」しか解消・軽減方法がなく、結局それが正解かも、というのはうすうす感じています。
Discussion