owasp-security

OWASP セキュリティ

コードの作成やレビューでは、これらの基準を適用してください。レビューでは、以下のワークフローに従ってください。

参考ファイル（タスクに必要なファイルを、必要なセクションだけ読んでください）：

• reference/review-checklist.md：すべての Top 10 カテゴリーに加え、LLM とエージェントのチェック項目を網羅したチェックリストです。レビューのステップ 3 で読んでください。
• reference/languages.md：20 以上の言語について、安全でない例と安全な例を交えた、言語ごとの注意点を記載しています。レビュー対象の言語のセクションを読んでください。
• reference/config-and-supply-chain.md：Dockerfile、Kubernetes、Terraform、フレームワークの設定、セキュリティヘッダー、ロックファイル、CI/CD における A02 と A03 を扱います。変更が設定、IaC、依存関係、またはパイプラインに関わる場合に読んでください。
• reference/owasp-report.md：すべての Top 10:2025、ASVS 5.0、LLM Top 10、Agentic 項目について、攻撃ベクトル、緩和策、実例を記載しています。約 1100 行あります。必要なセクションに移動してください。

セキュリティレビューのワークフロー

このチェックリストを回答にコピーし、作業しながらチェックを入れてください。

Security Review Progress:
- [ ] Step 1: Map entry points and trust boundaries
- [ ] Step 2: Load the references this code needs
- [ ] Step 3: Sweep for candidate issues
- [ ] Step 4: Triage every candidate
- [ ] Step 5: Report findings

ステップ 1：エントリーポイントと信頼境界を特定します。 攻撃者が制御できるデータの入力箇所を列挙します。 ルートとハンドラー、ヘッダーと Cookie、アップロード、Webhook、キューコンシューマー、CLI 引数、 サードパーティ API のレスポンス、LLM が読み込む、または返すあらゆるものが対象です。認証と認可が どこで適用されるかを確認してください。ルートごとではなく、ミドルウェアで一元的に適用されることがよくあります。

ステップ 2：このコードに必要な参考資料を読み込みます。 languages.md の該当する言語のセクションを読みます。 設定、IaC、依存関係、または CI に変更がある場合は config-and-supply-chain.md を読みます。コードがモデルを呼び出す、 またはエージェントを実行する場合は、owasp-report.md の LLM と Agentic のセクションを読みます。

ステップ 3：問題候補を洗い出します。 コードに該当するカテゴリーについて、review-checklist.md を確認します。 候補ごとに、ステップ 1 のエントリーポイントからシンクまでの経路をたどります。

ステップ 4：「指摘を報告する前に」に記載された基準ですべての候補をトリアージします。 基準を満たさない候補は除外するか、 多層防御の改善点として優先度を下げます。候補に到達可能かどうかが不明な場合は、判断する前に、その入力についてステップ 1 に戻ってください。

ステップ 5：以下の形式で指摘を報告します。 重大度の高いものから順に記載してください。

脆弱性を報告する前に

パターンに一致しただけでは、脆弱性とはいえません。自動セキュリティレビューで最もよくある失敗は、到達不能なコードや、すでに緩和策が講じられているコードを報告することで、本当の問題が埋もれてしまうことです。報告する前に、次の4点をすべて確認してください。

1. 入力は実際に攻撃者が制御できますか？ 実際のエントリーポイントまでさかのぼってください。たとえば、リクエストパラメーター、ヘッダー、Cookie、アップロードファイル、Webhook、キューメッセージ、サードパーティー API のレスポンスなどです。定数、列挙型、信頼された内部設定からしか取得されない値は、インジェクションの入力元ではありません。
2. その入力によってシンクに到達できますか？ バリデーション、許可リスト、ORM、またはフレームワークレベルの制御が両者の間にすでに存在しないか確認してください。ルートの認可が欠けていると指摘する前に、認証ミドルウェア（middleware.ts、proxy.ts、Express/Django/Rails のミドルウェア、基底コントローラー、デコレーター）を確認してください。適用される制御はルートごとではなく、集中管理されていることがよくあります。
3. 影響範囲はどの程度ですか？ 誰が引き起こせて、何を得られ、信頼境界を越えるのでしょうか？ クラウドメタデータに到達する SSRF と、localhost にしか到達しない SSRF では異なります。
4. 攻撃者はすべての手順を実行できますか？ エクスプロイトの各手順は、攻撃者の立場から実行可能でなければなりません。シンボリックリンクの競合状態には、サーバー上でシンボリックリンクを作成する手段が必要です。ヘッダー攻撃には、そのヘッダーを設定できるクライアントが必要です。攻撃者がその能力を持つことがコードから確認できない手順がある場合、その報告は High ではなく「要検証」です。

