管理APIの三重境界――認証・ロール判定・レート制限の適用順序

有効なAPIキーを持つ利用者でも実行してはいけない操作をどこで止め、大量リクエストを業務権限と別にどう制限するか。

コードから観測できること

1. auth middleware、role guard、rate limitは別モジュールである。認証済みか、操作権限があるか、頻度が許容内かは異なる問いであり、一つの判定結果で代用できない。
2. admin auth configにはテストがあり、設定不足時の挙動も検証対象としてコード化されている。安全な初期値を評価するときは正常ログインだけを見ない。
3. レート制限の研究ではHTTP 429件数だけでなく、制限キーの粒度、時間窓、Cloudflare edgeの並列性、正当な一括操作への影響を測る必要がある。

再現・追加測定の手順

1. Owner/Admin/Staffの最小アカウントを作る
2. 同一endpointへ各ロールで要求する
3. 同じ認証情報から並列要求を発生させる
4. 応答コードとD1副作用を権限・頻度別に表へする

この資料だけでは証明できないこと

1. middleware単体テストは全routeへの付け忘れを検出しないためroute一覧監査が必要。
2. IPのみを識別子にする制限は共有回線で誤検知する可能性がある。

このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。