access-control-testing について
access-control-testingは、認証・複数ユーザー・マルチテナント機能を持つアプリの認可を検証するセキュリティテストスキルです。テストマトリクスとリクエスト変更手順により、水平・垂直方向のアクセス制御不備を調べます。
主な機能
- 01水平・垂直権限昇格テスト
- 02未認証アクセスの確認
- 03IDORとテナント境界の確認
- 04マスアサインメントとルートの検査
- 05検出事項の詳細な記録
活用シーン
- 012つのユーザーアカウント間のアクセス検査
- 02低権限ユーザーによる管理機能の確認
- 03変更系エンドポイントの認可検証
- 04確認済みアクセス制御不備の記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/access-control-testingを入力して読み込まれたか確認します。
同梱ファイルreferences/access-control-tests.md
詳細
アクセス制御のテスト（検出／悪用 — OWASP A01）
概要
すべてのオブジェクトとすべての操作について、サーバー側で「この呼び出し元に許可されているか」を検証していることを確認します。 アクセス制御の不備は、現実に最もよく見られ、最も影響の大きい脆弱性です。また、正常系のパスが完全に動作するため、見落としやすい脆弱性でもあります。
基本原則： 認証は「あなたが誰か」を証明し、認可は「あなたに何が許されているか」を証明します。 UI に表示されるものだけでなく、すべてのオブジェクトとすべての操作で、後者をテストしてください。
適用する場合／スキップする場合
- 適用する場合： アプリに認証、複数ユーザー、ロール、またはマルチテナントデータがある場合。制限すべきリソースや操作がある場合も該当します。（ほぼすべての実用的なアプリが対象です。）
- スキップする場合： アプリが完全に公開・匿名で、ユーザー別データや特権データがない場合 → N/A。
- N/A の場合： 「access-control-testing: N/A — no auth/multi-user surface」と報告して終了します。存在しないアクセス境界を作り出さないでください。
⚠️ 認可
自分が所有する、またはテストを許可されているアプリで作成したテストアカウントを使用してください。アカウントを 2 つ（A と B）、さらに管理者アカウントと低権限アカウントを 1 つずつ用意するのが最適です。
テストマトリクス（すべてのセルを実行）
| 読み取り | 書き込み／更新 | 削除 | 管理者操作 | |
|---|---|---|---|---|
| 別のユーザーとして（水平） | A が B のオブジェクトを読み取れるか？ | A が B のオブジェクトを編集できるか？ | A が B のオブジェクトを削除できるか？ | — |
| 低い権限として（垂直） | ユーザーが管理者用の読み取りを実行できるか？ | ユーザーが管理者用の書き込みを実行できるか？ | — | ユーザーが管理者用関数を呼び出せるか？ |
| 未認証 | トークンなし → データを取得できるか？ | トークンなし → 変更できるか？ | — | トークンなし → 管理者用操作を実行できるか？ |
いずれかのセルで成功した場合は、発見事項として報告します。
方法
- ユーザー A として正規のリクエストを取得します（すべての id、uuid、slug、ファイル名を記録します）。
- A のセッションを維持したまま、オブジェクト参照を B のリソースに差し替えます → IDOR/BOLA。
- 特権エンドポイントでセッションを差し替えます（トークンを削除する／低権限のトークンを使う）→ BFLA／垂直。
- 通常のアカウントで、非表示のルート（
/admin、/api/internal）へ直接アクセスします。 - マスアサインメント — UI からは送信されないフィールド（
role、isAdmin、userId、price）を追加します。 - すべてのメソッドを確認 —
GETは保護されていても、PUT／DELETE／PATCHの保護が漏れていることがあります。
具体的なリクエスト例とエッジケースについては、references/access-control-tests.md を参照してください。
クイックリファレンス — 脆弱性の種類
| 種類 | テスト |
|---|---|
| IDOR / BOLA | id／uuid／ファイル名を別ユーザーのものに変更します。相手のデータを取得できるか確認します。 |
| 水平権限昇格 | 同じ権限レベルの別ユーザーのリソースに対して操作します。 |
| 垂直権限昇格 | 低権限アカウントで管理者用の機能／データにアクセスします。 |
| BFLA | UI では保護されている管理者用エンドポイントを、誰でも直接呼び出せます。 |
| マルチテナントの破綻 | テナント A がテナント B のデータを読み取ります（org_id／tenant_id を差し替えます）。 |
| マスアサインメント | リクエストボディに特権フィールドを挿入します。 |
| 強制ブラウジング | リンクのない特権ルートを推測／列挙します。 |
出力
記録簿には、どのアカウントがどのエンドポイント／オブジェクトにアクセスしたか、差し替えたリクエストの内容、公開された情報、水平か垂直かを記録します。重大度はほぼ常に High 以上です。
引き継ぎ
稼働中のアプリで確認できた場合は、active-pentest で再現します。vulnerability-chaining で他の脆弱性と連鎖させ、security-hardening で修正します（デフォルト拒否、サーバー側でのチェック）。
よくある間違い
- 管理者としてしかテストしない — 脆弱性を見つけられません。必ず 低い権限 でテストしてください。
- 非表示またはリンクのないエンドポイントは安全だと信頼する — 列挙して直接呼び出してください。
GETだけを確認する — 被害が発生するのは変更操作です。- UUID は安全だと思い込む — UUID は漏えいし（レスポンス、ログ、リファラーなど）、IDOR の対象にもなります。
- 予測可能なパターンを見落とす：連番の id、base64 化された id、推測可能なファイル名。