プロンプト ─ OWASP Top 10 基本対策の一括実装
# セキュリティ強化タスク：OWASP Top 10 基本対策
## 目的
このプロジェクトのWebアプリケーションに対し、OWASP Top 10に基づく
基本的なセキュリティ対策を実装してください。
## 作業手順（この順序で実行）
### 1. 現状分析
まず、プロジェクト全体を確認し、以下を報告してください：
- 使用フレームワーク・言語
- 認証方式の有無
- データベースの種類
- API エンドポイントの一覧
- 外部サービス連携の有無
### 2. 入力バリデーション＆サニタイズ
- 全フォーム入力にXSS対策を追加
- SQLインジェクション対策（プリペアドステートメント）
- パストラバーサル対策
- ファイルアップロードの型・サイズ検証
### 3. 認証・セッション管理
- パスワードはbcrypt等でハッシュ化されているか確認
- セッショントークンの安全な生成・管理
- ログイン試行回数制限の実装
- セッションタイムアウトの設定
### 4. セキュリティヘッダー
以下のHTTPヘッダーを設定：
- Content-Security-Policy
- X-Content-Type-Options: nosniff
- X-Frame-Options: DENY
- Strict-Transport-Security
- Referrer-Policy: strict-origin-when-cross-origin
### 5. シークレット管理
- ハードコードされたAPIキー・パスワードを検出
- .env ファイルへ移行
- .gitignore に .env が含まれているか確認
- 既にGit履歴にシークレットがある場合は警告
### 6. エラーハンドリング
- 本番環境でスタックトレースが表示されないことを確認
- ユーザー向けエラーメッセージに内部情報を含めない
- 適切なエラーログ出力の設定
### 7. レート制限
- 認証エンドポイントにレート制限を追加
- API全体に適切なレート制限を設定
## 出力形式
各カテゴリごとに以下を報告してください：
- ✅ 対策済み（変更不要）
- 🔧 修正実施（変更内容の説明）
- ⚠️ 要注意（手動確認が必要な項目）
- ❌ 対応不可（理由と代替案）
プロンプト ─ 自分のアプリに対するOWASP脅威分析
# OWASP Top 10 脅威分析レポート作成
## 目的
このプロジェクトのコードを分析し、OWASP Top 10 の各項目に対して
どの程度のリスクがあるかをレポートにまとめてください。
## 分析対象
プロジェクト内の全ソースコードを対象とする。
特に以下に注目：
- ユーザー入力を受け取る箇所
- データベースへのクエリ
- 認証・認可の処理
- ファイル操作
- 外部APIとの通信
- セッション管理
## レポート形式（各項目ごとに）
### A01: Broken Access Control（アクセス制御の不備）
- リスクレベル：高/中/低/該当なし
- 該当コード箇所：
- 具体的リスク：
- 推奨対策：
（A02〜A10まで同様の形式で）
## 追加で報告してほしいこと
- このアプリ固有のビジネスロジック脆弱性の可能性
- 優先的に対応すべきTop 3の脅威
- バイブコーディングで対応可能な範囲と、
専門家への相談を推奨する範囲の明確な区分
プロンプト ─ 脆弱性スキャン実行 & 自動修正
# セキュリティスキャン＆脆弱性修正
## フェーズ1：依存パッケージの脆弱性チェック
以下のコマンドを実行し、結果を報告してください：
### Node.js プロジェクトの場合
npm audit
### Python プロジェクトの場合
pip audit
検出された脆弱性について：
- Critical/High は即座に修正
- Medium は影響範囲を評価して修正
- Low は報告のみ（後日対応）
パッケージ更新で破壊的変更がある場合は、
更新前に影響範囲を報告してください。
## フェーズ2：静的コード解析
以下の観点でコード全体をスキャンしてください：
1. ハードコードされた認証情報・シークレット
2. 安全でない暗号化の使用（MD5, SHA1等）
3. 安全でないデシリアライゼーション
4. 未検証のリダイレクト
5. CSRF対策の欠如
6. 安全でないファイルアップロード処理
7. 過剰な権限付与
8. 未使用・放置された管理者エンドポイント
9. デバッグモードの本番有効化
10. ログへの機密情報出力
## フェーズ3：修正の実施
検出された脆弱性を以下の優先順位で修正：
1. 🔴 Critical ─ 即時修正（データ漏洩・RCEリスク）
2. 🟠 High ─ 当日中に修正
3. 🟡 Medium ─ 1週間以内に修正
4. 🟢 Low ─ 次回メンテナンスで対応
## 出力形式
### 診断サマリー
深刻度 | 件数 | 修正済み | 残件
### 各脆弱性の詳細
- 脆弱性名：
- 深刻度：Critical / High / Medium / Low
- 該当ファイル・行番号：
- リスク説明（技術者でなくても分かる言葉で）：
- 修正内容：
- 修正後の確認方法：
### 専門家への相談を推奨する項目
（バイブコーディングだけでは安全性を保証できない項目を明記）
要件定義書 ─ セキュリティ強化プロジェクト
========================================
セキュリティ強化 要件定義書
========================================
■ プロジェクト概要
─────────────────
目的：バイブコーディングで開発したWebアプリケーションの
セキュリティ品質を実用水準まで引き上げる
対象：[ここにアプリ名・URLを記入]
種別：[HP / Webアプリ / SaaS から選択]
技術スタック：[使用言語・フレームワークを記入]
■ セキュリティ要件（優先度順）
─────────────────────────────
【P0：必須 ─ 未対応ならリリース不可】
SEC-001: 入力バリデーション
- 全ユーザー入力にサーバーサイドバリデーションを実装
- XSS対策（出力エスケープ）を全出力箇所に適用
- SQLインジェクション対策（プリペアドステートメント）
- 受入基準：OWASP ZAPスキャンでHigh検出ゼロ
SEC-002: 認証・認可
- パスワードはbcrypt/argon2でハッシュ化
- セッション管理はフレームワーク標準機能を使用
- 全APIエンドポイントに認可チェックを実装
- ログイン試行制限（5回/15分）
- 受入基準：未認証でのAPIアクセスが全てブロック
SEC-003: シークレット管理
- ソースコード内にハードコードされた秘密情報ゼロ
- 全シークレットは環境変数で管理
- .env は .gitignore に含める
- Git履歴にシークレットが残っていないこと
- 受入基準：git logの全履歴検索で秘密情報ゼロ
SEC-004: HTTPS & セキュリティヘッダー
- 全通信をHTTPSに強制
- CSP / HSTS / X-Frame-Options 等を設定
- 受入基準：securityheaders.com で A 以上
【P1：重要 ─ リリース後1週間以内に対応】
SEC-005: エラーハンドリング
- 本番環境でスタックトレース非表示
- ユーザー向けエラーに内部情報を含めない
SEC-006: レート制限
- 認証系API：10回/分
- 一般API：100回/分
- ブルートフォース対策としてアカウントロック
SEC-007: 依存パッケージ管理
- npm audit / pip audit でCritical/Highゼロ
- Dependabot（またはRenovate）の有効化
【P2：推奨 ─ 1ヶ月以内に対応】
SEC-008: ログ・監視
- 認証イベントのログ出力
- 不正アクセス試行の検知
SEC-009: CSRF対策
- 状態変更APIにCSRFトークンを実装
SEC-010: ファイルアップロード
- ファイル種別・サイズの制限
- アップロード先の分離
■ 対象外（専門家への委託を推奨）
─────────────────────────────
- ペネトレーションテスト
- 暗号化設計のレビュー
- インフラ・ネットワーク層の診断
- 法的コンプライアンス（個人情報保護法、GDPR等）
- ビジネスロジック固有の脆弱性分析
■ 完了基準
─────────
□ P0項目が全て受入基準を満たすこと
□ npm audit / pip audit でHigh以上がゼロ
□ OWASP ZAP自動スキャンでHigh検出ゼロ
□ securityheaders.com で A 以上
□ 専門家委託が必要な項目リストが作成されていること
■ スケジュール
─────────────
Phase 1（P0対応）：1〜2日
Phase 2（P1対応）：3〜5日
Phase 3（P2対応）：1〜2週間
Phase 4（専門家診断）：予算確保後