APIレート制限の設計｜正しい認証のまま会員情報を大量に引かれるAPIを、鍵・重さ・業務の流れで止める

APIレート制限は、正しい認証のまま会員情報を大量に引かれる事故を、手前で止めるための仕組みです。2026年10月15日、ソースネクストは「会員情報取得 API」が不正に使われ、最大22,519,960件の会員情報が流出した可能性があると発表しました。

連載「事故から逆算するWebセキュリティ」の第9回は、この事案を入口に、会員情報を返すAPIの量の守り方をまとめます。1回ずつの認可が正しくても、回数が積み上がれば全件に届きます。回数の上限をどこに、何ごとに置くか。上限の内側でゆっくり抜かれたら、どう見つけるか。手元で実行して確かめます。

発表のタイムラインは次のとおりです（ソースネクスト情報漏洩｜最大2,252万件・パスワードも対象、会員とAPIを持つ側が確認すること の整理から）。

悪用された API の脆弱性の中身は公表されていません。本記事はソースネクストで何が起きたかを推測せず、「1件ずつは正しい形のリクエストが、数で積み上がる」型を自分の API で塞ぐ方法に絞ります。事案の読み方の全体像は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にまとめています。

同じ型は、原因まで公表された事案にもあります。アフラックは7月31日の調査結果で、攻撃のアクセスが通常の利用と同じ形式だったため即座に検知できず、短時間に大量のデータ照会があったときの監視・制御の機能も足りなかったと説明しました（漏えいは約440万人）。再発防止策には、データ照会時の認可の強化と、大量アクセスの監視・制御の強化が並びます。10月13日に NICT が注意喚起した「A2B攻撃」も、公開アプリを解析して裏の API を直接叩く手口で、暫定の緩和策に不要な API の停止とアクセス制限、監視の強化を挙げています。

1件ずつ正しくても抜かれる：APIレート制限が要る3つの型

会員情報を返す API が大量に引かれる型は、主に3つあります。どれも、1回ずつのリクエストは認証を通ります。

OWASP の API1 は、IDを受け取るすべての API で「ログイン中の利用者がその対象を操作してよいか」を確かめるよう求めています。これは1回ごとの問いです。1万回目の正しいリクエストにも、認可は同じ答えでOKを返します。回数が積み上がることは、認可の外側で止めるしかありません。

OWASP API4（Unrestricted Resource Consumption）は、一定時間に API を使える回数の制限（レート制限）と、1回の応答で返す件数の上限を挙げています。API6（Unrestricted Access to Sensitive Business Flows）は、購入や予約のように使いすぎると事業を損なう業務の流れを洗い出して守るよう求めています。

APIレート制限の鍵を決める：誰ごと・重さごと・業務の流れごと

レート制限は「何ごとに数えるか」（鍵）で効き方が決まります。IPアドレスだけでは足りません。API6 は、攻撃者が異なるIPアドレスと場所に分散して送る例を挙げています。逆に、会社や携帯回線では多くの人が1つのIPを共有します。

重さで数える例として、API4 は、パスワード再設定のSMSを1通0.05ドルで送るサービスに、攻撃者が最初の API を数万回呼んで数分で数千ドルを失わせる例を挙げています。API2 は、パスワード再設定の窓口をログインと同じ強さで守り、認証の窓口には通常のレート制限より厳しい上限を置くよう求めています。会員登録の大量作成は OAT-019 Account Creation です。書き出しのように1回で多くの会員を返す API は、回数ではなく返した件数で数えます。

鍵が欠けたリクエストは、数えられずに素通りします。nginx の limit_req は鍵が空のリクエストを数えません。AWS WAF のレートベースルールも、集計キーに指定した要素が無いリクエストを評価から外します。トークンごとの上限を置くときは、トークンの無いリクエストのためにIPごとの上限も残します。

429とRetry-After、RateLimitヘッダーの返し方

上限を超えたら、429 Too Many Requests を返します。RFC 6585 は、429 の応答に事情の説明を含めるべきで、Retry-After で待つ時間を示してよいとしています。誰をどう数えるかは定めていません。429 の応答はキャッシュに保存してはいけません。Retry-After の値は、秒数の整数か日時です（RFC 9110）。

既定値に注意します。nginx の limit_req は、拒否したときの既定のステータスが 503 で、limit_req_status で 429 に変えます。Cloudflare のレート制限ルールは、ブロックの既定が 429 です。

残りの回数を伝える RateLimit ヘッダーは、IETF の HTTPAPI ワーキンググループの Internet-Draft です。リポジトリのタグで最新は -11（2026-04-18 のコミット）で、原稿の中の RFC 番号は「RFC nnnn」のままです。初期の版（-03 など）は RateLimit-Limit・RateLimit-Remaining・RateLimit-Reset の3つでしたが、いまの版は RateLimit-Policy（上限の方針）と RateLimit（いまの残り）の2つです。

草案は、信頼できない相手に処理能力を明かさないよう書いています。401 や 403 も回数に数えると、他人の利用状況を探られうるとも書いています。会員情報の API では、残りを細かく返すことが攻撃者の速度調整を助けます。返すのは自社のアプリや契約先の API に限る判断もあります。

APIレート制限の方式と置き場所

数え方は主に4つです。

nginx の limit_req はリーキーバケットで、burst の既定は0です。AWS WAF のレートベースルールは、直近60・120・300・600秒のどれかを振り返り、約10秒ごとに数を確かめます。

置き場所は1つに決めず、重ねます。エッジは量の多い送信を安く落とせますが、Cloudflare のレート制限ルールは、数を世界全体で共有せずデータセンターごとに持ちます。リクエストを見てから数を更新するまで最大数秒の遅れがあり、決まった数だけを正確に通す作りではないとも書いています。ボットの見分け方は 「人間かボットか」を超えて：CloudflareのPrivacy Pass・Web Bot Auth・Agent Registryで変わるアクセス制御 で扱っています。

