Test Owasp Checklist

A02: 暗号化の失敗

• セッション Cookie 属性（httpOnly, Secure, SameSite）
• 機密データ（パスワード、トークン、個人情報）のログ出力
• API レスポンスに不要な機密フィールドが含まれていないか

A03: インジェクション

• XSS（Stored / Reflected）— ユーザー入力が HTML に反映される箇所
• SQL インジェクション — ORM バイパスや raw query 使用箇所
• NoSQL インジェクション — JSON / オブジェクト操作箇所
• コマンドインジェクション — 外部プロセス呼び出し箇所
• パストラバーサル — ファイルパス操作箇所

A04: 安全でない設計

• レート制限 — ログイン試行、API 呼び出しの制限
• ビジネスロジック悪用 — 負数・ゼロ値による金額操作、数量操作
• レースコンディション（TOCTOU）— 同時リクエストによる二重作成・二重削除
• マスアサインメント — 入力に余計なフィールド（role, storeId 等）を含めた場合の挙動

A05: セキュリティ設定ミス

• エラーメッセージの情報漏洩 — スタックトレース、内部 ID、DB 構造の露出
• 不要な HTTP ヘッダー（Server, X-Powered-By）の露出
• デバッグモード・開発設定の本番残存
• CORS の設定不備

A07: 認証の失敗

• ブルートフォース耐性（ログイン試行制限）
• セッション固定攻撃 — ログイン後のセッション ID 再生成
• セッション無効化 — ログアウト・パスワード変更後の全セッション無効化
• パスワードリセットフローの安全性（トークン有効期限、再利用防止）

A08: データの完全性の不備

• CSRF — Server Actions / API の保護が有効か
• マスアサインメント — 許可されたフィールドのみ更新されるか
• 署名検証 — Webhook 等の外部入力に対する署名検証

テストマトリクス

各 Action / API に対して以下のマトリクスを適用する:

ファイル配置パターン

セキュリティテストは専用ディレクトリにカテゴリ別で配置すると見通しが良い:

__tests__/security/
  access-control.test.ts    # A01: 認証・認可・IDOR
  injection.test.ts         # A03: XSS・SQLi 等
  data-protection.test.ts   # A02 + A05: 機密データ・エラー情報漏洩
  business-logic.test.ts    # A04: レースコンディション・マスアサインメント
  session.test.ts           # A07 + A08: セッション管理・CSRF

ディレクトリ構成は既存パターンに合わせる。

対象の優先順

1. 書き込み系（create / update / delete）— データ改ざんリスク
2. 機密データ系（個人情報、医療情報）— 漏洩リスク
3. 権限制御系（管理操作、設定変更）— 権限昇格リスク
4. 読み取り系（list / get）— データ漏洩リスク

既存テストとの重複回避

• ユニットテストでカバーされる「正常系・バリデーション」は対象外
• セキュリティ境界の突破テスト（拒否されるべき操作が拒否されること）に集中する
• 同じ Action でも観点が違えば別テストファイルに配置

プロジェクト固有設定

.claude/config/security.yml にプロジェクト固有のチェック項目があれば、それを優先する。