6-2. OWASP Top 10（SQLi・XSS・CSRF など）

このセクションで学ぶこと

• OWASP Top 10 が何のための資料か
• 現行の OWASP Top 10:2025 をどう読むか
• Injection と SQLi / XSS の関係
• Broken Access Control と CSRF の関係
• 安全な実装へつなげる基本方針
• OWASP Top 10 を暗記表ではなく実装レビューの視点として使う考え方

6-1 では、認証・認可・パスワードハッシュ・HTTPS を学んだ。
ここでは次の段階として、実務で頻出する失敗パターンをどう整理して捉えるか を学ぶ。

---

1. OWASP Top 10 とは何か

OWASP Top 10 は、Web アプリケーションで特に重要なセキュリティリスクをまとめた代表的な啓発資料である。

OWASP は Open Worldwide Application Security Project の略で、アプリケーションセキュリティに関する知見を公開しているコミュニティである。
その中でも Top 10 は、開発者やレビュー担当者が「どこに気を付けるべきか」をつかむ入口としてよく使われる。

重要なのは、OWASP Top 10 が次のどれでもないことだ。

• 10 個だけ覚えれば十分、という完全なチェックリスト
• すべてのシステムで同じ順番の優先度になるランキング表
• ツールを 1 本かければ自動で満点になる採点表

むしろ、OWASP Top 10 は次のような使い方に向いている。

設計時   : どんな失敗が起こりうるか考える
実装時   : 危険な書き方を避ける
レビュー : 抜けている観点を見つける
テスト時 : どこを重点的に試すか決める

つまり OWASP Top 10 は、「よくある事故の地図」 と考えると分かりやすい。

---

2. 現行の OWASP Top 10:2025

OWASP の公式サイトでは、現在 OWASP Top 10:2025 が公開されている。
この版では、個別の攻撃名をただ並べるよりも、根本原因（root cause）に近いカテゴリ で整理する傾向がさらに強くなっている。

公式資料へのリンク

• OWASP Top 10:2025 公式ページ（英語）
• OWASP Japan Chapter

現時点では、OWASP Top 10:2025 の日本語版公式ページはまだ公開されていない。
OWASP の公式ページにも「翻訳は利用可能になり次第追加される」と案内があるため、日本語版が公開されたら上の公式ページからたどれるようになるはずである。

2025 版の 10 カテゴリ

項目	カテゴリ	初学者向けの見方
A01	Broken Access Control	権限外の操作や閲覧を許してしまう
A02	Security Misconfiguration	危険な設定や不要な公開が残っている
A03	Software Supply Chain Failures	依存ライブラリやビルド経路の信頼が崩れる
A04	Cryptographic Failures	機密データの守り方が弱い
A05	Injection	入力がコマンドやクエリとして解釈されてしまう
A06	Insecure Design	設計の時点で悪用ケースへの備えが足りない
A07	Authentication Failures	ログインやセッション管理が弱い
A08	Software or Data Integrity Failures	ソフトウェアやデータの正しさを十分に検証できていない
A09	Security Logging & Alerting Failures	攻撃や異常に気づくための記録・通知が弱い
A10	Mishandling of Exceptional Conditions	異常時の扱いが危険で、安全側に倒れない

2025 版での見方のポイント

2025 版では、たとえば次のような整理になっている。

具体例	現在の主なカテゴリ
SQL Injection	A05: Injection
Cross-Site Scripting (XSS)	A05: Injection
Cross-Site Request Forgery (CSRF)	A01: Broken Access Control

ここで気を付けたいのは、有名な攻撃名が単独カテゴリから消えた = 重要でなくなった、ではない という点である。
CSRF は現在の 2025 版では単独項目ではないが、依然として重要な攻撃であり、Broken Access Control の文脈で捉えられている。

---

3. なぜ「根本原因」で整理するのか

同じ書き方のミスが、複数の脆弱性を生むことがあるからである。

たとえば次のように考える。

危険な根本原因
  ↓
外部入力をそのまま混ぜる
  ↓
SQLi / XSS / コマンドインジェクション など

別の例では、

危険な根本原因
  ↓
権限確認をクライアント側だけに置く
  ↓
URL 改ざん / 他人データ閲覧 / 管理画面侵入 など

つまり、個別の攻撃名だけを暗記しても、

• なぜ起きたのか
• どの設計や実装が共通原因か
• どう直すと再発を防げるか

が見えにくい。

OWASP Top 10 が根本原因寄りに整理されるのは、「名前当てゲーム」ではなく、予防の考え方へつなげるため である。

---

