auth-review について
Auth Review は、コードベースの認証と認可を監査する、フレームワーク非依存の読み取り専用スキルです。エンドポイント一覧、認可マトリクス、根拠付きの指摘を含むトリアージレポートを作成します。
主な機能
- 01外部・半信頼エントリーポイントの列挙
- 02エンドポイント認可マトリクスの作成
- 03脆弱性カテゴリに沿ったコード確認
- 04指摘を含む日付入りレポートの作成
- 05静的な読み取り専用レビュー
活用シーン
- 01リリース前のアクセス制御レビュー
- 02インシデント後の認証調査
- 03IDOR や認可の欠落のコードベース確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/auth-reviewを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/authz-matrix.mdenumeration.mdreport-template.mdvulnerability-catalog.md詳細
認証レビュー
現在のコードベースにおける認証と認可について、静的かつ読み取り専用のセキュリティレビューを実施します。フレームワークやベンダーに依存しません。出力先：問題報告やプルリクエストとして提出できる指摘をまとめたトリアージレポートを ./auth-review/ に作成します。
使用するタイミング
- ユーザーが
/auth-reviewを実行したとき。 - 「認証を監査して」「認可のバグを見つけて」「アクセス制御をレビューして」「IDOR を確認して」「ID セキュリティレビュー」などの依頼があったとき。
- リリース前の強化、または ID に焦点を当てたインシデント後のフォレンジックコードレビュー。
ワークフロー
次のフェーズを順番に実行します。先に進んではいけません。
フェーズ 1 — すべてのエントリーポイントを列挙する
外部または半信頼の呼び出し元から到達可能なコードパスをすべて特定します。網羅的なパターンについては references/enumeration.md を参照してください。単一のリポジトリに HTTP、GraphQL、WebSocket、キューコンシューマー、サーバーレスハンドラー、管理者向け CLI が混在していることもよくあります。すべて列挙してください。
成果物： method、path / trigger、handler (file:line)、auth required? (y/n/unknown)、roles or scopes、notes を含むエンドポイントインベントリテーブル。
先に進む前に、ルーターファイル、OpenAPI 仕様、GraphQL スキーマと照合してください。
フェーズ 2 — 認可マトリクスを作成する
各エンドポイントについて、誰がアクセスできるべきか、コードでは実際に何を強制しているかを明らかにします。慣例から想定されるプリンシパルを推定し、ギャップを分類するには references/authz-matrix.md を使用してください。
成果物： endpoint、expected principal、enforced check (file:line)、gap を含む認可マトリクステーブル。
フェーズ 3 — 脆弱性カタログを適用する
references/vulnerability-catalog.md の各カテゴリを順に確認します。検出ヒューリスティックを実行した後、該当ファイルを読んで確認してください。grep の一致だけを根拠に指摘してはいけません。
チェックが存在しないと判断する前に、上流のミドルウェア、デコレーター、ガード、フィルター、インターセプター、フレームワークのデフォルト、リバースプロキシによって強制されていないことを確認してください。指摘ごとに、少なくとも 1 つの具体的な呼び出し元のパスを最初から最後まで追跡してください。チェックが条件付きの場合は、その条件と、攻撃者がそれを制御できるかどうかを記録してください。
フェーズ 4 — レポートを作成する
./auth-review/ が存在しない場合は作成します。./auth-review/report-YYYY-MM-DD.md に書き込みます（本日の日付のファイルがすでに存在する場合は -HHMM を追加します）。references/report-template.md の構成を使用してください。
レポートには次の内容を含めてください。
- 重要度別の件数を含むエグゼクティブサマリー。
- エンドポイントインベントリ（フェーズ 1）。
- 認可マトリクス（フェーズ 2）。
- 指摘事項 — それぞれにタイトル、重要度、CWE、
file:line、証拠、悪用の根拠、修正方法を記載。 - 「提出する課題」 — 指摘事項を、そのまま貼り付けて提出できる課題本文として整形したもの。
- メンテナーが回答する必要のある未解決の質問。
作成後、重要度別の件数をユーザーに要約し、ファイルパスを示してください。課題やプルリクエストは作成しないでください。
重要度の基準
| レベル | 意味 |
|---|---|
| High | 認証されていない攻撃者、または低権限の攻撃者が悪用でき、アカウントの乗っ取り、データ侵害、権限昇格、テナント間のアクセスにつながる。 |
| Medium | 特定の条件が必要、影響が部分的、または多層防御に不備がある。 |
| Low | 強化に関する推奨事項。軽微な情報漏えい、またはベストプラクティスの欠如。 |
CWE ID（例：CWE-287、CWE-639、CWE-862、CWE-863）を必ず含めてください。references/vulnerability-catalog.md に記載された識別子を使用し、ID を作り出してはいけません。
禁止事項
- ソースコードを変更しないでください。このスキルは読み取り専用です。
- アプリケーションを実行したり、ネットワークプローブを実施したり、外部へのリクエストを送信したりしないでください。
file.ext:line形式の参照と証拠となるスニペットを示さずに、問題を報告しないでください。- 上流のミドルウェア、ガード、デコレーター、プロキシによってチェックが適用されていないことを確認する前に、チェックの欠如を指摘しないでください。
- CWE ID、CVSS スコア、フレームワークの動作を捏造しないでください。確信が持てない場合は、問題に「未確認」と明記し、「未解決の質問」に移してください。
- レポートにシークレット、トークン、秘密鍵、実際のユーザーデータを含めないでください。
[REDACTED]に置き換えてください。 - ユーザーから依頼されない限り、レポートを git にコミットしないでください。
- GitHub の issue や PR を直接作成しないでください。issue にそのまま使える文章を出力し、ユーザー自身に投稿してもらってください。
- バグを1つ見つけただけで作業を終えないでください。すべてを列挙してから報告してください。
- コードそのものよりも、コードのコメントやドキュメントを信用しないでください。「管理者のみ」と書かれたコメントは、セキュリティ対策ではありません。
参考資料
references/enumeration.md— HTTP、GraphQL、WebSocket、RPC、サーバーレス、バックグラウンドの各スタックにおけるエントリーポイントのパターン。references/vulnerability-catalog.md— 検出ヒューリスティクス、CWE ID、修正方法を含む脆弱性の分類一覧。references/authz-matrix.md— マトリクスのスキーマと、想定されるプリンシパルの推定ルール。references/report-template.md— レポートの正確な構成と issue 本文の形式。