深刻度はパターンではなく、エクスプロイト可能性に基づいて報告してください。具体的な経路（この入力がこのシンクに到達する）を示し、理論上の問題、または直接エクスプロイト可能ではなく多層防御上の問題である場合は、その旨を明記してください。利用可能なコードから到達可能性を判断できない場合は、どちらかを断定せず、その旨を記載してください。

報告形式

脆弱性ごとに1ブロックとし、深刻度の高い順に記載します。

[SEVERITY] Title (CWE-###, OWASP A##:2025, LLM## Risk Name, ASI## Risk Name)
Location:   path/to/file.ext:LINE
Path:       <entry point> -> <intermediate hops> -> <sink>
Impact:     who can trigger it, what they get, which trust boundary it crosses
Fix:        the concrete change, with a code snippet when it isn't obvious
Confidence: Confirmed | Likely | Needs verification (say what you couldn't see)

LLM および ASI の ID はすべて、リスク名と併記してください。例：「LLM03 過剰な自律性」。LLM の ID だけでは曖昧です。2025 年版と 2026 年版では、同じ番号が異なるリスクを指します。

深刻度	意味
Critical	認証不要のリモートコード実行、認証の回避、または大規模なデータ漏えい
High	認証済みの攻撃が信頼境界を越える（他のテナントへの IDOR、ログイン後の SQLi など）
Medium	特殊な前提条件が必要、または影響が攻撃者自身のデータに限られる
Low	実証されたエクスプロイト経路を伴わない多層防御上の欠陥
Info	強化の提案。脆弱性ではないことを明確に述べてください

エクスプロイト可能な問題が見つからなかった場合は、その旨を明確に述べてください。網羅的に見せるために Info 項目を並べないでください。報告が長い一覧になると、本当の問題が無視される原因になります。

OWASP Top 10:2025

2021 年版から名称が変更されたカテゴリが3つあり、新しいカテゴリが2つあります（A03、A10）。オンラインの OWASP 資料には2021年版が今も多く掲載されているため、次の名称と番号を使用してください。

#	カテゴリ	主な予防策
A01	アクセス制御の不備（SSRF を含むように変更）	デフォルトで拒否し、サーバー側で適用し、所有権を検証する
A02	セキュリティ設定の誤り	設定を強化し、デフォルト設定を無効にし、機能を最小限にする
A03	ソフトウェアサプライチェーンの障害	バージョンを固定し、整合性を検証し、依存関係を監査する
A04	暗号化の失敗	TLS 1.2 以降、AES-256-GCM、パスワードには Argon2/bcrypt を使用する
A05	インジェクション	パラメーター化クエリ、入力検証、安全な API
A06	安全でない設計	脅威モデリング、レート制限、セキュリティ制御の設計
A07	認証の失敗	MFA、漏えい済みパスワードの確認、安全なセッション
A08	ソフトウェアまたはデータの完全性の障害	パッケージへの署名、CDN への SRI の適用、安全なシリアライズ
A09	セキュリティログとアラートの失敗	セキュリティイベントを構造化形式で記録し、アラートを設定する
A10	例外的な状況への不適切な対処	失敗時は閉じる、内部情報を隠す、コンテキストとともに記録する

LLM アプリケーション向け OWASP Top 10（2026）

LLM を呼び出すアプリケーション（チャットボット、RAG、副操縦ツール、エージェント）向けです。2026 年版ではリストの番号が変更されています。2025 年版の ID は owasp-report.md の表で変換し、2026 年版の ID のみを記載してください。

#	リスク	主な対策
LLM01	プロンプトインジェクション	完全な対策はありません。信頼できないコンテンツ（画像、音声、ツールの出力を含む）を隔離し、モデルがアクセスできないように権限を管理し、出力をフィルタリングします
LLM02	機密情報の漏えい	トレーニングデータ／RAG データをサニタイズし、コンテキストから PII を削除し、ユーザーごとにモデルが取得できる情報を制限します
LLM03	過剰な自律性	ツールと権限を最小限にし、破壊的なアクションには人間の承認を必須にし、タスクごとに認証情報の範囲を限定します
LLM04	サプライチェーン	モデルの来歴と署名を検証し、サードパーティのモデルハブを審査し、モデルとアダプターのバージョンを固定します
LLM05	データおよびモデルのポイズニング	トレーニング／ファインチューニングのソースを検証し、データ取り込み時に異常を検出し、ホールドアウトデータによる整合性テストを実施します
LLM06	無制限のリソース消費	ユーザー／キーごとにレート制限を設け、リクエストごとのトークン数とツール呼び出し回数に上限を設定し、コストを監視し、ハードタイムアウトを設定します
LLM07	誤情報	出典を引用し、確信度を示し、重要な回答には根拠を求め、AI による生成であることを開示します
LLM08	隠れたコンテキストの漏えい	システムプロンプト、ツールスキーマ、その他の隠れたコンテキストは抽出されるものと考えます。そこに秘密を含めず、隠されていることを前提とした認可やポリシーを設けないでください
LLM09	ベクトルおよび埋め込みの弱点	ベクトルストアをテナントごとに分離し、検索にアクセス制御を適用し、チャンクに署名またはハッシュを付与して間接的なプロンプトインジェクションを防ぎます
LLM10	不適切な出力処理	生成コードを含むすべての LLM 出力を信頼できない入力として扱います。SQL、シェル、HTML、コード、ツール呼び出しなどの処理先に渡す前に、検証、エスケープ、またはサンドボックス化します

エージェント型アプリケーション向け OWASP Top 10（2026）

計画を立てたり、ツールを呼び出したり、メモリを保持したりする AI エージェントシステム向けです。

リスク	説明	対策
ASI01：エージェントの目標の乗っ取り	プロンプトインジェクションによってエージェントの目標が変更されます	ツールや検索結果のコンテンツをデータとして扱い、目標の境界を設け、動作を監視します
ASI02：ツールの誤用と悪用	ツールが意図しない方法で使用されます	最小権限、きめ細かな権限設定、入出力の検証
ASI03：ID と権限の悪用	委任された信頼、継承された認証情報、ロールチェーンの悪用	有効期間の短いスコープ限定トークン、ID 検証
ASI04：エージェント型サプライチェーンの脆弱性	プラグイン／MCP サーバーの侵害	署名の検証、サンドボックス化、プラグインの許可リスト
ASI05：予期しないコード実行	安全でないコードの生成／実行	実行のサンドボックス化、静的解析、人間による承認
ASI06：メモリおよびコンテキストのポイズニング	RAG／コンテキストデータの破損	保存コンテンツの検証、信頼レベルごとの分割
ASI07：安全でないエージェント間通信	エージェント間メッセージのなりすまし／傍受	認証、暗号化、メッセージの完全性の検証
ASI08：連鎖的な障害	エラーがシステム間で伝播します	サーキットブレーカー、グレースフルデグラデーション、分離
ASI09：人間とエージェント間の信頼の悪用	エージェントへの過信を利用してユーザーを操作します	AI コンテンツのラベル付け、ユーザー教育、検証手順
ASI10：悪意あるエージェント	侵害されたエージェントが悪意のある行動を取ります	動作の監視、キルスイッチ、異常検出

ASVS 5.0 の主な要件

ASVS 5.0（2025 年 5 月）では、すべての章の番号が変更され、再編成されています。4.0 の要件 ID は 5.0 に対応していません。V2.1.1 は 4.0 では「パスワードの長さ」を意味していましたが、現在は別の意味です。5.0 の ID のみを記載してください。レベルはアプリケーションのカテゴリではなく、要件の割合によって定義されています。

レベル	割合	意図
L1	約 20%	最低限の基準。導入のハードルを下げるため、意図的に範囲を小さくしています
L2	約 50%（累計約 70%）	ほとんどのアプリケーションが目標とすべきレベル
L3	残り約 30%	最も高い保証レベル

レベル 1 — 最低限の基準

• パスワードは8 文字以上とし、15 文字以上を強く推奨します（6.2.1）
• 文字種の組み合わせを強制せず、任意の文字、貼り付け、パスワードマネージャーを許可します（6.2.5、6.2.7）
• よく使われるパスワードの上位 3000 件以上をブロックします（6.2.4）
• クレデンシャルスタッフィングや総当たり攻撃に対する自動化対策を講じます（6.3.1）
• root／admin／sa などのデフォルトアカウントを設けません（6.3.2）
• セッショントークンは、エントロピーが 128 ビット以上の CSPRNG から取得します（7.2.3）
• 認証時および再認証時に、新しいセッショントークンを発行します（7.2.4）
• ログアウトまたは期限切れ後は、セッションを完全に使用できない状態にします（7.4.1）
• 機能レベルおよびデータレベルのアクセスを、明示的な権限に制限します（8.2.1、8.2.2）
• クライアントが操作できない、信頼されたサービスレイヤーで認可を適用します（8.3.1）
• すべてのデータアクセスにパラメーター化クエリ／ORM を使用します（1.2.4）。OS 呼び出しもパラメーター化します（1.2.5）
• HTML、URL、JavaScript／JSON に対して、コンテキストに応じた出力エンコードを行います（1.2.1–1.2.3）
• eval() や動的コード実行を避けます（1.3.2）
• 信頼されたサービスレイヤーで入力を検証し、可能な場合は許可リスト方式を採用します（2.2.1、2.2.2）
• すべての外部トラフィックで TLS 1.2 以上を使用し、公的に信頼された証明書を用います（12.1.1、12.2.1、12.2.2）
• 承認された暗号およびモードのみを使用します。ECB や PKCS#1 v1.5 パディングは使用しません（11.3.1、11.3.2）
• URL やクエリー文字列に機密データを含めません（14.2.1）

レベル 2 — ほとんどのアプリケーションが目指すべき基準

• MFA、または文書化された単一要素認証の組み合わせを使用します（6.3.3）
• パスワードを、漏えいしたパスワードのリストと照合します（6.2.12）
• パスワードの定期的な強制変更は行わず、漏えいした場合にのみ変更します（6.2.10）
• すべてのセキュリティログ要件はここから始まります。 ASVS 5.0 には L1 のログ要件はありません。V16 全体が L2 以上です。認証試行、認可の失敗、セキュリティイベント、予期しないエラーを記録します（16.3.1–16.3.4）
• ログエントリーには、同期された時計を基準とする日時／場所／ユーザー／内容のメタデータを含めます（16.2.1、16.2.2）
• ログインジェクションを防ぐためにログをエンコードし、改ざんから保護して、外部のマシンに転送します（16.4.1–16.4.3）
• ユーザーには一般的なエラーメッセージを表示し、詳細はログに記録します（16.5.1）

レベル 3 — 最高水準の保証

ASVS 5.0 には92 件の L3 要件がありますが、ここでは列挙していません。新たな要件を追加するのではなく、L2 の要件を強化するため、知っておく価値のあるものを 2 つ紹介します。

• 要素の 1 つは、FIDO キーなど、ハードウェアベースでフィッシング耐性のあるものでなければなりません（6.3.3、L3 条項）
• 失敗した認可だけでなく、すべての認可判断を記録します（16.3.2、L3 条項）

実際に L3 評価を行う場合は、規格そのものを参照してください。章の一覧については reference/owasp-report.md をご覧ください。