4. Injection：SQLi と XSS をどう理解するか

OWASP Top 10:2025 の A05: Injection は、信頼できない入力が、何らかの解釈器（interpreter）にコマンドや構文として扱われてしまう問題 をまとめたカテゴリである。

解釈器とは何か

解釈器といっても、特別なものだけではない。

• データベースは SQL を解釈する
• ブラウザは HTML / JavaScript を解釈する
• OS シェルはコマンドを解釈する

そのため、入力と命令の境界が崩れると危険になる。

SQL Injection（SQLi）

たとえば次のような SQL 文字列連結は危険である。

SELECT * FROM books WHERE title = 'ユーザー入力'

もし入力に次のような文字列が混ざると、

' OR '1'='1

クエリの意味が変わってしまう。

SELECT * FROM books WHERE title = '' OR '1'='1'

これにより、

• 本来 1 件だけ返すはずが大量のデータを返す
• 条件をすり抜ける
• 場合によっては更新や削除につながる

といった問題が起こりうる。

なぜ起きるのか

理由は単純で、データと SQL の構造を分けていない からである。

基本的な対策

• パラメータ化クエリ / プレースホルダを使う
• 動的な SQL 文字列連結を避ける
• 入力検証は補助として使うが、それだけで守れると思わない

Cross-Site Scripting（XSS）

XSS は、ブラウザへ表示する HTML の中に、攻撃者が用意したスクリプトや危険なタグを混ぜ込めてしまう問題である。

危険な例を単純化するとこうなる。

<p>ユーザーのコメント: ここに入力をそのまま差し込む</p>

もしコメント欄に次のような内容が入ると、

<img src=x onerror="alert(1)">

ブラウザは「ただの文字列」ではなく、HTML / イベント属性として解釈 しようとする。

なぜ起きるのか

理由は、表示用データと HTML の構造を分けていない からである。

基本的な対策

• 出力先の文脈に応じてエスケープ / 出力エンコーディングする
• innerHTML のような危険な API を安易に使わない
• 文字列として見せたいだけなら textContent のような安全な API を使う

SQLi と XSS は何が共通しているか

両者は見た目は違うが、本質は似ている。

観点	SQLi	XSS
何が解釈するか	データベース	ブラウザ
混ざるもの	SQL 構造と入力	HTML / JavaScript と入力
何が危険か	クエリの意味が変わる	画面上で意図しないコードが動く

つまり Injection の本質は、「入力をデータとして扱うべきところで、命令や構文として扱わせてしまう」 ことである。

---

5. Broken Access Control：CSRF をどう位置付けるか

OWASP Top 10:2025 の A01: Broken Access Control は、ユーザーが本来許されていない操作や閲覧をできてしまう問題 をまとめたカテゴリである。

典型例には次のようなものがある。

• URL の ID を変えたら他人のデータを見られた
• 一般ユーザーが管理 API を呼べた
• フロントエンドだけで権限を隠していて、サーバー側では確認していなかった
• POST / PUT / DELETE 側に認可チェックがなかった

CSRF は現在どう扱われるのか

CSRF は現在の Top 10 では単独項目ではなく、Broken Access Control に含まれる形で扱われている。

それでも重要なのは、CSRF が次のような流れで本人の意図しない操作を引き起こすからである。

1. 利用者は正規サイトへログイン済み
2. 別サイトや悪意あるページを開く
3. ブラウザが自動で Cookie を付けてリクエストを送る
4. サーバーが「ログイン済みの正規操作」と誤認する
5. 意図しない更新や送信が実行される

たとえば、次のような状態は危険である。

ブラウザは session_id を保持
  ↓
悪意あるページが送金・削除・設定変更の POST を誘発
  ↓
サーバーが追加確認なしで実行

なぜログイン済みブラウザが関係するのか

CSRF の特徴は、攻撃者が被害者のブラウザを利用して、被害者の権限で操作させる ことにある。
つまり「本人がログイン済みであること」が、逆に悪用の前提になる。

基本的な対策

• CSRF トークンを使う
• SameSite 属性を適切に使う
• Origin / Referer を確認する
• 状態変更を GET に載せない
• そもそも各操作で正しい認可確認を行う

XSS と CSRF の違い

初学者はこの2つを混同しやすい。

観点	XSS	CSRF
攻撃の中心	悪意あるスクリプトを実行させる	ログイン済みブラウザに意図しない操作を送らせる
主な原因	危険な出力・無害化不足	状態変更要求の正当性確認不足
典型対策	出力エンコーディング、安全な DOM API	CSRF トークン、SameSite、Origin 確認

