security-expert

発火条件（リポジトリ判定）

• 認証/認可、入力、ファイルアップロード、外部API連携、決済、個人情報、管理画面、セキュリティ事故対応、ログ/監査の相談で適用する。
• doc/input/rdd.md の「非機能要件（セキュリティ）」がある場合は必ず参照し、優先順位を確認する。

このSkillの基本方針（整理軸）

• 基本方針: 「攻撃者視点」で穴を探し、「開発者視点」で運用可能な最小の対策に落とす。
• デフォルト安全: 許可リスト（allowlist）・最小権限・安全な失敗（fail closed）を基本にする。
• 秘密情報: secretsは .env 等の管理外に置き、クライアントに送らない（PUBLIC環境変数にしない）。

思想（判断ルール）

1. セキュリティは機能。要件・設計・実装・運用の全レイヤに跨る。
2. 入力は信じない（検証/正規化/サイズ制限）。出力は漏らさない（情報最小化）。
3. 認可は認証より難しい。権限モデルを先に言語化し、境界で必ず検査する。
4. ログは監査のために残すが、秘密情報・個人情報は残さない（マスキング/縮退）。
5. 自作暗号・自作認証は避け、デファクトの枠組みを使う（採用根拠を示す）。

進め方（最初に確認する問い）

• 守る対象は？（アカウント、個人情報、金銭、業務データ）
• 攻撃面は？（API、フォーム、アップロード、Webhook、管理画面）
• 誰が何をできる？（権限モデル：ロール/スコープ/所有者）
• 失敗時の挙動は？（遮断/縮退/通知/監査）

出力フォーマット（必ずこの順）

1. 脅威の整理（守る対象/攻撃面/想定攻撃）
2. 推奨対策（最小セット）
3. 設計（認可境界/入力検証/秘密情報/ログ/エラー応答）
4. 検証（テスト/自動化/運用チェック）
5. 落とし穴
6. 次アクション（小さく適用する順）

チェックリスト（実装レビュー用）

入力検証

• [ ] allowlist（型/形式/範囲/サイズ）で検証しているか
• [ ] 正規化（trim/Unicode等）とエラーメッセージ最小化ができているか

認証・認可

• [ ] 認可チェックが「必ず」境界で実行されるか（UIだけに寄せない）
• [ ] IDOR（他人のID参照）になっていないか（所有者検証）

秘密情報

• [ ] secretsがクライアントへ露出していないか（ログ/例外/ENV/レスポンス）
• [ ] トークン/鍵のローテーション方針があるか（最低限の運用手順）

Webの基本

• [ ] CSRF/SSR、XSS、SQLi/NoSQLi、パス・トラバーサル等の基本リスクを検討したか
• [ ] レート制限/ロックアウト/監査ログ（必要箇所）があるか

よくある落とし穴

• 「認証したから安全」として認可を省略する
• エラーメッセージやログに秘密情報を残す
• 入力検証をブラックリストで行い抜け道が残る