このページでは、スコアを解釈して、ユーザー インタラクションによって生じるリスクのレベルを理解し、モバイルアプリに適したアクションを取る方法について説明します。
reCAPTCHA は、モバイルアプリとのインタラクションに基づいてリクエストごとにスコアを返します。reCAPTCHA からスコアを入手したら、そのスコアを解釈して、サイトでモバイルアプリに適したアクションを行う必要があります。
始める前に
評価を解釈する
バックエンドが reCAPTCHA にユーザーの reCAPTCHA レスポンス トークンを送信すると、次の例に示すように JSON レスポンスとして評価を受け取ります。
評価を解釈するには、次のパラメータを考慮します。
valid
: 提供されたユーザー レスポンス トークンが有効かどうかを示します。valid = false
の場合、理由はinvalidReason
で指定されます。valid = false
は、ユーザーが課題の解決に失敗したか、sitekey
の不一致があることを意味する場合もあります。invalidReason
:valid = false
の場合はレスポンスに関連付けられた理由。action
: reCAPTCHA の検証をトリガーするユーザー インタラクション。expectedAction
: 評価の作成時に指定した、予想されるユーザーのアクション。score
: ユーザー インタラクションが与えるリスクのレベル。reasons
: reCAPTCHA がユーザー インタラクションをどのように解釈したかに関する追加情報。理由コードは、プロジェクトに請求先アカウントを追加して自動セキュリティ審査をトリガーした後に利用できるようになります。理由コードへのアクセスをリクエストするには、プロジェクトに請求先アカウントを追加します。
{ "event":{ "expectedAction":"EXPECTED_ACTION", "hashedAccountId":"ACCOUNT_ID", "siteKey":"KEY_ID", "token":"TOKEN", "userAgent":"(USER-PROVIDED STRING)", "userIpAddress":"USER_PROVIDED_IP_ADDRESS" }, "name":"ASSESSMENT_ID", "riskAnalysis":{ "reasons":[], "score":"SCORE" }, "tokenProperties":{ "action":"USER_INTERACTION", "createTime":"TIMESTAMP", "hostname":"HOSTNAME", "invalidReason":"(ENUM)", "valid":(BOOLEAN) } }
アクションを確認する
JSON レスポンスには、execute()
を呼び出すときにユーザー インタラクションとして指定した action
パラメータと、評価の作成時に指定した expectedAction
パラメータが含まれます。
action
が expectedAction
と一致することを検証します。たとえば、login ページで login
アクションが返されます。不一致が存在する場合は、攻撃者が操作を偽装しようとしていることを示しています。ユーザー インタラクションに対して、追加の検証を行う、またはインタラクションをブロックするなどのアクションを講じて、不正なアクティビティを防止できます。
スコアを解釈する
reCAPTCHA のスコアリング システムは、以前のバージョンの reCAPTCHA からの拡張であり、より詳細なレスポンスを可能にします。reCAPTCHA には、0.0 から 1.0 までの値の範囲のスコアを持つ 11 のレベルがあります。スコア 1.0 は、インタラクションのリスクが低く、正当である可能性が非常に高いことを示します。一方で 0.0 は、インタラクションのリスクが高く、不正行為の可能性があることを示します。プロジェクトに課金アカウントを追加して自動セキュリティ審査をトリガーする前に使用できるスコアレベルは、11 レベルのうち 0.1、0.3、0.7、0.9 の 4 つのみです。
11 のスコアレベルへのアクセスをリクエストするには、プロジェクトに請求先アカウントを追加します。
reCAPTCHA は、モバイルアプリ上の実際のトラフィックをモニタリングすることで学習していきます。したがって、実装から 7 日以内にステージング環境で得られたスコアは、長期にわたって本番環境で得られたスコアと異なる場合があります。
モバイルアプリ用の reCAPTCHA キーによってユーザーフローが中断されることはないため、最初にアクションを行わずに reCAPTCHA を実行し、その後にトラフィックを確認してしきい値を決定できます。
スコアに基づいて、モバイルアプリのコンテキストで適切なアクションを講じることができます。モバイルアプリをより適切に保護するには、トラフィックをブロックするのではなく、バックグラウンドでアクションを講じることをおすすめします。
次の表では、実行できる操作の一部を示します。
ユースケース | アクション |
---|---|
ログイン | スコアが低い場合は、MFA またはメール確認を必須にして、認証情報の盗み取り攻撃を回避します。 |
ソーシャル | 不正行為者からの未承認の友達リクエストを制限し、危険性のあるコメントを管理者に送信します。 |
ecommerce | 実際の販売を bot に先だって実施し、危険性のあるトランザクションを特定します。 |
理由コード
理由コードは、請求先アカウントを追加して自動セキュリティ審査をトリガーした後に利用できるようになります。理由コードへのアクセスをリクエストするには、プロジェクトに請求先アカウントを追加します。
一部のスコアは、reCAPTCHA がインタラクションをどのように解釈したのかについての詳細情報を示す理由コードが付加されて返される場合があります。
次の表に、理由コードと説明を示します。
理由コード | 説明 |
---|---|
AUTOMATION | 自動化されたエージェントの行動とインタラクションが一致しています。 |
UNEXPECTED_ENVIRONMENT | イベントの発生元が不正な環境です。 |
TOO_MUCH_TRAFFIC | イベント ソースからのトラフィック量が通常よりも多くなっています。 |
UNEXPECTED_USAGE_PATTERNS | サイトのインタラクションが、想定したパターンと大きく異なっていました。 |
LOW_CONFIDENCE_SCORE | このサイトから受信したトラフィック量が過少であるため、品質リスク分析を生成できません。 |
次のステップ
- サイト固有のモデルに調整するには、評価 ID を Google に送り、真陽性と真陰性、または正しいエラーかどうかを確認します。詳細については、評価にアノテーションを付けるをご覧ください。