ウェブアプリで reCAPTCHA Enterprise を使用して App Check を使ってみる

このページでは、reCAPTCHA Enterprise プロバイダを使用して、ウェブアプリで App Check を有効にする方法について説明します。App Check を有効にすると、自分のアプリだけがプロジェクトのバックエンドリソースにアクセスできるようになります。この機能の概要をご覧ください。

App Check では reCAPTCHA Enterprise のスコアベースのサイトキーを使用しているため、ユーザーには表示されないことに留意してください。reCAPTCHA Enterprise プロバイダがユーザーに問題の解決を求めることはありません。

ユースケースで App Check によって実装されていない reCAPTCHA Enterprise 機能が必要な場合、または独自のカスタムプロバイダで App Check を使用する場合は、App Check カスタムプロバイダを実装するをご覧ください。

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

Firebase を JavaScript プロジェクトに追加します（まだ行っていない場合）。
Cloud コンソールの [reCAPTCHA Enterprise] セクションを開き、次の操作を行います。
1. reCAPTCHA Enterprise API を有効にするよう求めるメッセージが表示された場合は、有効にします。
2. ウェブサイト タイプのキーを作成します。ウェブアプリをホストするドメインを指定する必要があります。[チェックボックスによる本人確認を使用する] オプションはオフのままにします。
Firebase コンソールの App Check セクションで、App Check を使用するアプリを reCAPTCHA Enterprise プロバイダに登録します。前の手順で取得したサイトキーを指定する必要があります。

Firebase プロダクトで適用を有効にすると、プロダクトのバックエンドリソースにアクセスできるのは登録されているアプリのみとなるため、通常、プロジェクトのアプリすべてを登録する必要があります。
省略可: アプリの登録設定で、プロバイダが発行する App Check トークンのカスタム有効期間（TTL）を設定します。TTL は 30 分から 7 日までの任意の値に設定できます。この値を変更する場合は、次のトレードオフに注意してください。
- セキュリティ: TTL が短いほど、漏えいしたトークンや傍受されたトークンが攻撃者によって悪用される可能性が低減するため、セキュリティが向上します。
- パフォーマンス: TTL が短いほど、アプリで証明書の取得が頻繁に行われます。アプリで証明書が取得されるたびにネットワークリクエストのレイテンシが増加するため、TTL が短いと、アプリのパフォーマンスに影響する可能性があります。
- 割り当てとコスト: TTL を短くすると、証明書の取得が頻繁に発生し、割り当てが早く消費されます。有料サービスの場合は、費用が増加する可能性があります。割り当てと上限をご覧ください。
通常は、デフォルトの TTL（1 時間）で十分です。App Check ライブラリは TTL の約半分でトークンを更新することに留意してください。

詳細設定を構成する（省略可）

ユーザーがウェブアプリにアクセスすると、reCAPTCHA Enterprise はユーザーインタラクションがもたらすリスクレベルを評価し、0.1 刻みの 0.0～1.0 の範囲でスコアを返します。スコア 1.0 は、インタラクションのリスクが低く、正当である可能性が非常に高いことを示します。一方で 0.0 は、インタラクションのリスクが高く、不正行為の可能性があることを示します。App Check では、アプリのリスクしきい値を設定して、このリスクに対する許容度を調整できます。

ほとんどのユースケースでは、デフォルトのしきい値 0.5 が推奨されます。ユースケースで調整が必要な場合は、各ウェブアプリに対して Firebase コンソールの App Check セクションで構成できます。

詳細

App Check は、構成されたアプリのリスクしきい値を、ユーザーインタラクションが正当と見なされるために必要な最低限の reCAPTCHA Enterprise スコアとして使用します。構成されたしきい値を厳密に下回る reCAPTCHA Enterprise スコアはすべて拒否されます。アプリのリスクしきい値を調整する際は、次の点に注意してください。

