OWASP Top 10 は、Webアプリケーションのセキュリティリスクとして最も広く参照されているリストであり、信頼される非営利団体であるOpen Worldwide Application Security Project (OWASP) によって公開されています。セキュリティの専門家向けに書かれていますが、そこで説明されるリスクには、情報漏えい、システム停止、罰金、信頼の失墜といった直接的なビジネス上の影響があります。本ガイドは各カテゴリーを平易な言葉で解説し、自社のアプリケーションについて適切な質問ができるようにします。
OWASP は攻撃パターンの変化に合わせて数年ごとにリストを改訂しています。以下のカテゴリーは、多くのチームにとって依然として標準的な参照先である、確立された2021年版の改訂を反映しています。順位は変動しても、根底にあるリスクは安定しています。
要点
- OWASP Top 10 は、Webアプリケーションで最も重大なセキュリティリスクを示す業界標準のリストです
- 主なカテゴリーは、アクセス制御、弱い暗号、インジェクションの欠陥、そして早い段階で下された安全でない設計上の判断に関するものです
- これらのリスクの多くは、いくつかの根本原因に集約されます。確認の欠落、設定ミス、古いコンポーネント、そして不十分な監視です
- 各項目への対応について、チームやベンダーに責任を持たせるのに、あなたが技術者である必要はありません
1. アクセス制御の不備（Broken Access Control）
意味: ユーザーが本来できないはずのことを実行または閲覧できてしまう状態です。たとえば、URL内のIDを変更して別の顧客のデータを閲覧したり、管理者でないのに管理機能に到達したりします。
なぜ重要か: これは一貫して最も一般的で被害の大きいリスクの一つです。データの露出や不正な操作に直結します。
チームに聞くべきこと: 権限はインターフェースに隠されているだけでなく、すべてのリクエストに対してサーバー側で強制されていますか？
2. 暗号化の失敗（Cryptographic Failures）
意味: 機密データ（パスワード、決済情報、個人情報）が適切に保護されていない状態です。たとえば、通信中や保存時に暗号化されていない、あるいは弱い・古いアルゴリズムで保護されているなどです。
なぜ重要か: 機密データの露出は情報漏えいを引き起こし、GDPRの下では罰金の可能性や開示義務につながります。
チームに聞くべきこと: すべての通信はHTTPSで行われ、機密データは最新のアルゴリズムで保存時に暗号化されていますか？
3. インジェクション（Injection）
意味: 信頼できない入力がコマンドとして扱われ、攻撃者がデータベースを操作（SQL injection）したり、意図しない処理を実行したりできる状態です。クロスサイトスクリプティング（XSS）もここに含まれます。
なぜ重要か: インジェクションはデータベース全体を露出または破壊し、ユーザーセッションを乗っ取る可能性があります。
チームに聞くべきこと: パラメーター化クエリを使用し、すべてのユーザー入力を検証・エンコードしていますか？
4. 安全でない設計（Insecure Design）
意味: セキュリティの弱点がコードだけでなく設計そのものにある状態です。たとえば、悪用可能なパスワードリセットの流れや、ブラウザから送られた価格を信用してしまう決済処理などです。
なぜ重要か: 設計上の欠陥は後からパッチで消せません。機能そのものの再検討が必要です。セキュリティは最初から考慮しなければなりません。
チームに聞くべきこと: 重要な機能を構築する前に、脅威モデリングを行っていますか？
5. セキュリティの設定ミス（Security Misconfiguration）
意味: 安全でない初期設定、有効なままの不要な機能、詳細すぎるエラーメッセージ、あるいは欠落したセキュリティヘッダーなどです。
なぜ重要か: 設定ミスは非常に一般的で、攻撃者が発見・悪用するのが容易であることが少なくありません。
チームに聞くべきこと: 初期アカウントは削除され、未使用の機能は無効化され、セキュリティヘッダーは設定されていますか？
6. 脆弱で古いコンポーネント（Vulnerable and Outdated Components）
意味: アプリケーションが、既知の脆弱性を持ちながら更新されていないサードパーティのライブラリ、フレームワーク、プラグインに依存している状態です。
なぜ重要か: 攻撃者は既知の脆弱なコンポーネントを大規模にスキャンします。多くの重大な侵害は、パッチ未適用の依存関係にさかのぼります。
チームに聞くべきこと: 依存関係を把握し、脆弱性が公表されたら速やかに更新していますか？
7. 識別と認証の失敗（Identification and Authentication Failures）
意味: 弱いログインの仕組みです。不十分なパスワードポリシー、総当たり攻撃（brute force）への保護の欠如、弱いセッション管理、あるいは多要素認証の欠落などです。
なぜ重要か: 侵害されたアカウントは、データや機能への直接の入口になります。
チームに聞くべきこと: 多要素認証（MFA）を提供し、クレデンシャルスタッフィングや総当たり攻撃から保護していますか？
8. ソフトウェアとデータの整合性の失敗（Software and Data Integrity Failures）
意味: 検証されていないソースからのコード、更新、データを信頼することです。たとえば、安全でないソフトウェア更新の仕組みや、侵害されたビルドパイプライン（サプライチェーンのリスク）などです。
なぜ重要か: サプライチェーン攻撃は増加しており、単一の信頼されたチャネルを通じて一度に多数の被害者を侵害する可能性があります。
チームに聞くべきこと: 更新や依存関係の整合性を検証し、ビルドとデプロイのパイプラインを保護していますか？
9. セキュリティログと監視の失敗（Security Logging and Monitoring Failures）
意味: セキュリティに関連するイベントを記録しない、あるいは監視しないため、攻撃が長期間気づかれないまま続いてしまう状態です。
なぜ重要か: 見えないものには対応できません。監視が不十分であることが、侵害が何か月も検出されないままになる理由です。
チームに聞くべきこと: セキュリティイベントを記録し、不審な活動に対してアラートを出していますか？
10. サーバーサイドリクエストフォージェリ（SSRF）
意味: 攻撃者がサーバーをだまして、本来アクセスすべきでないシステムへリクエストを送らせ、公開されるべきでない内部サービスに到達しうる状態です。
なぜ重要か: SSRF は内部インフラやクラウドのメタデータを露出させる可能性があり、重大な侵害でも見られてきました。
チームに聞くべきこと: サーバーが呼び出せる宛先を検証し、制限していますか？
重要なポイント
- OWASP Top 10 は、Webアプリケーションのセキュリティリスクに関する標準的な参照先です。多くの項目は、確認の欠落、設定ミス、古いコンポーネント、弱い監視に集約されます。
- アクセス制御、暗号、インジェクション、安全でない設計が、最も影響の大きいカテゴリーです。
- 各リスクについてチームやベンダーに責任を持たせるのに、技術者である必要はありません。上記の質問は良い出発点です。
- 自社の状況を最も確実に知る方法は、独立したテストです。
あなたのサイトを OWASP Top 10 に照らしてテストする
上記の質問は会話の糸口です。答えを与えてくれるのは専門的なテストです。アプリケーションセキュリティテスト は、静的コード解析、動的な実行時テスト、依存関係とサプライチェーンの監査、認証と暗号のレビューを組み合わせ、実際のアプリケーションでこれらのリスクを見つけ出します。結果はリスク評価付きで提示され、修正の指針も示されます。稼働中のサイトを保護するより広い視点については、英国企業向けWebサイトセキュリティ監査ガイド をご覧ください。
よくある質問（FAQ）
OWASP Top 10 とは何ですか？ Webアプリケーションで最も重大なセキュリティリスク10項目を定期的に更新するリストで、Open Worldwide Application Security Project (OWASP)が公開しています。アプリケーションセキュリティの作業に優先順位を付けるための、業界標準の参照先です。
OWASP Top 10 は完全なセキュリティ標準ですか？ いいえ。最も重大なリスクを扱う、意識向上と優先順位付けのための文書であり、網羅的なチェックリストではありません。より深いテストや安全な開発手法と併せて、出発点として活用してください。
OWASP Top 10 はどのくらいの頻度で更新されますか？ OWASP はデータや攻撃パターンの変化に合わせて数年ごとに改訂します。カテゴリーは進化し順位も変わりますが、根底にあるリスクはおおむね安定しているため、改訂の合間も概念は有効であり続けます。
どの OWASP リスクが最も危険ですか？ アプリケーションによって異なりますが、アクセス制御の不備とインジェクションは歴史的に最も一般的で被害の大きいものの一つでした。あなたにとって正しい優先順位は、自社のアプリケーションがどのように構築され、どの程度公開されているかによって決まります。
自社のアプリケーションが影響を受けているかどうか、どう知ればよいですか？ 唯一信頼できる方法はテストです。静的解析、動的テスト、そして実際のコードベースと稼働中のアプリケーションに対する依存関係の監査を行います。専門的なアプリケーションセキュリティテストは、あなたのリスクをこれらのカテゴリーに対応付け、優先順位を付けた修正を示します。
コメント