先に要点
- OWASP Top 10 は OWASP(Open Worldwide Application Security Project)がおおむね 4 年ごとに更新する Web アプリで頻発する脆弱性カテゴリのランキング。2026年10月時点の最新は OWASP Top 10:2025 で、280 万を超えるアプリのデータとコミュニティ調査をもとにしている。個別の脆弱性カタログではなく、カテゴリ単位の優先順位として読む。
- 2025 版は A01: アクセス制御の不備、A02: セキュリティ設定ミス、A03: ソフトウェアサプライチェーンの不備、A04: 暗号化の失敗、A05: インジェクション、A06: セキュアでない設計、A07: 認証の失敗、A08: ソフトウェアやデータの整合性の不備、A09: セキュリティログとアラートの不備、A10: 例外的な状況の不適切な処理。
- 2021 版からの大きな変化は、サプライチェーンが 3 位に新設(旧 A06 の古いコンポーネントを拡張)、設定ミスが 5 位から 2 位へ、SSRF がアクセス制御に統合、例外処理の不備が A10 に新設の4点。番号が大きく動いたので、2021 版の番号で書かれた社内資料は読み替えが要る。
- 仕様書として読むより、自社プロダクトのチェックリストとして現状を当てはめるのが本来の用途。「どのカテゴリが自分達に当てはまるか」 を四半期に一度棚卸しすると、優先度のついた改善バックログになる。
- Top 10 だけが世界ではない。「OWASP API Security Top 10」 「OWASP Top 10 for LLM Applications」 「OWASP Mobile Top 10」 など領域別のリストもあり、自分達のスタックに合わせて読む。Web の Top 10 は 一般 Web アプリ向けの最大公約数。
「セキュリティ強化」 と言われても、「何から手を付けるべきか分からない」 のが現場の正直な気持ちです。「OWASP Top 10」 は、その問いに対する まずこの 10 カテゴリを上から押さえると、現実の事故の多くをカバーできる という共通リファレンスです。
「仕様書として暗記する」 のではなく、自社プロダクトの現状をカテゴリ単位で当てはめるチェックリストとして使うのが正しい使い方です。この記事では、2026年10月時点で OWASP 公式サイトの OWASP Top 10:2025 を確認し、10 カテゴリを実務目線で順に読み解きながら、「それぞれで現場が踏みやすい失敗と対策」 を整理します。2021 版の番号で覚えている人向けに、読み替え表も入れています。
OWASP Top 10 とは何か
OWASP は、Web セキュリティのオープンコミュニティです。OWASP Top 10 は、セキュリティ企業などから集めたテストデータとコミュニティ調査をもとに、Web アプリで実際によく見つかる脆弱性カテゴリの上位 10 件をまとめたもの。2025 版は 8 回目の版で、公式の説明では 280 万を超えるアプリのデータから 589 の CWE(脆弱性の種類の分類)を分析し、10 カテゴリに 248 の CWE を割り当てています。
具体的な脆弱性のリストではない
個別の CVE ではなく、「脆弱性のカテゴリ」 を扱う。「SQL インジェクションが何件あった」 ではなく、「インジェクション系全般」 という粒度。抽象的すぎず具体的すぎない、現場の議論で使いやすい単位。
おおむね 4 年ごとに更新される
2013 / 2017 / 2021 / 2025 と更新されてきた。2025 版はデータ由来の 8 カテゴリと、コミュニティ調査で選ばれた 2 カテゴリで構成される。データにまだ表れにくい新しい脅威を、現場の声で補う作り。
対策の世界共通言語
「うちのアプリ、A05 のインジェクションがまだ残ってる」 と言えば世界中のエンジニアに通じる。ただし 版によって番号が変わるので、資料には 「A05:2025」 のように版まで書くと誤解がない。
プロセスへの組み込みが本質
「開発・レビュー・運用の各フェーズで Top 10 を意識する」 のが理想。「設計レビュー時にカテゴリを 1 つずつチェック」 「年次のセキュリティ棚卸しで現状をマップ」 のような使い方。
2021 版から何が変わったか — 番号の読み替え
2021 版の番号で書かれた社内チェックリストや研修資料は多いはずです。2025 版で番号がどう動いたかを先に表で整理します。
| 2021 版 | 2025 版 | 変わった点 |
|---|---|---|
| A01 アクセス制御の不備 | A01 アクセス制御の不備 | 1 位のまま。旧 A10 の SSRF を取り込んだ |
| A05 セキュリティ設定ミス | A02 セキュリティ設定ミス | 5 位から 2 位へ上昇 |
| A06 脆弱で古いコンポーネント | A03 ソフトウェアサプライチェーンの不備 | ビルド・配布・更新の仕組み全体に範囲を広げた。コミュニティ調査で最多の 1 位票 |
| A02 暗号化の失敗 | A04 暗号化の失敗 | 2 位から 4 位へ |
| A03 インジェクション | A05 インジェクション | 3 位から 5 位へ。XSS も引き続きここ |
| A04 セキュアでない設計 | A06 セキュアでない設計 | 4 位から 6 位へ |
| A07 識別と認証の失敗 | A07 認証の失敗 | 名前が少し変わった |
| A08 ソフトウェアとデータの整合性の不備 | A08 ソフトウェアやデータの整合性の不備 | 順位は同じ |
| A09 ログとモニタリングの不備 | A09 セキュリティログとアラートの不備 | 「記録するだけでなく、気付いて動けるか」 に重心が移った名前 |
| A10 SSRF | A10 例外的な状況の不適切な処理 | 新設。SSRF は A01 へ |
順位は集めたデータでの見つかり方などをもとに決まるもので、暗号化やインジェクションの順位が下がったからといって、対策をやめてよいという意味ではありません。プレースホルダや自動エスケープ、TLS の設定は引き続き前提として守ります。
2025 版 10 カテゴリを実務目線で読む
各カテゴリで 「どんな攻撃か」 「現場でよく見る失敗」 「対策の方向性」 を整理します。
A01: アクセス制御の不備 (Broken Access Control)
2021 版に続いて 1 位。認可ロジックの抜けによる情報漏えい・権限昇格が中心で、2025 版では SSRF(サーバーに内部宛のリクエストを送らせる攻撃)もこのカテゴリに入りました。
よくある失敗
「URL の ID を書き換えるだけで他人の情報が見える」(IDOR)、「管理者用エンドポイントが認可チェック無しで叩ける」、「フロント側だけで権限制御している」、「API のメソッド差別なし(POST も DELETE も同じ権限で通る)」。
対策の方向性
サーバ側で必ず認可チェックが大前提。「ロール + リソース所有者 + コンテキスト」 を確認するパターンを共通ヘルパに切り出し、「各エンドポイントで明示的に呼ぶ」 設計にする。「認可テスト」 を CI に組み込む。
クラウド時代の追加観点
S3 バケットの誤公開、IAM の過剰権限、「CloudFront のキャッシュ汚染で他人のレスポンスを見る」 のような クラウド層での認可不備も A01 の観点で見る。S3 + OAC 移行もこのカテゴリの対策。
SSRF の被害シナリオと対策
「ユーザー指定の URL を取得する機能」 から 169.254.169.254(クラウドのメタデータ)に届くと、IAM の一時クレデンシャルを盗まれうる。内部 IP 宛てのブロック、http/https 以外の拒否、DNS 解決結果の検証、IMDSv2 の必須化で緩和する。2026 年 5 月の Next.js セキュリティリリースにも SSRF が含まれていた。
A02: セキュリティ設定ミス (Security Misconfiguration)
2021 版の 5 位から 2 位へ上がったカテゴリ。OWASP の説明では、テストしたアプリの 100% で何らかの設定ミスが見つかっています。デフォルト値のまま、不要な機能が有効、公開設定の間違いの3パターンが多い。
よくある失敗
S3 バケットの誤公開、「管理画面のデフォルトパスワードのまま運用」、「本番に開発用デバッグエンドポイントが残っている」、「セキュリティヘッダを設定していない」、「ディレクトリリスティングが見える」。
対策の方向性
Infrastructure as Code + ポリシーチェック(Terraform + Checkov、CloudFormation Guard、AWS Config Rules)で 設定の自動検出と是正を仕組み化する。「人間が気を付ける」 だけでは必ず漏れる。
最小権限・最小機能の原則
「必要なものだけ有効にする」。デフォルトで全部 ON ではなく、必要だと判明したものだけ明示的に有効化する設計が事故を減らす。「IAM のワイルドカード権限」 をなくすだけでも被害縮小に効く。
A03: ソフトウェアサプライチェーンの不備 (Software Supply Chain Failures)
2021 版の 「脆弱で古いコンポーネント」 を広げた新カテゴリ。OWASP は、ソフトウェアを ビルド・配布・更新する過程での破綻や侵害全般と定義しています。コミュニティ調査では回答者の半数がこのカテゴリを 1 位に挙げました。
よくある失敗
「package.json / composer.json / requirements.txt の依存を半年以上更新していない」、「CVE が出ているライブラリを使い続けている」、「CI/CD の権限が本番より緩い」、「SBOM(ソフトウェア部品表)を持っていない」。
対策の方向性
npm audit / pip-audit / composer audit / Dependabot を CI に組み込み、新しい脆弱性が見つかったら自動 PR。ロックファイルをコミットして再現性を確保し、依存追加時にレビューする。CI/CD・リポジトリ・成果物レジストリにも MFA と最小権限を適用する。
最近の事故事例
OWASP は 2025 年の npm の自己増殖型ワーム 「Shai-Hulud」 を例に挙げている。後続の Mini Shai-Hulud Worm(2026 年 5 月)も、正規パッケージのメンテナアカウントを乗っ取って悪意あるバージョンを公開する手口だった。
A04: 暗号化の失敗 (Cryptographic Failures)
2021 版の 2 位から 4 位へ。暗号化していない / 弱い / 鍵管理がずさんが中心です。
よくある失敗
「パスワードを平文または弱いハッシュ(MD5, SHA-1)で保存」、「通信に TLS を使っていない / 古い TLS バージョン」、「秘密鍵をリポジトリに commit」、「暗号化していない DB バックアップを外部ストレージに置く」。
対策の方向性
パスワードは Argon2 や bcrypt でハッシュ + ソルト。通信は TLS 1.2 以上、できれば 1.3。秘密鍵は AWS KMS / Secrets Manager / HashiCorp Vault のような専用基盤に置く。「暗号化は仕組みに任せ、自前で実装しない」 が鉄則。
A05: インジェクション (Injection)
2021 版の 3 位から 5 位へ。ユーザー入力がそのままコマンドや SQL として解釈される系全般で、XSS もこのカテゴリです。
よくある失敗
「SQL を文字列連結で組み立て」、「外部コマンドを shell=True で呼ぶ」、「テンプレートエンジンの自動エスケープを切って HTML 連結」、「ORM の Raw クエリを生で組む」。
対策の方向性
SQL は プレースホルダ(prepared statement)、HTML は テンプレートエンジンの自動エスケープを切らない、外部コマンドは シェルを介さない API + 引数配列。詳細は サニタイズ・エスケープ・バリデーションとエスケープ深掘りを参照。
新興: プロンプトインジェクション
LLM を組み込んだアプリでは プロンプトインジェクションが台頭。OWASP は別途 「Top 10 for LLM Applications」 で 1 位(LLM01)に挙げている。入力の文脈分離や権限最小化など、インジェクションと同じ発想の防御が効く。
原則: 許可リスト + 分離
「危ない文字を消す(拒否リスト)」 ではなく、許す形だけ通す(許可リスト)+ データと指示を分ける(プレースホルダ / 分離)。これがインジェクション系すべての対策の核。
A06: セキュアでない設計 (Insecure Design)
2021 版で新設された 設計レベルでの不備のカテゴリで、2025 版では 6 位。「実装を直しても、設計が間違っていれば直しきれない」 という問題意識です。
よくある失敗
「パスワードリセット URL に有効期限が無い」、「機能フラグで管理者機能を一般ユーザーにも見せられる作り」、「レート制限が無く総当たり攻撃が可能」、「Admin と User の差が API の実装次第になっている」。
対策の方向性
脅威モデリング(STRIDE / PASTA)を設計フェーズで行う。「このユースケースで攻撃者は何を狙うか」 「想定される攻撃に対し、どの層で守るか」 を 設計段階で言語化する。実装後に脆弱性スキャナで見つけるより、はるかに低コスト。
セキュア・バイ・デザイン
「機能を作る → 後でセキュリティを足す」 ではなく、機能要件と同時にセキュリティ要件を定義する。「このフォームは認証必須」 「この API は管理者のみ」 を 設計ドキュメントの第一級要素として扱う。
既存システムへの適用
一度動いているシステムでも、機能追加や仕様変更のタイミングに脅威モデリングを差し込める。「全部やる」 ではなく、重要な機能から優先順位を付けて評価するのが現実解。
A07: 認証の失敗 (Authentication Failures)
2021 版の 「識別と認証の失敗」 から少し名前が変わりました。ログイン周りの仕組みが弱い系です。
よくある失敗
「短すぎるパスワード許可」、「MFA(多要素認証)が無い」、「セッション ID が予測可能」、「セッションタイムアウトが長すぎる」、「パスワードリセットが攻撃に弱い」、「総当たり対策(レート制限)無し」。
対策の方向性
認証は自前で書かず、AWS Cognito / Auth0 / Okta / Firebase Auth のような既製品に任せる。MFA を標準で有効にする。レート制限を WAF や API Gateway で実装する。OAuth 2.0 と OIDC の正しい使い分けも重要。
パスワードの現在の基準
NIST SP 800-63B-4 は、パスワード単独で認証するなら 15 文字以上、多要素認証の一部なら 8 文字以上を求め、定期変更の強制や文字種の組み合わせルールを課さないこと、既知の漏えいパスワードとの照合を求めている。
パスキー / WebAuthn の台頭
パスワードレス認証(パスキー、WebAuthn)が普及フェーズに入っている。フィッシング耐性とユーザビリティを同時に上げられるので、新規システムは積極的にパスキー対応を検討する価値あり。
A08: ソフトウェアやデータの整合性の不備 (Software or Data Integrity Failures)
2021 版から順位は同じ。検証なしに信頼してしまう系です。
よくある失敗
「署名検証なしの自動更新」、「CI/CD で外部スクリプトを curl | sh で実行する」、「セッションオブジェクトを Cookie に詰めて改ざん検証なし」、「信頼できない JSON / YAML をデシリアライズして任意コード実行」。
対策の方向性
署名検証 + チェックサムを更新パイプラインに組み込む。デシリアライズ前にスキーマ検証。CI/CD では 信頼できるレジストリからのみ取得し、SLSA のような枠組みでビルドの出所を担保する。
A09: セキュリティログとアラートの不備 (Security Logging and Alerting Failures)
2021 版の 「ログとモニタリングの不備」 から名前が変わりました。記録していても、異常に気付いて動けなければ意味がないという方向です。
対策の方向性
認証・認可・重要操作のイベントを構造化ログに残す、改ざんされにくい場所(S3 Object Lock など)に保管、異常パターンで自動アラート(WAF、GuardDuty、Datadog)。事故時に 何が起きたか追える状態を最低ラインに。
クラウドネイティブな最低構成
「CloudTrail データイベント + GuardDuty + Security Hub + S3 アクセスログ」 を有効化するだけでも、「攻撃に気付くまでの時間」 を短くしやすい。アラートの宛先と、誰が何分以内に見るかまで決めておく。
A10: 例外的な状況の不適切な処理 (Mishandling of Exceptional Conditions)
2025 版の新カテゴリ。OWASP は 24 の CWE をまとめ、異常な状況を防ぐ・検知する・対処することの失敗と説明しています。従来は 「コード品質の問題」 として曖昧に扱われていた領域を、具体的な指針にした形です。
よくある失敗
「認可チェックで例外が起きたら通してしまう(fail open)」、「スタックトレースや内部情報をエラー画面に出す」、「戻り値を確認しない」、「例外でファイルやロックが解放されずリソースが枯渇する」、「途中で失敗した取引が中途半端に確定する」。
対策の方向性
エラーは 発生した場所で捕まえて意味のある形で処理し、最後の受け皿としてグローバルな例外ハンドラを置く。途中で失敗した処理は部分的に直そうとせず ロールバックする。利用者には分かりやすいメッセージだけを見せ、詳細はログへ。
攻撃との関係
大量のエラーを起こしてリソースを枯渇させる、詳細なエラーメッセージから内部構成を探る、という使われ方をする。レート制限・クォータで異常な状況そのものを起こしにくくし、同じエラーの繰り返しを監視する。
レビューで見る場所
空の catch、例外を握りつぶして true を返す関数、トランザクションの外で行う外部 API 呼び出し。エラー処理をセキュリティ要件・脅威モデリング・コードレビュー・負荷試験の対象に含める。
判断できないときは 「拒否する」 側に倒す(fail closed)のが基本です。たとえば認可サービスが落ちたときの扱いはこう書きます。
// 認可サービスが落ちたときに「通す」(fail open)のは危険
async function canAccess(user, doc) {
try {
return await authz.check(user, doc);
} catch (err) {
logger.error("authz check failed", { docId: doc.id }); // 詳細はログへ
return false; // 判定できないときは拒否する(fail closed)
}
}
OWASP Top 10 を 「自社の運用」 にどう組み込むか
「読んで終わり」 にしないために、運用への組み込み方を整理します。
- 11. 棚卸し: 現状を 10 カテゴリにマップ
既存システムを Top 10 の各カテゴリで評価。"A01 アクセス制御" "A02 設定ミス" などのチェックリストを作り、現状を ○ △ × で記録。これだけで改善優先度のあるバックログができる。2021 版の番号で作った既存のチェックリストは、読み替え表で 2025 版に付け替える。
- 22. 設計レビューにカテゴリチェックを組み込む
新規機能の設計時に "Top 10 のうちこの機能で関係するカテゴリ" を明示。設計ドキュメントのテンプレに "想定脅威" 欄を入れる。
- 33. コードレビュー観点に追加
PR テンプレに "OWASP 該当カテゴリと対策" を書く欄を作る。"A05 のためにプレースホルダ使用" "A02 のために設定値を環境変数化" "A10 のために失敗時は拒否" などを明文化する習慣に。
- 4
- 55. 四半期ごとの棚卸し
"Top 10 全カテゴリの現状" を四半期に一度レビュー。"前回から悪化したカテゴリ" を優先的に改善する PDCA を回す。
- 66. インシデント発生時の振り返り
事故が起きたら "Top 10 のどのカテゴリに該当したか" を版の番号つきで記録。次に同じ系統の事故を防ぐ材料にする。
「プロセスへの組み込み」 こそが OWASP Top 10 を活かす本質です。
API / LLM / Mobile 向け Top 10 もある
Web の Top 10 だけが世界ではありません。自分達のスタックに合わせて他のリストも読むと、抜けが減ります。
| リスト名 | 対象 | Web の Top 10 との関係 |
|---|---|---|
| OWASP API Security Top 10 | API バックエンド | API 特有の認可・流量制御・スキーマ検証を深掘り。「Broken Object Level Authorization」 などが並ぶ |
| OWASP Top 10 for LLM Applications(2025) | LLM 組み込みアプリ | 「プロンプトインジェクション」 「機密情報の漏えい」 「過剰な権限(Excessive Agency)」 「システムプロンプトの漏えい」 など。Web の Top 10 にない観点が多い |
| OWASP Mobile Top 10(2024) | モバイルアプリ | 端末内のデータ保存、バイナリ改ざん、通信の保護などモバイル特有 |
「自社の主たるスタック」 のリストを 1 つ深く読み、Web の Top 10 を共通基盤とするのが現実的な学習ルートです。
OWASP Top 10 に関するよくある質問
Q. Top 10 を全部対策すれば安全ですか?
A. 安全に近づくが、十分ではないです。Top 10 は 「特に多いカテゴリ」 を集計したもので、「これだけ守れば全部 OK」 ではありません。業界特有のリスクや、自社固有のビジネスロジック由来の脆弱性もあるので、Top 10 を 最低ラインと捉え、その上で 自社の脅威モデリングを追加するのが本来の使い方です。
Q. 2021 版と 2025 版で何が変わりましたか?
A. 「A03 ソフトウェアサプライチェーンの不備」 と 「A10 例外的な状況の不適切な処理」 が新しく入り、SSRF は A01 アクセス制御に統合されました。セキュリティ設定ミスは 5 位から 2 位へ上がり、暗号化の失敗・インジェクション・セキュアでない設計はそれぞれ 2 つずつ順位を下げています。A07 と A09 は名前が少し変わりました。
Q. 2021 版の番号で書かれた資料はどう読み替えればよいですか?
A. 本文の読み替え表のとおり、A02→A04、A03→A05、A04→A06、A05→A02、A06→A03、A10(SSRF)→A01 と付け替え、残りは同じ番号です。番号だけで会話すると版の取り違えが起きるので、資料には 「A05:2025」 のように版まで書くのが安全です。
Q. 個人開発でも OWASP Top 10 を使うべきですか?
A. 規模に応じて使うが答えです。自分しか使わないツールなら Top 10 全部は過剰ですが、公開する Web サービスや他人に使わせる API なら、最低でも A01(アクセス制御)/ A05(インジェクション)/ A07(認証)はチェックしておくべきです。「MFA 必須化 + プレースホルダ使用 + サーバ側認可」 だけでも事故のリスクを大きく下げられます。
Q. セキュリティ専門家がいない組織でも始められますか?
A. 始められます。「カテゴリごとに 1 つだけ対策を入れる」 から始めても、ゼロより圧倒的に強い。AWS や Cloudflare の マネージドサービス(WAF、Cognito、Macie、IAM Access Analyzer)を使うと、専門家がいなくても多くのカテゴリで標準的な対策ができます。
Q. CVSS との関係は?
A. 別の軸です。CVSS は 「個別の脆弱性の重大度スコア(0〜10)」、OWASP Top 10 は 「脆弱性カテゴリのランキング」。Top 10 を どのカテゴリを優先するかの議論に使い、CVSS を カテゴリ内の個別 CVE をどう優先するかに使う、と整理すると両方活きます。
Q. 脆弱性スキャナを買えば全部見つかりますか?
A. 見つけやすいものと見つけにくいものがあります。A05 インジェクション、A03 の古い依存、A04 の弱い TLS 設定はツールで見つけやすい一方、A01 の認可ロジック、A06 の設計の不備、A09 のアラート不足は、人間が業務知識を持ってレビューしないと見つかりません。スキャナは 「下地」、レビューと脅威モデリングが 「上もの」 と考えてください。
まとめ
OWASP Top 10 は Web セキュリティの共通言語です。「仕様書として暗記する」 のではなく、自社の現状をマップするチェックリストとして、設計・実装・運用の各フェーズに組み込むのが本来の使い方です。
2025 版では、サプライチェーン(A03)と例外処理(A10)が新たに加わり、設定ミス(A02)の重みが増しました。2021 版の番号で作ったチェックリストは読み替え表で付け替え、「完璧に守る」 ではなく 攻撃者にとってのコスパを悪くする発想で、「まず上位 3 つから」 のような優先順位で進めるのが現実的です。
参考リンク
- OWASP: OWASP Top 10:2025
- OWASP: Introduction(2025 版の変更点)
- OWASP: A03:2025 Software Supply Chain Failures
- OWASP: A10:2025 Mishandling of Exceptional Conditions
- OWASP Cheat Sheet Series: Cheat Sheet Series
- OWASP: API Security Top 10
- OWASP GenAI Security Project: Top 10 for LLM Applications
- OWASP: Mobile Top 10
- NIST: SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management