reCAPTCHA Enterprise の 11 個のスコアレベルのうち、4 個のスコアレベル 0.1、0.3、0.7、0.9 に限り、Google Cloud 請求先アカウントをプロジェクトに追加する前に使用できます:。この期間、App Check はそれに応じてアプリのリスクしきい値として 0.1、0.3、0.5、0.7、0.9 のみを許可します。ほとんどのユースケースでは、アプリのリスクしきい値には引き続き 0.5 をおすすめします。
- reCAPTCHA Enterprise の 11 個のスコアレベルをすべて有効にするには、Google Cloud 請求先アカウントをプロジェクトに追加します。その方法の 1 つは、Blaze のお支払いプランにアップグレードすることです。設定が完了すると、App Check を使用して、アプリのリスクしきい値を 0.1 刻みの 0.0～1.0 の範囲で設定できるようになります。
  
  注: Google Cloud 請求先アカウントがプロジェクトに追加されると、プロジェクトの自動セキュリティレビューがトリガーされます。詳細については、reCAPTCHA Enterprise のドキュメントをご覧ください。
ウェブアプリの reCAPTCHA Enterprise スコアの高低の分布をモニタリングするには、Google Cloud コンソールの reCAPTCHA Enterprise ページにアクセスし、ウェブアプリで使用されているサイトキーを選択します。
アプリのリスク許容度が低い場合は、スライダーを左に移動して、アプリのリスクしきい値を上げます。
- 値 1.0 に設定することはおすすめしません。というのは、この設定では、正規ユーザーであっても、この高い信頼性基準を満たさない場合はアクセスが拒否される可能性があるためです。
警告: アプリのリスクしきい値を引き上げる前に、正規ユーザーの混乱を避けるために、現在適用されているすべてのサービスで App Check 保護を一時的に無効にすることを検討してください。適用を再開する前に、App Check リクエストの指標をモニタリングして、トラフィックが中断されていないことを確認する必要があります。
アプリのリスク許容度が高い場合は、スライダーを右に移動して、アプリのリスクしきい値を下げます。
- 値 0.0 に設定することはおすすめしません。というのは、この設定では不正行為に対する保護が無効になるためです。

詳細については、reCAPTCHA Enterprise のドキュメントをご覧ください。

2. アプリに App Check ライブラリを追加します。

ウェブアプリに Firebase を追加します（まだ行っていない場合）。必ず App Check ライブラリをインポートしてください。

3. App Check を初期化する

Firebase サービスにアクセスする前に、次の初期化コードをアプリケーションに追加します。Cloud コンソールで作成した reCAPTCHA Enterprise のサイトキーを activate() に渡す必要があります。

Web

import { initializeApp } from "firebase/app";
import { initializeAppCheck, ReCaptchaEnterpriseProvider } from "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

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 にリクエストを送信するたびに App Check トークンを送信しますが、Firebase コンソールの App Check セクションで適用を有効にするまで、Firebase プロダクトは有効なトークンを必要としません。

指標をモニタリングして適用を有効にする

ただし、適用を有効にする前に、既存の正規ユーザーを中断しないように対策を行う必要があります。一方、アプリリソースの不審な使用に気づいた場合は、すぐに適用を有効にすることもできます。

この決定を行うことができるように、使用するサービスの App Check 指標を確認します。

Firebase AI Logic、Data Connect、Realtime Database、Cloud Firestore、Cloud Storage、Authentication、Google Identity for iOS、Maps JavaScript API、Places API（新規）の App Check リクエスト指標をモニタリングします。
Cloud Functions に対して App Check リクエスト指標をモニタリングします。

App Check 適用を有効にする

App Check がユーザーに与える影響を理解し、続行する準備ができたら、App Check の適用を有効にできます。

Firebase AI Logic、Data Connect、Realtime Database、Cloud Firestore、Cloud Storage、Authentication、Google Identity for iOS、Maps JavaScript API、Places API（新規）の App Check の適用を有効にします。
Cloud Functions に対して App Check の適用を有効にします。

デバッグ環境で App Check を使用する

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

ウェブアプリのデバッグプロバイダで App Check を使用するをご覧ください。

費用に関する注意事項

App Check は、ウェブアプリを実行しているブラウザが App Check トークンを更新するたびに、ユーザーのレスポンストークンを検証するために、ユーザーに代わって評価を作成します。無料割り当て枠を超えて作成された評価ごとに、プロジェクトに課金されます。詳しくは、reCAPTCHA の料金をご覧ください。

デフォルトでは、ウェブアプリはこのトークンを 1 時間に 2 回更新します。アプリで App Check トークンの更新頻度（つまり、新しい評価を作成する頻度）を制御するには、TTL を構成します。