App Check SDK をアプリに追加した後、App Check の適用を有効にする前に、既存の正規ユーザーを中断しないように対策を行う必要があります。
Realtime Database、Cloud Firestore、Cloud Storage、Authentication（ベータ版） のどれを使用するのかを決める際に、App Check リクエストの指標画面は重要なツールとなります。
プロダクトの App Check リクエストの指標を表示するには、Firebase コンソールで [App Check] セクションを開きます。次に例を示します。
各プロダクトのリクエスト指標は 4 つのカテゴリに分類されます。
確認済みリクエストは、有効な App Check トークンを含むリクエストです。App Check の適用を有効にすると、このカテゴリのリクエストのみが成功します。
古いクライアント リクエストは、App Check トークンのないリクエストです。これらのリクエストは、アプリに App Check が追加される前の古いバージョンの Firebase SDK から送信されたリクエストである可能性があります。
送信元が不明なリクエストは、App Check トークンのないリクエストで、Firebase SDK から送信されていない可能性があります。これには、盗まれた API キーで行われたリクエストや、Firebase SDK を使用せずに行われた偽造リクエストなどが該当します。
無効なリクエストは無効な App Check トークンを含むリクエストです。アプリになりすますために権限のないクライアントから送信された可能性があります。また、エミュレートされた環境から送信された可能性もあります。
アプリがこのカテゴリのどれに分類されるのかにより、適用を有効にするかどうかを判断する必要があります。ガイドラインをいくつか紹介します。
最近のリクエストのほとんどが検証済みのクライアントからのものである場合は、適用を有効にして、バックエンド リソースの保護を開始します。
最近のリクエストの大部分が古いクライアントからのものである場合は、ユーザーの混乱を避けるため、アプリを更新するユーザーが増えるまで適用を有効にしません。リリースされたアプリに App Check を適用すると、App Check SDK と統合されていない以前のバージョンのアプリが破損します。
アプリをまだリリースしていない場合は、古いクライアントが存在しないため、App Check の適用をすぐに有効にします。
次のステップ
App Check がユーザーに与える影響を理解し、続行する準備ができたら、Realtime Database、Cloud Firestore、Cloud Storage、Authentication で App Check の適用を有効にします。