このページは Cloud Translation API によって翻訳されました。

WebアプリでreCAPTCHAEnterpriseを使用してアプリチェックを有効にする

このページでは、reCAPTCHA Enterpriseプロバイダーを使用して、Webアプリでアプリチェックを有効にする方法を示します。アプリチェックを有効にすると、アプリのみがプロジェクトのFirebaseリソースにアクセスできるようになります。この機能の概要を参照してください。

reCAPTCHA Enterpriseは、無料の割り当てを備えた有料サービスです。 App Checkは、無料のサービスであるreCAPTCHAv3もサポートしています。 reCAPTCHAv3とreCAPTCHAEnterpriseの違いについては、機能の比較をご覧ください。

AppCheckはreCAPTCHAEnterpriseスコアベースのサイトキーを使用するため、ユーザーには表示されないことに注意してください。 reCAPTCHA Enterpriseプロバイダーは、ユーザーがいつでも課題を解決することを要求しません。

独自のカスタムプロバイダーでAppCheckを使用する場合は、「カスタムAppCheckプロバイダーの実装」を参照してください。

1.Firebaseプロジェクトを設定します

まだ追加していない場合は、JavaScriptプロジェクトにFirebaseを追加します。
クラウドコンソールのreCAPTCHAEnterpriseセクションを開き、次の手順を実行します。
1. reCAPTCHA Enterprise APIを有効にするように求められた場合は、有効にします。
2. Webサイトタイプのキーを作成します。 Webアプリをホストするドメインを指定する必要があります。 [チェックボックスチャレンジを使用する]オプションは選択しないでください。
Firebaseコンソールの[アプリチェック]セクションで、reCAPTCHAEnterpriseプロバイダーにアプリチェックを使用するようにアプリを登録します。前の手順で取得したサイトキーを提供する必要があります。
Firebase製品の適用を有効にすると、登録されたアプリのみが製品のバックエンドリソースにアクセスできるようになるため、通常はプロジェクトのすべてのアプリを登録する必要があります。
オプション：アプリ登録設定で、プロバイダーによって発行されたアプリチェックトークンのカスタム存続時間（TTL）を設定します。 TTLは30分から7日の間の任意の値に設定できます。この値を変更するときは、次のトレードオフに注意してください。
- セキュリティ：TTLを短くすると、漏洩または傍受されたトークンが攻撃者によって悪用される可能性のあるウィンドウが減少するため、セキュリティが強化されます。
- パフォーマンス：TTLが短いということは、アプリがより頻繁にアテステーションを実行することを意味します。アプリの認証プロセスは、実行されるたびにネットワークリクエストにレイテンシを追加するため、TTLが短いとアプリのパフォーマンスに影響を与える可能性があります。
- 割り当てとコスト：TTLを短くし、再認証を頻繁に行うと、割り当てがより早く使い果たされます。有料サービスの場合、コストが高くなる可能性があります。割り当てと制限を参照してください。
ほとんどのアプリでは、デフォルトのTTLである1時間が妥当です。 App Checkライブラリは、TTL期間の約半分でトークンを更新することに注意してください。

2.アプリチェックライブラリをアプリに追加します

まだ追加していない場合は、Firebaseをウェブアプリに追加します。必ずAppCheckライブラリをインポートしてください。

3.アプリチェックを初期化します

Firebaseサービスにアクセスする前に、次の初期化コードをアプリケーションに追加してください。 activate()を実行するには、クラウドコンソールで作成したreCAPTCHAEnterpriseサイトキーを渡す必要があります。

Web version 9

const { initializeApp } = require("firebase/app");
const { initializeAppCheck, ReCaptchaEnterpriseProvider } = require("firebase/app-check");

const app = initializeApp({
  // Your Firebase configuration object.
});

// Create a ReCaptchaEnterpriseProvider instance using your reCAPTCHA Enterprise
// site key and pass it to initializeAppCheck().
const appCheck = initializeAppCheck(app, {
  provider: new ReCaptchaEnterpriseProvider(/* reCAPTCHA Enterprise site key */),
  isTokenAutoRefreshEnabled: true // Set to true to allow auto-refresh.
});

Web version 8

firebase.initializeApp({
  // Your Firebase configuration object.
});

// Create a ReCaptchaEnterpriseProvider instance using your reCAPTCHA Enterprise
// site key and pass it to activate().
const appCheck = firebase.appCheck();
appCheck.activate(
  new firebase.appCheck.ReCaptchaEnterpriseProvider(
    /* reCAPTCHA Enterprise site key */
  ),
  true // Set to true to allow auto-refresh.
);

App Checkライブラリがアプリにインストールされたら、それをデプロイします。

更新されたクライアントアプリは、Firebaseへのすべてのリクエストとともにアプリチェックトークンの送信を開始しますが、Firebase製品では、Firebaseコンソールの[アプリチェック]セクションで適用を有効にするまで、トークンが有効である必要はありません。詳細については、次の2つのセクションを参照してください。

4.リクエストの指標を監視する