---

6. ほかのカテゴリを実務へどうつなげるか

OWASP Top 10 は SQLi や XSS だけの一覧ではない。
実務では、次のような日常的な習慣と結び付けて考えることが大切である。

カテゴリ	日常的な実践
Security Misconfiguration	不要な公開をやめる、危険なデフォルト設定を見直す、CORS やヘッダーを適切に設定する
Software Supply Chain Failures	依存ライブラリを更新する、入手元を信頼できるものに限定する、ビルド経路を守る
Cryptographic Failures	HTTPS を使う、パスワードを平文保存しない、自作暗号を避ける
Insecure Design	実装前に「どう悪用されるか」を考える、脅威モデリングを行う
Authentication Failures	セッション管理、ログアウト、レート制限、MFA などを正しく設計する
Software or Data Integrity Failures	取り込むソフトウェアやデータの正しさを検証する
Security Logging & Alerting Failures	失敗を記録するだけでなく、必要な通知まで設計する
Mishandling of Exceptional Conditions	エラー時に危険な側へ倒れず、安全側で止まるようにする

既に学んだ内容とのつながり

この章の前半や過去章と、実はきれいにつながっている。

• 6-1 の HTTPS とパスワードハッシュ → Cryptographic Failures を減らす
• 6-1 の認証・認可 → Authentication Failures と Broken Access Control を減らす
• 4-3 のログ → Security Logging & Alerting Failures を減らす
• 4-3 の例外処理 → Mishandling of Exceptional Conditions を減らす

つまり、OWASP Top 10 は新しい話を 10 個足すのではなく、これまで学んだ内容をセキュリティの観点で再配置するもの とも言える。

---

7. 実務ではどう使うか

OWASP Top 10 は、開発の各場面で使える。

場面	自分へ投げるべき質問
設計	権限外の操作をどう防ぐか
実装	入力と命令の境界を崩していないか
画面実装	HTML として解釈される危険な出力をしていないか
API 実装	フロントエンドを信用せずサーバー側で認可しているか
依存管理	ライブラリやビルド経路を安全に保てているか
運用	攻撃や異常を記録し、検知できるか
障害時	例外時に情報漏えいしたり、fail-open したりしないか

ここで大事なのは、OWASP Top 10 を「試験の暗記項目」として終わらせないことだ。
コードレビューや設計レビューで、何を疑うべきかの観点 として使ってこそ価値がある。

---

8. 初学者が混同しやすい点

OWASP Top 10 だけ見れば十分、ではない

Top 10 は入口として非常に有用だが、すべての脅威を網羅するわけではない。
自分のシステム固有の業務ルールや運用条件も考える必要がある。

ORM を使えば自動で SQLi が消える、ではない

ORM（Object-Relational Mapping。Java クラスとテーブルを対応付ける仕組み）を使っていても、文字列連結でクエリを組めば危険は残る。
安全な API を選び、使い方も安全である必要がある。

ログインしている = 安全、ではない

ログイン済みブラウザは、CSRF のような攻撃では逆に悪用されることがある。
認証済みかどうかだけでなく、その操作が本当に本人の意図か も考えなければならない。

CSRF が単独項目でない = 学ばなくてよい、ではない

2025 版では CSRF は Broken Access Control に含まれるが、対策不要になったわけではない。
整理の仕方が変わっただけであり、実装上は依然として重要である。

---

まとめ

キーワード	説明
OWASP Top 10	重要な Web アプリケーションリスクを整理した代表的な啓発資料
A05: Injection	入力が命令や構文として解釈されてしまう問題群
SQL Injection	SQL の構造へ入力が混ざり、クエリの意味が変わる問題
XSS	ブラウザが危険な入力を HTML / JavaScript として解釈してしまう問題
A01: Broken Access Control	権限外の操作や閲覧を許してしまう問題群
CSRF	ログイン済みブラウザを悪用して意図しない操作を送らせる問題
パラメータ化クエリ	SQL の構造とデータを分ける基本対策
出力エンコーディング	XSS を防ぐために表示文脈に応じて文字を無害化する考え方
CSRF トークン	状態変更リクエストの正当性を確認する代表的な方法
ログ / アラート / 例外処理	セキュリティ事故を見つけ、危険な失敗を防ぐために重要

---

次のステップ

演習問題 に取り組んで、OWASP Top 10 を具体的な攻撃名と防御策へ結び付けて説明できるようになろう。

第6章が終わったら、次は 7-1. ユニット・統合・E2Eテストの違い で品質を守るためのテストの考え方へ進もう。