security-best-practices

セキュリティのベストプラクティス

このスキルは、不足しているセキュリティ層を1つ特定し、範囲を限定した強化ブリーフにまとめる場合に使用します。

目的は、OWASPの膨大なリスト、ミドルウェアのカタログ、スキャナーの羅列を提示することではありません。 目的は次のとおりです。

1. 対象範囲とリスクを整理する
2. 主要な強化モードを1つ選ぶ
3. 信頼できる最小限の初回対応を推奨する
4. 検証手順を明示する
5. 関連する作業を適切に振り分ける

まず、次の補足ドキュメントを読んでください。

• references/modes-and-boundaries.md
• references/mode-packets-and-route-outs.md
• references/hardening-review-checklist.md
• references/verification-ladder.md

このスキルを使用する場合

• チームから「セキュリティを強化して」と言われたものの、不足しているセキュリティ層がまだ明確でない
• Webアプリ、API、マーケティングサイトのフロー、管理パネル、ゲームサービスの対象範囲について、リリースや移行の前に強化が必要である
• 主な問題がCSP／ヘッダー、Cookie／CSRF、不正利用対策、検証／安全でない実行、シークレットの取り扱い、または検証の弱さのどれなのか判断する必要がある
• スキャナーの検出結果、OWASP関連の依頼、またはリリースレビューのメモを、優先順位を付けた1つの強化ブリーフにまとめる必要がある
• 現在のスタックにはすでにいくつかの対策があるものの、信頼性が低く、次の検証手順が明確でない

このスキルを使用しない場合

• 主な作業が、認証ベンダー、セッションアーキテクチャ、組織／メンバーモデル、またはエンタープライズSSOの方針を選ぶことである → authentication-setup
• 主な作業が、セキュリティ対策を組み込む前のAPI契約／インターフェース設計である → api-design
• 主な作業が、スキーマ制約、トークンテーブル、インデックス、または移行の安全性である → database-schema-design
• 主な作業が、バックエンドの回帰テストや認証／セキュリティテストの実装である → backend-testing
• 主な作業が、コード内の特定の脆弱性の修正や具体的な差分のレビューである → debugging または code-review
• 主な作業が、シークレット注入の仕組み、ツールチェーンのブートストラップ、または環境の構成である → system-environment-setup / environment-setup
• 主な作業が、クラウドIAM、VPC／ネットワーク、またはより広範なインフラストラクチャのセキュリティである → このアプリケーション強化の基点ではなく、インフラストラクチャ専用のスキルを使用する

手順

Step 1: ツールを挙げる前に強化作業の範囲を整理する

まず、最低限必要な事実をまとめます。

security_intake:
  surface: frontend | backend-api | fullstack | edge-worker | marketing-site | game-service-web | mixed | unknown
  workflow_type: new-build | hardening-pass | audit-review | launch-readiness | incident-follow-up | migration
  auth_session_model: cookie-session | bearer-token | mixed | unknown
  current_controls:
    - headers-csp
    - csrf
    - rate-limit
    - validation
    - secret-store
    - scanning
    - none
  primary_risk: xss-browser-policy | csrf-session | abuse-automation | injection-unsafe-execution | secret-exposure | verification-gap | mixed | unknown
  environments: local | preview | staging | prod | multi-env | unknown
  ownership: app-team | platform | security | shared | unknown

ルール：「Helmetをインストールする」「CORSを有効にする」「WAFルールを追加するだけ」といった提案から始めてはいけません。 まず、不足している層を特定してください。

Step 2: 主要な強化モードを1つだけ選ぶ

references/mode-packets-and-route-outs.md のルーターを使用してください。

主要モード：

1. browser-perimeter-policy
2. session-cookie-csrf
3. abuse-controls
4. validation-unsafe-execution
5. secrets-runtime-config
6. review-verification

リスクが最も高い不足レイヤーを主要モードに選びます。 それ以外は、対等な共同担当ではなく、後続作業として列挙します。

Step 3: 不変条件を明示する

次のルールは、どの回答でも維持してください。

• CORS、認証、CSRF、レート制限、検証、シークレットは、同じルートに関わる場合でも、それぞれ別の懸念事項です
• ブラウザポリシーの作業では、段階的なロールアウトやレポート専用の検証が必要になる場合があります
• フレームワークのデフォルト設定は役立ちますが、完全にカバーされている証明にはなりません
• シークレットのスキャンは検出であり、保存やローテーションのポリシーではありません
• WAFとレート制限は補完的な境界対策であり、アプリケーション層の修正を完全に代替するものではありません
• 推奨事項には、それに対応する検証手順が必ず必要です

Step 4: セキュリティ強化ブリーフを作成する

次の構成で返します。

# Security Hardening Brief

## Scope
- Surface: ...
- Workflow type: ...
- Primary mode: ...
- Confidence: high | medium | low

## Current control state
- Controls already present: ...
- Missing or untrusted controls: ...

## Highest-risk gaps
1. ...
2. ...
3. ...

## Recommended first slice
1. ...
2. ...
3. ...

