ログイン済みのアカウントでも業務を悪用できる

架空の限定販売が始まると、商品はすぐに品切れと表示されます。注文完了数は大きく増えていませんが、支払い待ちの予約が多く、期限が切れると似たアカウント群が在庫を確保し直します。予約APIの入力形式は正しく、アカウント当たりの頻度も高くないため、WAFの遮断数は普段と大差ありません。

時間帯別の販売完了数、購入可能在庫、予約数量と保持時間、再予約までの時間、アカウントごとの有効予約を調べます。決済エラーで予約が解放されない場合や、在庫画面の反映遅延も調べます。職場や学校、集合住宅、携帯回線では公開IPを共有し得るため、IPの一致だけで自動化と判定しません。

OWASP API Securityは、形式が正しいリクエストでも、重要な業務の流れを無制限に利用できれば自動化による悪用が起こると説明しています。事業上守るべき流れを特定し、それぞれに制御を設計します。APIセキュリティ制御の比較とOWASP API Security Top 10の重要業務に関する項目[1]を参照できます。

トラフィックのグラフでは見えない損失

クーポンは、資格なしで使われた枚数や割引額を確認します。登録の悪用には、サポート確認の時間、通知費用、正規利用者が得られなかった特典も関わります。在庫の場合は、買えなかった数量と時間、正規購入の推移を見ます。公開APIでは返した行数、消費したリソース、一時的に使えなかった正規リクエストを追います。

予約が100件失効しても、その件数だけでは販売損失を確定できません。通常の購入断念や後から売れた商品も含まれます。数量と保持時間を掛けると、対策前後の在庫占有量を比較できます。12個の商品が支払いなしでそれぞれ5分間予約された場合は60個・分です。金額の推定には当時の需要、入荷、後から成立した注文などの情報が必要です。

資産ごとの制御点と正規利用への影響

守る資産を選び、その状態を確定するサービスを見つけます。入口で使う信号と、取引確定時の資格条件を記録します。同時に維持する正規利用の基準を決め、誤判定を受けて戻す際の根拠にします。

守る資産繰り返される行為と損失制御点と判断維持すべき正規利用
登録特典と通知登録・認証を繰り返し、特典や通知費を消費入口で試行を制限し、付与時に認証した利用者と条件を確認家族や共有回線からの登録、障害後の認証再依頼
クーポン予算と割引資格なしの適用、複数経路での再利用注文サーバーが資格、企画、期間と消費の一意性を確認注文失敗後の正規の復活と再利用
座席・商品・予約枠未払いで保持し、期限後に確保し直す予約時に期限、保有数、在庫を照合し、確保と調整を一緒に確定支払いに時間がかかる人、支援技術、正規の団体予約
参照APIと提供資料分散したアカウントで範囲を順に取得入口で頻度を制限し、参照側でトークン範囲、検索負荷、出力権限を確認正規のカタログ同期や障害復旧後の一括参照

制限単位を複数にします。ログイン前はIP範囲や接続で集中を緩和し、ログイン後はアカウント・企画別の試行数や有効予約数、商品全体の占有上限を業務サーバーで確認します。アカウントの関連は補助情報として扱います。判断材料が弱い場合は、範囲を絞るか保留して確認します。地域やブラウザーだけで遮断すると、利用者の一部に影響が偏ることがあります。OWASPのボット対策とリクエスト制限[2]

最後の特典と在庫をサーバーで確定する

資格照会と実際の利用確定が分かれていれば、二つの注文が同じ結果を読み、同じ特典を使う場合があります。資格確認と消費記録を同じ整合性の範囲で処理します。一人一回の企画なら記録側で強制します。複数の注文経路が同じ台帳を確認するか、経路ごとに残高を持つ場合はその整合性を管理します。

在庫が残り一個と表示されても、予約時に最新状態と有効な保有数を確認し、二重確定を防ぎます。予約期限後に決済結果が届くと、在庫を別の顧客に割り当てている可能性があります。決済を待つ期間、在庫の再確保、顧客への案内、返金や訂正の担当を決めます。旧版のアプリも同じ条件で試します。

制御そのものの障害時の処理も定めます。占有の確認ができなければ、照会を保ちながら高リスクの新規予約を保留できます。台帳が動作し補助信号だけが遅い場合は、承認済みの低い上限で継続する案もあります。守る資産と既存の約束から判断します。

サービスの仕組み

サービスの前段でリクエストを分類・防御 — リクエストと遮断記録から防御ルールを調整し、証明書とアクセス制御も管理します。

追加確認で購入を行き止まりにしない

先へ進めない利用者に次の操作を示します。短い待機、クーポンの保留、再確認、サポートへの接続を、被害と確認の負担で選びます。根拠が弱ければ許可して観測でき、負担が小さければ購入を止める前に再確認できます。手動審査では、自動取消前に確認すべき項目と期限を渡します。決済の遮断・追加確認・手動審査の基準も参照できます。

CAPTCHAを使う場合は、視覚・聴覚、キーボード、支援技術、低速回線での完了を試します。W3Cの資料は、人間か自動処理かを見分ける操作が障害のある利用者の障壁になることと、方式ごとの課題を説明しています。代替確認で同じ業務を完了できるかと時間を計測します。画面単体の要件を満たしても、確認が何度も出たりセッションが失効したりすると、購入を妨げます。W3CのCAPTCHAアクセシビリティ資料[3]

架空の販売例では、一般予約の上限を下げる前に団体購入の別経路を用意します。予約期限と支払い状態を示し、利用可能な確認手段を備えます。エラー画面は他人の情報やしきい値を出さず、問い合わせ番号を示せます。担当者はリクエストIDと規則の版から誤判定を調べます。WAFが関わった場合はWAF例外のライフサイクルに沿って変更の理由と終了時点を管理します。

損失と誤判定を同時に試験する

観測期間には候補の判定、適用条件の版、正規利用と判断できる後続の証拠を保存します。コンバージョンの全体値だけで商品需要や流入差を対策の結果と取り違えないようにします。近い商品・期間を選び、適用範囲を段階的に広げます。確認済みの悪用と不明な事例を分け、レビュー対象と全試行の割合を区別します。

試験期待する動作記録する証拠
複数のアカウントが一つの在庫を占有し続けるアカウント・企画・商品の制限で再保持を減らし解放購入可能在庫、占有量、注文完了
同じIPに二人の正規購入者個々の資格を確認して完了両方の判定、時間、追加確認の成否
アプリとWebから同じクーポンを同時適用条件を満たす一件の消費のみ確定注文と特典のID、重複なし
キーボード利用と遅い決済代替確認後に所定の時間内で完了操作経路、フォーカス、完了・離脱理由
正規利用者による一括API同期登録済みの範囲と上限で完了範囲別の処理量、追加確認と失敗率

不正な消費、占有量、続いている悪用を見ます。正規と確認した試行のうち追加確認や遮断に遭った割合、確認中の離脱、最終完了、保留解除までの時間も確認します。完了率が下がれば、影響経路を特定して範囲を縮めます。どの条件で誰が元に戻し、残った保留案件を引き継ぐか決めます。