AppSec(App Security)の世界標準基準
OWASP(Open Worldwide Application Security Project) は、ソフトウェアのセキュリティ向上を目的とする国際的な非営利団体です。数年ごとに発表する 「OWASP Top 10」 は、「絶対に塞がなければならない脆弱性のトップ10リスト」として、開発者からセキュリティエンジニアまで業界全体のデファクトスタンダードになっています。
PCI DSSなどの国際セキュリティ基準も「OWASP Top 10の脆弱性が存在しないこと」を要件に組み込んでおり、開発現場でもコードレビューやペネトレーションテストの評価軸として日常的に参照されます。
古いバージョンのOWASP Top 10は、「XSS」や「SQLインジェクション」といった「具体的な症状」のランキングでした。しかし近年の改訂(2021年、および最新の2025年版)では、「インジェクション」や「暗号化の失敗」といった**「根本的な設計・実装の欠陥(Root Cause)」**という抽象度の高いクラスに統合・再編されています。症状を叩くのではなく、欠陥が生まれる原因を断つという方向性への転換です。
OWASP Top 10 2025年版の全体像
2026年現在、標準として参照されている2025年版のトップ10リストと、前回(2021年版)からの主な推移は以下の通りです。
| ランク | 2025年版 カテゴリ | 2021年版からの推移・特記事項 |
|---|---|---|
| A01 | アクセス制御の不備 (Broken Access Control) | 不動の第1位。他人のデータが見えてしまう致命的な設計欠陥。 |
| A02 | セキュリティの設定ミス (Security Misconfiguration) | 5位→2位へ急上昇。クラウド設定ミス(S3バケット公開等)の多発を反映。 |
| A03 | ソフトウェア・サプライチェーンの失敗 (Software Supply Chain Failures) | 🆕 新規追加。XZ Utils バックドアや npm 汚染など、依存関係の脆弱性が深刻化。 |
| A04 | 暗号化の失敗 (Cryptographic Failures) | 2位→4位。平文保存・弱い暗号アルゴリズムがデータ漏洩の直接原因に。 |
| A05 | インジェクション (Injection) | 3位→5位。ORマッパーの普及で発生頻度は低下傾向だが、依然として危険な脅威。 |
| A06 | 安全でない設計 (Insecure Design) | 順位維持。コードを書く前の段階、アーキテクチャ設計の欠陥に起因する問題。 |
| A07 | 識別と認証の失敗 (Identification and Authentication Failures) | 順位維持。セッション管理の不備やMFAの未実装。 |
| A08 | ソフトウェアとデータの完全性の失敗 (Software and Data Integrity Failures) | 順位維持。安全でないCI/CDパイプラインや署名なしの更新機構。 |
| A09 | セキュリティログとモニタリングの失敗 (Security Logging and Monitoring Failures) | 順位維持。侵害が起きても気付けない、という運用上の盲点。 |
| A10 | 例外条件の誤処理 (Mishandling of Exceptional Conditions) | 🆕 新規追加。エラー時に「フェイルオープン(セキュリティを解除して例外を許す)」してしまう論理バグ。 |
注目すべき3つの重要カテゴリ(解説)
A01: アクセス制御の不備(Broken Access Control)
堂々の1位です。「認証(誰であるか)」は正しくても、「認可(何をしてよいか)」のチェックが甘いケースです。現場でよく見かけるのが、機能の非表示でアクセスを制限しているつもりになっている実装です。
- IDOR(Insecure Direct Object Reference / 危険な直接オブジェクト参照):
https://example.com/api/user?id=100というURLを、ユーザーがid=101に書き換えただけで他人のマイページデータが返ってくる脆弱性。驚くほど単純ですが、バグバウンティでも頻繁に報告される定番の問題です。 - 対策: クライアント側(ブラウザのボタン非表示など)の制御を信用せず、必ずバックエンドでセッショントークンとユーザーIDを照合し、当該リソースへの**「所有権(Ownership)」**を検証すること。
A03: ソフトウェア・サプライチェーンの失敗(新規)
現代のWebアプリは、自社で書いたコードより、サードパーティのOSSライブラリが占める割合のほうがはるかに大きい現実があります。npmパッケージ、PyPIライブラリ、Dockerイメージを通じた攻撃は2024〜2025年に急増しました。
- リスク: 直接の依存関係だけでなく、そのライブラリがさらに依存する「孫請けライブラリ(推移的依存関係)」にマルウェアが仕込まれるケースが急増しています。2024年に発覚したXZ Utilsバックドア事件はその典型例です。
- 対策: **SBOM(Software Bill of Materials:ソフトウェア部品表)**の自動生成と、GitHub DependabotやSnykなどのSCA(ソフトウェアコンポジション解析)ツールをCI/CDパイプラインに統合し、既知のCVEを持つパッケージのビルドをブロック(Shift-Left)すること。
A10: 例外条件の誤処理(新規)
システムが予期せぬエラー(DB切断や外部APIタイムアウト等)に直面したときの、エラーハンドリングの不備による脆弱性です。セキュリティ設計では「フォールトモードをどう設計するか」が重要であり、これを誤ると平時には見えない穴が生まれます。
- フェイルオープンの危険性: 認証APIが落ちているときに「エラーなら認証をスキップしてtrue(ログイン成功)を返してシステムを止めないでおこう」というロジックを実装してしまう致命的なミス。障害時にこそ脆弱性が露出します。
- 情報漏洩(Stacktrace Leak): 本番環境のエラー画面に、バックエンドのSQL文やファイルパスを含む詳細なスタックトレースが表示されてしまう設定ミス。攻撃者にとっては偵察情報の宝庫になります。
- 対策: セキュリティ設計では必ず**「フェイルセキュア(エラー時はデフォルト拒否)」**を原則とすること。本番のフロントエンドには「予期せぬエラーが発生しました」という無害なメッセージのみを返し、詳細なエラーログは内部のSIEMにのみ送ること。
【確認問題】社内の開発チームが、新機能として「ユーザーのプロフィール画面」を実装しました。ログイン状態で `https://app.example.com/profile/user_555` にアクセスすると自身の情報が見えます。ここで攻撃者がURLの数字を `user_556` に書き換えたところ、他のユーザーの住所と電話番号が表示されてしまいました。この脆弱性は、OWASP Top 10のどのカテゴリに分類されますか?