security-protocol

セキュリティプロトコル

概要

セキュリティは後から付け加える段階ではありません。コードの一行一行が、セキュリティ上の判断です。

基本原則： 信頼境界の外から来たデータを決して信頼しないでください。境界を越えるたびに検証します。

例外なし。回避策なし。近道なし。

最優先の指針

NO EXTERNAL DATA REACHES A SYSTEM CALL, QUERY, OR OUTPUT WITHOUT VALIDATION AND SANITIZATION

データが信頼境界を越えるときは、使用する前に必ず検証します。これは絶対です。

使用する場面

次のコードを書く場合は必須です：

• ユーザー入力（フォーム、URL、ヘッダー、アップロードファイル）を受け付ける
• データベースクエリを構築する
• ユーザーが提供したコンテンツをレンダリングする
• 認証または認可を管理する
• シークレットや認証情報を扱う
• 外部 API を呼び出す
• ファイルパスを操作する
• システムコマンドを実行する
• HTTP レスポンスヘッダーを設定する
• ファイルのアップロードを処理する

これは任意ではありません。 セキュリティ意識は開発に組み込むものであり、開発後に適用するものではありません。

エントリープロトコル

BEFORE shipping ANY code that handles external data:

1. IDENTIFY: Where does data enter the system? (Trust boundary)
2. VALIDATE: Is input validated at the boundary?
3. SANITIZE: Is output encoded for its target context?
4. AUTHORIZE: Is access control verified before the action?
5. PROTECT: Are secrets, tokens, and keys managed safely?

Omit any step = vulnerability shipped

OWASP Top 10 簡易ガイド

A01：アクセス制御の不備

すべてのエンドポイントで、次の点を確認する必要があります：このユーザーは、このリソースに対して、この操作を実行できますか？

# VULNERABLE: Checks authentication but not authorization
GET /api/accounts/456/profile  # User 123 views user 456's private data

# SECURE: Verify resource ownership
if resource.owner_id != authenticated_user.id:
    return 403 Forbidden

検証項目	方法
認証	ユーザーは本人だと主張する人物本人ですか？
認可	このユーザーにこの操作を実行する権限がありますか？
リソースの所有権	このユーザーはこの特定のリソースを所有していますか？
ロールの適用	サーバー側でロールを確認します。クライアントが提供するロールの申告を決して信頼しないでください

基本姿勢：拒否です。 アクセスを許可する明示的なルールがなければ、アクセスは拒否されます。

A02：暗号化の失敗

必須の実践	禁止される実践
パスワードのハッシュ化には bcrypt/scrypt/argon2 を使用する	パスワードに MD5、SHA1、SHA256 を使用する
常に TLS（HTTPS）を使用する	機密情報を扱う際に HTTP を使用する
トークンには暗号学的に安全な RNG を使用する	セキュリティトークンに Math.random() を使用する
保存データの機密情報を暗号化する	機密情報を平文で保存する
実績のある暗号ライブラリを使用する	独自の暗号方式を実装する

A03：インジェクション

外部入力をクエリ、コマンド、テンプレートに決して連結しないでください。

インジェクションの種類	防止策
SQL インジェクション	パラメーター化クエリ／プリペアドステートメントを使用します。必ず実施してください。
NoSQL インジェクション	入力の型を確認し、ODM のクエリビルダーを使用します
コマンドインジェクション	シェル実行を避けます。避けられない場合は、引数を許可リストで制限し、文字列を決して埋め込まないでください
LDAP インジェクション	特殊文字をエスケープし、パラメーター化クエリを使用します
テンプレートインジェクション	自動エスケープ機能を備えたテンプレートエンジンを使用します

-- VULNERABLE: String concatenation
SELECT * FROM users WHERE email = '" + userInput + "'

-- SECURE: Parameterized query
SELECT * FROM users WHERE email = $1

これは譲れない要件です。クエリで文字列連結が許容される状況はありません。

A04：安全でない設計

• 認証エンドポイントにレート制限を適用する
• アカウント作成に CAPTCHA またはプルーフ・オブ・ワークを使用する
• ビジネスロジックの制約をサーバー側で検証する（クライアント側だけで検証しない）
• 想定される使い方だけでなく、悪用のシナリオも考慮して設計する

A05：セキュリティ設定の不備

確認項目	対応
デフォルトの認証情報	デプロイ前にすべてのデフォルト値を変更する
デバッグ機能	本番環境ではデバッグモード、管理コンソール、詳細なエラーを無効にする
エラーの詳細度	スタックトレース、SQL エラー、内部パスをユーザーに決して公開しない
ディレクトリ一覧	すべての Web サーバーで無効にする
セキュリティヘッダー	設定する（「セキュリティヘッダー」のセクションを参照）
CORS ポリシー	特定のオリジンに制限する。認証情報を含むリクエストでは決して * を使わない

A06：脆弱なコンポーネント

BEFORE adding any dependency:

1. Is it actively maintained? (Last commit within 6 months)
2. Are known vulnerabilities published? (npm audit, snyk, dependabot)
3. Is it widely adopted? (Download counts and stars are signals, not guarantees)
4. Is it actually necessary? (Do not add a dependency for a single utility function)