更新されたアプリがユーザーの手に渡ったので、使用しているFirebase製品に対してアプリチェックを適用できるようになります。ただし、そうする前に、そうすることで既存の正当なユーザーを混乱させないことを確認する必要があります。

リアルタイムデータベース、Cloud Firestore、およびCloud Storage

Realtime Database、Cloud Firestore、およびCloud Storageでこの決定を行うために使用できる重要なツールは、アプリチェックリクエストの指標画面です。

商品のアプリチェックリクエストの指標を表示するには、Firebaseコンソールの[アプリチェック]セクションを開きます。例えば：

AppCheckメトリクスページのスクリーンショット

各製品のリクエストメトリックは、次の4つのカテゴリに分類されます。

確認済みのリクエストとは、有効なAppCheckトークンを持つリクエストです。 App Checkの適用を有効にすると、このカテゴリのリクエストのみが成功します。
古いクライアントリクエストとは、AppCheckトークンが欠落しているリクエストです。これらのリクエストは、アプリチェックがアプリに含まれる前の古いバージョンのFirebaseSDKからのものである可能性があります。
不明な発信元のリクエストとは、App Checkトークンが欠落しているリクエストであり、FirebaseSDKからのものではないようです。これらは、盗まれたAPIキーを使用して行われたリクエスト、またはFirebaseSDKを使用せずに行われた偽造されたリクエストからのものである可能性があります。
無効なリクエストとは、アプリを偽装しようとしている不正なクライアントからの、またはエミュレートされた環境からの、無効なアプリチェックトークンを持つリクエストです。

アプリのこれらのカテゴリの分布は、施行を有効にすることを決定したときに通知する必要があります。ここにいくつかのガイドラインがあります：

最近のリクエストのほとんどすべてが検証済みのクライアントからのものである場合は、強制を有効にしてバックエンドリソースの保護を開始することを検討してください。
最近のリクエストの大部分が古くなっている可能性のあるクライアントからのものである場合、ユーザーの混乱を避けるために、施行を有効にする前に、より多くのユーザーがアプリを更新するのを待つことを検討してください。リリースされたアプリにAppCheckを適用すると、AppCheckSDKと統合されていない以前のアプリバージョンが破損します。
アプリがまだ起動していない場合は、使用中の古いクライアントがないため、すぐにAppCheckの適用を有効にする必要があります。

クラウド機能

Cloud Functionsの場合、関数のログを調べることでAppCheckの指標を取得できます。呼び出し可能な関数を呼び出すたびに、次の例のような構造化されたログエントリが出力されます。

{
  "severity": "INFO",    // INFO, WARNING, or ERROR
  "logging.googleapis.com/labels": {"firebase-log-type": "callable-request-verification"},
  "jsonPayload": {
    "message": "Callable header verifications passed.",
    "verifications": {
      // ...
      "app": "MISSING",  // VALID, INVALID, or MISSING
    }
  }
}

次の指標フィルターを使用してログベースのカウンター指標を作成することで、GoogleCloudConsoleでこれらの指標を分析できます。

resource.type="cloud_function"
resource.labels.function_name="YOUR_CLOUD_FUNCTION"
resource.labels.region="us-central1"
labels.firebase-log-type="callable-request-verification"

フィールドjsonPayload.verifications.appCheckを使用してメトリックにラベルを付けます。

5.施行を有効にする

施行を有効にするには、以下の各製品の指示に従ってください。製品の施行を有効にすると、その製品に対する未確認のリクエストはすべて拒否されます。

リアルタイムデータベース、Cloud Firestore、およびCloud Storage

Realtime Database、Cloud Firestore（iOSおよびAndroid）、およびCloudStorageの適用を有効にするには：

Firebaseコンソールの[アプリチェック]セクションを開きます。
施行を有効にする製品のメトリックビューを展開します。
[強制]をクリックして、選択を確認します。

強制を有効にしてから有効になるまで、最大15分かかる場合があることに注意してください。

クラウド機能

クラウド機能のアプリチェックの実施を有効にするを参照してください。

費用に関する注意

App Checkは、Webアプリを実行しているブラウザーがApp Checkトークンを更新するたびに、ユーザーの応答トークンを検証するための評価を作成します。プロジェクトは、無料の割り当てを超えて作成された評価ごとに課金されます。詳細については、 reCAPTCHAEnterpriseの価格を参照してください。

デフォルトでは、Webアプリはこのトークンを1時間ごとに2回更新します。アプリがアプリチェックトークンを更新する頻度（したがって、新しい評価が作成される頻度）を制御するには、それらのTTLを構成します。

次のステップ

App Checkにアプリを登録した後、開発中のローカルや継続的インテグレーション（CI）環境など、App Checkが通常は有効と分類されない環境でアプリを実行する場合は、次のように作成できます。実際のアテステーションプロバイダーの代わりにAppCheckデバッグプロバイダーを使用するアプリのデバッグビルド。

Webアプリのデバッグプロバイダーでのアプリチェックの使用を参照してください。