1. 多層防御（Defense in Depth）: 単一の対策に依存しない
2. 最小権限の原則: 必要最小限のアクセス権のみ付与
3. デフォルト拒否: 明示的に許可されたもの以外は拒否
4. フェイルセキュア: エラー時は安全側に倒す
5. 入力は信頼しない: すべての外部入力を検証

- サーバーサイドで必ず検証（クライアントのみは不十分）
- 許可リスト方式（拒否リスト方式は漏れが生じやすい）
- 型チェック + 長さ制限 + 範囲チェック + 形式検証
- 文字エンコーディングの正規化

- 拡張子の許可リスト
- Content-Type の検証（拡張子だけでなくマジックバイトも確認）
- ファイルサイズ制限
- 保存先パスのサニタイズ（パストラバーサル防止）
- アップロード先はWebルート外に配置

原則:
- Access-Control-Allow-Origin に * は本番で使わない
- 許可するオリジンを明示的に列挙
- credentials 使用時は具体的なオリジンが必須
- preflight キャッシュ（Access-Control-Max-Age）を適切に設定

設定項目:
- Allow-Origin: 許可するオリジン
- Allow-Methods: 許可する HTTP メソッド
- Allow-Headers: 許可するリクエストヘッダー
- Expose-Headers: クライアントがアクセス可能なレスポンスヘッダー

対策の組み合わせ:
1. SameSite Cookie 属性（Lax or Strict）
2. CSRF トークン（フォーム送信）
3. Origin / Referer ヘッダーの検証
4. カスタムヘッダーの要求（API リクエスト）

方針:
- ロックファイルを必ずバージョン管理に含める
- 定期的な脆弱性スキャン（CI に組み込む）
- 依存パッケージは最小限に
- メジャーバージョンアップはテスト付きで行う
- セキュリティアドバイザリの監視

自動化:
- GitHub Dependabot / Renovate で自動更新
- npm audit / pip audit / govulncheck を CI に組み込み

原則:
- ソースコードにシークレットを含めない
- .env ファイルはバージョン管理に含めない（.env.example のみ）
- 環境変数 or シークレットマネージャーで管理
- ログにシークレットを出力しない
- 定期的なキーローテーション
- アクセスログの記録

検出:
- pre-commit フックでシークレットパターンを検出
- CI でのシークレットスキャン

記録すべきイベント:
- 認証の成功/失敗
- 認可の失敗（アクセス拒否）
- 入力バリデーション失敗
- 予期しないエラー
- 管理操作の実行

記録してはいけないもの:
- パスワード（平文/ハッシュ含む）
- トークン・セッションID
- 個人情報（マスキングする）
- クレジットカード番号

ログの設計:
- 構造化ログ（JSON 形式）
- タイムスタンプ（UTC）
- リクエスト ID での追跡
- ログレベルの適切な使い分け

原則:
- 内部エラーの詳細をクライアントに露出しない
- スタックトレースは本番で非表示
- 一般的なエラーメッセージを返す
- 詳細はサーバーログに記録
- fail-secure: エラー時は安全側に倒す

アンチパターン:
- ❌ "ユーザー名が見つかりません" → 攻撃者にユーザー存在を教える
- ✅ "認証情報が正しくありません" → 情報を限定