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

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

reCAPTCHA v3は、無料のサービスです。アプリのチェックもサポートしていreCAPTCHAのエンタープライズ、無償割当で有料サービスを。 reCAPTCHAのV3とreCAPTCHAのエンタープライズとの違いを学ぶためには、参照機能の比較を。

reCAPTCHAv3はユーザーには表示されないことに注意してください。 reCAPTCHA v3プロバイダーは、ユーザーがいつでも課題を解決する必要はありません。参照してくださいreCAPTCHAのv3のドキュメントを。

独自のカスタムプロバイダとのAppチェックを使用する場合は、参照のカスタムアプリのチェック・プロバイダーを実装。

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

  1. JavaScriptのプロジェクトにFirebaseを追加あなたはまだ行っていない場合。

  2. reCAPTCHAのv3のためにあなたのサイトを登録して、reCAPTCHAのv3のサイトの鍵と秘密鍵を取得します。

  3. でreCAPTCHAのプロバイダとアプリケーションのチェックを使用するようにアプリを登録するプロジェクト設定>アプリケーションのチェックFirebaseコンソールのセクション。あなたは前のステップで得た秘密鍵を提供する必要があります。

    Firebase製品の適用を有効にすると、登録されたアプリのみが製品のバックエンドリソースにアクセスできるようになるため、通常はプロジェクトのすべてのアプリを登録する必要があります。

  4. オプション：アプリの登録設定では、プロバイダによって発行されたアプリケーション・チェック・トークンのカスタム生存時間（TTL）を設定します。 TTLは30分から7日の間の任意の値に設定できます。この値を変更するときは、次のトレードオフに注意してください。

    • セキュリティ：TTLを短くすると、漏洩または傍受されたトークンが攻撃者によって悪用される可能性のあるウィンドウが減少するため、セキュリティが強化されます。
    • パフォーマンス：TTLが短いということは、アプリがより頻繁にアテステーションを実行することを意味します。アプリの認証プロセスは、実行されるたびにネットワークリクエストにレイテンシを追加するため、TTLが短いとアプリのパフォーマンスに影響を与える可能性があります。
    • 割り当てとコスト：TTLを短くし、再認証を頻繁に行うと、割り当てがより早く使い果たされます。有料サービスの場合、コストが高くなる可能性があります。参照してくださいクォータ＆制限を。

    1日のデフォルトのTTLは、ほとんどのアプリケーションのための合理的です。 App Checkライブラリは、TTL期間の約半分でトークンを更新することに注意してください。

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

あなたのWebアプリにFirebaseを追加し、あなたがまだの場合。必ずAppCheckライブラリをインポートしてください。

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

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

Webバージョン9

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

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

// Pass your reCAPTCHA v3 site key (public key) to activate(). Make sure this
// key is the counterpart to the secret key you set in the Firebase console.
const appCheck = initializeAppCheck(app, {
  provider: new ReCaptchaV3Provider('abcdefghijklmnopqrstuvwxy-1234567890abcd'),

  // Optional argument. If true, the SDK automatically refreshes App Check
  // tokens as needed.
  isTokenAutoRefreshEnabled: true
});
index.js

Webバージョン8

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

const appCheck = firebase.appCheck();
// Pass your reCAPTCHA v3 site key (public key) to activate(). Make sure this
// key is the counterpart to the secret key you set in the Firebase console.
appCheck.activate(
  'abcdefghijklmnopqrstuvwxy-1234567890abcd',

  // Optional argument. If true, the SDK automatically refreshes App Check
  // tokens as needed.
  true);
index.js

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

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

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

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

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

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

製品のアプリケーションのチェック要求メトリックを表示するには、開くプロジェクト設定>アプリケーションのチェックFirebaseコンソールのセクションを。例えば：

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

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

  • 検証の要求は有効なアプリケーションはトークンをチェック有するものです。 App Checkの適用を有効にすると、このカテゴリのリクエストのみが成功します。

  • 古いクライアントの要求は、Appチェックトークンが欠落しているものです。これらのリクエストは、アプリチェックがアプリに含まれる前の古いバージョンのFirebaseSDKからのものである可能性があります。

  • 原因不明の要求は、アプリケーションはトークン確認不足しているものであり、それらはFirebase SDKから来るようには見えません。これらは、盗まれたAPIキーを使用して行われたリクエスト、またはFirebaseSDKを使用せずに行われた偽造されたリクエストからのものである可能性があります。

  • 無効なリクエストは、無効なアプリはアプリを偽装しようとして本物でないクライアントから、またはエミュレートされた環境からであるかもしれない、トークンチェック有するものです。

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

  • 最近のリクエストのほとんどすべてが検証済みのクライアントからのものである場合は、強制を有効にしてバックエンドリソースの保護を開始することを検討してください。

  • 最近のリクエストの大部分が古いクライアントからのものである場合は、ユーザーの混乱を避けるために、強制を有効にする前に、より多くのユーザーがアプリを更新するのを待つことを検討してください。リリースされたアプリにAppCheckを適用すると、App CheckSDKと統合されていない以前のアプリバージョンが破損します。

  • アプリがまだ起動されていない場合は、使用中の古いクライアントがないため、すぐにAppCheckの適用を有効にする必要があります。

クラウド機能

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

{
  "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
    }
  }
}

あなたがでGoogleクラウドコンソールでこれらの指標を分析することができます作成カウンタメトリックログをベース以下のメトリックのフィルタで：

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の適用を有効にするには：

  1. 開き、プロジェクト設定>アプリケーションのチェックFirebaseコンソールのセクションを。

  2. 施行を有効にする製品のメトリックビューを展開します。

  3. 強制クリックして選択を確認。

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

クラウド機能

参照クラウド機能のためのAppチェック執行を有効にします。

次のステップ

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

参照してください使用アプリケーションは、Webアプリケーション内のデバッグプロバイダに確認してください。