「どの会員を何件読んだか」を知っているのはアプリだけです。業務の流れごとの上限と、次に試す種類数の検知はアプリに置きます。

手元で確かめる：トークンバケットと読んだ会員の種類数

Python 3.13.16 の標準ライブラリだけで、会員情報を返す小さな API（/api/members/<ID>）を手元に立てました。トークンからアカウントを引き、アカウントを鍵にしたトークンバケット（上限20、毎秒5回の補充）で数えます。次がその部分です。

class TokenBucket:
    def __init__(self, rate, burst):
        self.rate, self.burst = rate, burst      # 1秒に足す数, 貯められる上限
        self.state, self.lock = {}, threading.Lock()
    def take(self, key):
        now = time.monotonic()
        with self.lock:
            tokens, last = self.state.get(key, (self.burst, now))
            tokens = min(self.burst, tokens + (now - last) * self.rate)
            if tokens >= 1:
                self.state[key] = (tokens - 1, now)
                return True, 0
            self.state[key] = (tokens, now)
            return False, math.ceil((1 - tokens) / self.rate)  # Retry-After は整数秒

LIMIT = TokenBucket(rate=5, burst=20)

# do_GET の中（抜粋）。account は認証済みのトークンから引いたアカウント
ok, wait = LIMIT.take(account)          # 鍵はIPでなくアカウント
if not ok:
    return self.reply(429, {"error": "too many requests"}, {"Retry-After": str(wait)})

送る側も標準ライブラリで書き、10並列で一気に送る場合と、決まった速さで送る場合を比べました（2026-10-17、127.0.0.1）。

一気に送る相手には429が返り、Retry-After はすべて1秒でした。毎秒4回の送信は、上限の内側なので1回も止まりません。ゆっくりした列挙は、回数の制限では見つかりません。

そこで、API が残したログ（1行1件のJSON）から、アカウントごとに1時間で読んだ会員の種類数を数えます。

# 使い方: python3 detect.py access.jsonl
import collections, json, sys
seen = collections.defaultdict(set)                 # (アカウント, 時) -> 読んだ会員ID
for line in open(sys.argv[1]):
    r = json.loads(line)
    if r["status"] == 200:
        seen[(r["account"], int(r["ts"] // 3600))].add(r["member"])
for (account, hour), members in sorted(seen.items()):
    print(account, hour, len(members), "FLAG" if len(members) >= 100 else "ok")

列挙した側は300種類で FLAG、同じ300回を送った普通の利用者は3種類で ok でした（陰性対照）。一気に送った表の2・3行目のログでは、各アカウントが読めたのは23・24種類で、どれも ok です。

しきい値の100と1時間の区切りは、この実験のための値です。区切りは固定窓なので、境目をまたぐ列挙は2つに分かれます。本番では、利用者が普段読む種類数を測ってから決めます。

APIレート制限だけで足りない部分の対策：ページング上限・返す項目・ログ

レート制限は、量の上限を決めるだけです。抜かれたときの被害を小さくし、早く気づくために、次も合わせて入れます。

・1回で返す件数の上限：API4 は、返す件数を決める引数をサーバー側で検査するよう求めている。limit=100000 を受け付けない
・返す項目を絞る：API3 は、to_json() のような丸ごとの変換を避け、返す項目を選んで最小にするよう求めている。画面に出さない生年月日や電話番号は返さない
・推測しにくいID：API1 は、連番より推測しにくい値をIDに使うよう挙げている。ただし認可の代わりにはならない
・種類数と存在しないIDの率を見る：1アカウントが読んだ会員の種類数に加え、404 の多さも列挙の兆候になる
・試してから止める：nginx の limit_req_dry_run は、止めずに超えた数だけを記録する

ログには、時刻、アカウントID、トークンの識別子（値そのものは残さない）、送信元IP、エンドポイントの型（/api/members/{id}）、読んだ会員ID、ステータス、返した件数、レート制限の判定を残します。nginx なら判定は $limit_req_status に PASSED・REJECTED などで入ります。会員IDが残っていないと、漏れた範囲を後から特定できません。

影響範囲を決めるのは、1つのトークンで読める会員の範囲と、上限に届くまでの時間です。上限を毎秒5回にしても、1日では43万回に届きます。日ごとの上限と種類数の検知を重ねます。

参照ソース

• アフラック「当社システムに対する不正アクセスの発生および情報漏えいに関する調査結果と再発防止策について」（2026-07-31）
• NICT「相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」（2026-10-13）
• OWASP API Security Top 10 2023（API1・API2・API3・API4・API6 の原稿を OWASP/API-Security から2026-10-17に取得）
• OWASP Automated Threats to Web Applications（OAT-007・008・011・019 の原稿と Handbook 1.30 の PDF を リポジトリ から取得）
• RFC 6585 Additional HTTP Status Codes §4（httpwg/httpwg.github.io の写しで確認）
• RFC 9110 HTTP Semantics §10.2.3 Retry-After（同上）
• draft-ietf-httpapi-ratelimit-headers（ietf-wg-httpapi/ratelimit-headers の原稿と -03・-06・-07・-10・-11 のタグを確認）
• nginx ngx_http_limit_req_module（nginx/nginx.org の原稿で確認）
• Cloudflare Rate limiting rules（cloudflare/cloudflare-docs の parameters・request-rate の原稿で確認）
• AWS WAF Rate-based rule statement（botocore 1.43.114 の wafv2 モデルの RateBasedStatement の説明で確認）