ECHOSCAN
UNQ
STB
#···
概要 ブログ

APIキーの不正利用と無料枠のリスク

APIキーの不正利用対策は、無料リクエスト枠やトライアル用の認証情報を提供するAPIプラットフォーム、AIサービス、開発者向けツールにとって重要なポリシー設計です。EchoScanは、キーや追加の利用枠を付与する前に、デバイスの継続性とブラウザ、ネットワーク、自動化に関するリスク情報を提供します。入力はブラウザで生成されたImprint、出力はサーバー側で取得するLiteまたはProのReportです。API提供者は、その結果をアカウント、利用条件、決済、本人確認、リクエスト頻度の情報と組み合わせて判断します。

メールアドレスを変えるだけでは不十分な理由

メールアドレスはアカウントを区別する手掛かりにはなりますが、利用しているデバイスやアクセス環境までは示しません。短時間に新しいアドレスを作成しても、同じブラウザやデバイス環境が使われ続ける場合があります。一方、共有端末、教室、家庭、開発チームでは、複数の正当なメールアドレスが1台のデバイスから利用されることもあります。

そのため、API提供者は複数の判断材料を組み合わせる必要があります。アカウントの作成日時、連絡先の確認状況、請求状態、招待関係、過去の利用枠、リクエスト頻度は、サービス上の利用履歴を示します。デバイスの継続性とアクセスリスクは、リクエスト時の環境を補足します。どちらか一方だけで、もう一方を置き換えることはできません。

キーを発行する前にデバイス情報を確認する

  1. 登録、開発者向けトライアル、キー作成、利用枠追加のページでBrowser Verifierを実行します。
  2. { imprint }を受け取り、保護対象のリクエストと一緒にAPI提供者のバックエンドへ送ります。
  3. バックエンドからSecret API Keyを使ってReport API v1を照会します。
  4. risk.statusと、契約プランで利用できる継続性の項目を確認します。
  5. アカウント、利用枠、決済、本人確認、リクエスト頻度のルールと組み合わせます。
  6. API提供者が定めた許可、追加認証、制限、保留、確認、拒否の処理を行います。

公開可能なEnvironment IDはブラウザコードに設定し、Secret API Keyはサーバーだけに保存します。この境界により、訪問者が連携用の認証情報を使ってReportを読み取ることを防ぎます。

継続性とアクセスリスクから分かること

デバイスの継続性からは、その環境が以前にも観測されたか、何回観測されたかを確認できます。Proでは初回と前回の観測時刻も確認できます。ブラウザとOSの整合性、ネットワーク情報、自動化の兆候、最近のアクティビティ、Historyは、必要に応じて追加の判断材料になります。

これらの情報は、初めて観測した環境か、アクセスの集中を詳しく確認すべきか、追加認証を求めるべきリスク状態か、といった個別の判断に役立ちます。無料プランの対象者かどうかをEchoScanが決めるわけではありません。利用条件はAPI提供者が定めます。

複数の情報を組み合わせた利用枠ポリシー

実際の運用では、次のような情報を組み合わせます。

  • アカウント作成日時、メールや電話番号の確認状況、組織への所属
  • 過去に取得した無料キー、クレジット、トライアル、利用枠
  • 支払方法と有料プランへの移行履歴
  • デバイスの継続性、ネットワーク情報、自動化リスク
  • リクエスト頻度、同時実行数、Tokenや計算のリソースコスト、エンドポイントの重要度
  • 完了した追加認証、手動確認、異議申し立ての履歴

API提供者は、最終判断を説明できるサービス上の記録を保持します。EchoScanが提供するのはアクセス時の情報であり、アカウントや契約に関する記録のすべてではありません。

中程度のリスクには段階的に対応する

SUSPICIOUSは追加情報を確認するきっかけであり、自動的な拒否を意味しません。メールや電話番号の確認、支払方法の登録、初期利用枠の縮小、高コスト機能の一時保留、同時実行数の制限、短い有効期限、手動確認などを選択できます。

アクセスリスクが、API提供者のアカウント情報や決済情報とも一致する場合は、より強い制限を検討できます。リソースコスト、取り消しやすさ、利用者の負担、正当な開発者を誤って止めた場合の影響に合わせて対応を調整します。

同じデバイスからの再訪だけでは不正の根拠にならない

同じデバイスは、正当な再訪、共有端末、サポートを受けながらの設定、学校のPC、企業ゲートウェイ、顧客が管理する自動テストでも使われます。seen_before: trueや高いaccess_countだけで、複数アカウントによる不正利用を証明することはできません。

再訪をきっかけに、時刻の分布、関連するアカウント、利用枠の履歴、本人確認、決済、ネットワークの変化、自動化リスク、保護対象の操作を確認します。すべての再訪デバイスを拒否すると誤検知が増え、デバイスを切り替える不正利用も見逃します。

LiteとProの選び方

Liteは全体のrisk.status、基本的な継続性、ブラウザ、OS、ネットワークの結果を提供します。追加認証や利用枠縮小など、比較的単純な対応の起点にできます。

Proは、製品運用向けのリスク理由、初回・前回の観測時刻、最近のアクティビティ、詳しいネットワーク情報、Historyを使った確認に適しています。どちらも同じReportエンドポイントを使うため、ブラウザとバックエンドの境界を変えずに確認項目を増やせます。

次のステップ

開発者向け導入フローを確認し、既存の利用枠ポリシーに結果を組み込んでください。ブラウザフィンガープリントAPIガイドでは、公開Environment IDとサーバー専用Secret API Keyの境界を説明しています。

API利用枠の判断に関するよくある質問

1台のデバイスを1つのAPIアカウントだけに制限するべきですか?

自動的に制限するべきではありません。共有端末、チーム、教室、サポート対応、正当な再訪でも、複数のアカウントが同じデバイスから利用されます。再訪は追加確認の材料であり、それだけで拒否する理由にはなりません。

EchoScanはAPI利用枠の不正利用を断定しますか?

断定しません。EchoScanが返すのはデバイスの継続性とアクセスリスクです。API提供者がアカウント、利用枠、決済、本人確認、リクエスト頻度の情報と組み合わせて最終判断します。

API利用枠の確認でProが役立つのはいつですか?

Liteのリスク状態と継続性に加えて、製品運用向けのリスク理由、初回・前回の観測時刻、最近のアクティビティ、詳しいネットワーク情報、Historyが必要な場合にProが役立ちます。