## Verification plan
- Manual review: ...
- Static/policy checks: ...
- Dynamic/runtime verification: ...
- Operational evidence: ...

## Ownership and route-outs
- Primary owner: ...
- Adjacent skills / teams: ...

Step 5: 巨大なチェックリストではなく、モードパケットを使う

references/mode-packets-and-route-outs.mdからパケットを取得します。

モードのルール：

• browser-perimeter-policy → ヘッダー、CSP、フレーミング、セキュアな通信、レポート専用での段階的導入、プロキシ/CDN とアプリのどちらが管理するか
• session-cookie-csrf → Cookie フラグ、状態を変更するブラウザルート、オリジンに関する前提、Web と API/モバイルの違い
• abuse-controls → ログイン／リセット／フォーム／高コストなエンドポイントの保護、ルート単位と全体の制限、ボットの例外、モニタリング
• validation-unsafe-execution → 信頼境界、検証／エンコード、アップロード、SSRF、コマンド実行、危険なパターン
• secrets-runtime-config → シークレットと設定の分離、保存／注入、最小権限、ローテーション／失効、クライアントバンドルへの混入防止
• review-verification → 指摘事項の分類、維持／修正／追加／延期の判断、最小限の検証手順、責任の所在の明確化

Step 6: 隣接する作業は明示的に振り分ける

問題が境界をまたぐ場合は、次の振り分け先を使います。

実際の作業が...	振り分け先...
認証ベンダーの選定、エンタープライズ SSO、組織／メンバーモデル、ホスト型認証とネイティブ認証の選択	authentication-setup
API 認証／エラー／Webhook の契約設計	api-design
スキーマ制約、トークンテーブル、マイグレーション／データモデルの安全性	database-schema-design
バックエンドのセキュリティ回帰テストや CI ゲート	backend-testing
具体的な脆弱性の修正やリスクのある差分のレビュー	debugging / code-review
環境のブートストラップやシークレット注入の配線	system-environment-setup / environment-setup

出力への期待

このスキルによる優れた回答では、次の点を満たす必要があります。

1. 主に欠けているレイヤーを特定する。
2. 範囲を限定した最初の一手を1つ推奨する。
3. 検証手順を明示する。
4. 1つのライブラリ／ツールですべて解決するかのように装わない。
5. 隣接する作業は取り込まず、別の作業先へ振り分ける。

例

例 1: Cookie ベースの管理アプリの強化

入力

当社の Next.js 管理アプリでは Cookie セッションを使っています。POST ルートに CSRF 保護がなく、ステージング環境と本番環境で Cookie フラグに差異があります。

出力の方向性

• session-cookie-csrfを選ぶ
• CSRF 保護が必要なルートと、修正すべき Cookie フラグを特定する
• ステージング環境と本番環境の差異を検証する手順を含める
• 認証ベンダーの選定の話にすり替えない

例 2: マーケティングサイトのフォームへの不正利用

入力

ハニーポットと CAPTCHA を追加した後も、登録フォームとデモ申請フォームにスパムが届き続けています。

出力の方向性

• abuse-controlsを選ぶ
• フォームへの不正利用対策と、汎用的な CSP／ヘッダー作業を分ける
• ルートに応じたスロットリングや自動化対策と、モニタリングを推奨する
• より広範なインフラ作業やベンダーのルール作成は、中心となる依頼の範囲外にする

例 3: ゲームサービスのシークレット漏えいリスク

入力

ゲームのコンパニオンサイトとバックエンド API があります。パートナーキーや管理者トークンが CI ログに混入したり、クライアントバンドルに含まれたりしていないか心配です。

出力の方向性

• secrets-runtime-configを選ぶ
• シークレットの検出と、保存／ローテーション／注入のポリシーを分ける
• 必要に応じて、環境のブートストラップに関する詳細を別の作業先へ振り分ける
• 失効／ローテーションの検証要件を含める

例 4: 責任の所在が曖昧なスキャナーのレポート

入力

スキャナーは CSP が弱く、ヘッダーが不足していると指摘していますが、アプリにはすでにミドルウェアが追加されており、その結果を誰も信頼していません。

出力の方向性

• review-verificationまたはbrowser-perimeter-policyを選ぶ
• ミドルウェアの導入と、段階的な導入を証明する作業を分ける
• 段階的な検証、レポート専用での検証、またはスキャナーと実行環境の間の引き継ぎを推奨する

ベストプラクティス

1. ツールを挙げる前に、欠けているセキュリティレイヤーを選ぶ。
2. ブラウザポリシー、セッションの安全性、不正利用対策、検証、シークレット、検証プロセスを分けて扱う。
3. すべての推奨事項に、効果を証明する証拠を対応付ける。
4. フレームワークのデフォルト設定やスキャナーは、最終的な答えではなく入力として扱う。
5. 膨大なコンプライアンス項目の羅列より、範囲を限定したセキュリティ強化の依頼を優先する。

参考資料

• OWASP アプリケーションセキュリティ検証標準
• OWASP チートシートシリーズ
• MDN：コンテンツセキュリティポリシー
• MDN：Set-Cookie
• OWASP ZAP
• GitHub CodeQL コードスキャン