npm audit / pip audit / cargo audit を定期的に実行します。重大および高リスクの検出結果には、直ちに対処してください。

A07：認証の失敗

要件	実装
パスワードの保存	一意のソルトを使用した bcrypt/scrypt/argon2
セッショントークン	暗号学的に安全な乱数を使用し、httpOnly、secure、sameSite フラグを設定
ブルートフォース対策	5～10 回連続で失敗したらアカウントをロック
多要素認証	機密性の高いアプリケーションでは、最低限 TOTP をサポート
パスワードポリシー	最低 8 文字。漏えいデータベースと照合
セッションのライフサイクル	セッションを期限切れにし、パスワード変更時に無効化

A08：データ完全性の失敗

• ソフトウェアの更新と CI/CD パイプラインの完全性を検証します
• 署名付きアーティファクトとチェックサムを使用します
• 信頼できないデータを自動的にデシリアライズしてはいけません（ユーザー入力に対する eval() や pickle.loads() の使用は禁止）

A09：ロギングと監視の失敗

ログに記録する	絶対にログに記録しない
認証の試行（成功と失敗）	パスワードや認証トークン
認可の拒否	クレジットカード番号全体
入力検証の失敗	目的のない個人識別情報
システムエラー	暗号化キーやシークレット

A10：サーバーサイドリクエストフォージェリ（SSRF）

• サーバーサイドリクエストの前に URL を検証し、許可リストと照合します
• サーバーサイドでのフェッチに使用する URL をユーザーが制御できるようにしてはいけません
• 内部ネットワーク（169.254.x.x、10.x.x.x、127.x.x.x、192.168.x.x）へのリクエストをブロックします

セキュリティヘッダー

すべての HTTP レスポンスに次の内容を設定します。

Content-Security-Policy: default-src 'self'; script-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

制限を厳しく設定した状態から始め、特定の要件がある場合に限り緩和します。

シークレットの管理

NEVER:
- Embed secrets in source code
- Commit .env files to version control
- Write secrets to log output
- Transmit secrets in URL query parameters
- Store secrets in client-side code

ALWAYS:
- Use environment variables or dedicated secret managers
- Add .env to .gitignore BEFORE the first commit
- Rotate secrets on a defined schedule
- Use distinct secrets per environment
- Audit secret access

入力検証チェックリスト

すべての入力フィールドについて、次を確認します。

• 型を検証する（文字列、数値、メールアドレス、URL）
• 長さを制限する（最小値と最大値）
• 形式を検証する（構造化データには正規表現を使用）
• 範囲を確認する（数値、日付）
• 可能な場合は許可リストと照合する（列挙値、既知のオプション）
• 出力コンテキストに合わせてサニタイズする（HTML、SQL、シェル）
• ファイルのアップロード：拡張子ではなく内容の検査で種類を確認し、サイズを制限する

認知の落とし穴

合理化	真実
「内部ツールだから、攻撃者はいない」	内部ツールも侵害されます。内部ユーザーもミスをします。内部脅威は現実に存在します。
「セキュリティは後で追加する」	セキュリティは機能ではありません。後付けには、最初から組み込む場合の 10 倍のコストがかかります。
「フレームワークが処理してくれる」	フレームワークには保護を回避できる手段があります。フレームワークが何を保護し、何を保護しないのかを正確に把握してください。
「入力検証は過剰だ」	歴史上のあらゆるインジェクション攻撃は、未検証の入力から始まりました。
「これは単なるプロトタイプだ」	プロトタイプは本番システムになります。最初からセキュリティを確保してください。
「複雑すぎて、開発が遅くなる」	データ侵害は開発を恒久的に遅らせます。
「誰もそんなことはしない」	攻撃者はまさにそのようなことをします。すべての入力を敵対的なものとして扱ってください。

ガードレール -- 停止して修正

• SQL クエリでの文字列連結
• ユーザー提供データに対する eval() または exec() の使用
• ソースコードまたはコミット済みの設定ファイル内のシークレット
• エンドポイントの認可チェック漏れ
• エンコードせずにレンダリングされるユーザー入力
• 認証情報を許可するワイルドカード * の CORS ポリシー
• 認証または機密データを扱う処理での HTTP
• サーバーサイドの対応がない、クライアントサイドだけの検証
• 無効化された CSRF 保護
• デプロイ環境でのデフォルト認証情報

このリストにある項目はすべてセキュリティの脆弱性です。出荷前に修正してください。

連携

補完的なスキル：

• godmode:system-design -- 認証戦略とデータフローの設計
• godmode:quality-enforcement -- 自動化された品質ゲートとしてのセキュリティチェック
• godmode:completion-gate -- 出荷前のセキュリティ検証
• godmode:test-first -- セキュリティを重視したテストケースの作成

要点

Trust boundary crossed -> validate input, sanitize output, verify authorization

例外はありません。「後で追加する」もありません。セキュリティとともにコードを出荷するか、コードを出荷しないかです。