| name | security-mind |
| description | 認証・認可・テナント境界・秘密情報・外部入力・キャッシュ・本番/共有環境を扱う実装、レビュー、セキュリティ監査で必ず使う skill。権限チェック、マルチテナント、トークン、資格情報、脆弱性調査に関わるときのほか、「セキュリティを確認して」と依頼されたときの固定観点としても使う。 |
Security Mind
「悪意しかない利用者」と「うっかり事故」の両方を前提に、境界で守るための skill。
quality-mind の「悪意ある異常系」を、設計・運用側から補完する。
境界は信頼できる情報から再導出する
- テナント ID・ユーザー ID・ロール・所有権・金額・状態は、クライアント入力(body、query、cookie、hidden field、localStorage)を信頼せず、サーバー側のセッション・認証コンテキストから再導出する。
- クライアントから受け取ったテナント ID は、認証済みユーザーの所属と必ず突合する。UI で選択肢を絞っていても、サーバー側の検証を省かない。
- この強制は UI やリゾルバ層ではなく、リポジトリ層・インフラ層に置く(呼び出し忘れが構造的に起きない場所)。
- キャッシュのキーにテナント・ユーザーのスコープを含める。スコープ漏れは他テナントへのデータ混入になる。
- テナント境界に触れる変更にはクロステナントのテストを追加する。
固定監査観点(「セキュリティ確認して」と言われたら最低限これを見る)
- 認可漏れ・IDOR: 他人の ID・他テナントの ID を指定した直接参照。認証なしで到達できるエンドポイント・直リンク。
- XSS / CSRF / SSRF / インジェクション(SQL・NoSQL・コマンド)・パストラバーサル・オープンリダイレクト。
- 鍵・トークンの漏洩: リポジトリ内の平文資格情報、公開ビルドに含まれる secret、ログへの出力。
- 悪用可能な導線: メール送信の踏み台、レート制限のない認証・送信系 API、過大 payload。
- トークン検証の手抜き: JWT を split して手動デコードするなど署名検証を通らない実装。
- 情報露出: エラーメッセージ・API レスポンスに内部情報や権限外フィールドが混ざっていないか。アカウントの存在が推測できるレスポンス差(パスワードリセット等)を返していないか。
認証・検証の水準を下げない
- テスト・E2E の都合で認証バイパスフラグや「テストモード」を新設しない。検証は正規のログイン導線で行う(そのための E2E 基盤・テストアカウント)。
- 開発・staging 環境の認証(Basic 認証等)を勝手に外さない。外れているのを見つけたら戻す。
- reCAPTCHA・レート制限などの緩和設定は環境変数で環境限定にし、本番に漏れない構造にする。
本番・共有環境の扱い
- 本番・staging・共有 DB・クラウドコンソールは、明示指示がない限り read-only。調査はよいが操作はしない。
- 対象が本番かどうかを URL・環境変数・設定から必ず識別してから触る。判別できないものは本番として扱う。
- 破壊的操作(reset、migrate、seed、prune、削除)は、ユーザーがその操作を明示的に依頼した場合のみ。
秘密情報の扱い
- トークン・パスワード・接続文字列をコード・README・サンプル・テスト・コミット・応答に平文で書かない。secrets 管理(環境変数、Secrets Manager 等)へ外出しする。
- 画面・ログに出すときはマスキングする(末尾数桁のみ等)。
- ローカル検証用のテスト資格情報は、プロジェクトが定めた場所(AGENTS.md / docs)を参照し、新しい場所に増殖させない。
リスク受容の記録
- 指摘を「対応しない/保留」と判断した場合は、握りつぶさずに記録する: コード上に根拠コメント、プロジェクトのセキュリティ文書(SECURITY.md 等)に受容理由と再評価条件。
- スキャナ(依存監査、SAST、secret scan)の除外設定には必ず理由を残す。
完了前
- 変更が権限・境界・秘密情報に触れた場合、悪用シナリオを 1 つ以上実際に試す(他人の ID、権限のないロール、直接 URL)。
- 「防いだこと」だけでなく「防げていない既知のリスク」も報告に含める。