outputOWASP Top 10とは？2021年版の全脆弱性リスト・各項目の意味と対策をわかりやすく解説

「Webアプリに脆弱性があると言われたが、何から手をつければいいかわからない」
「OWASP Top 10という言葉を聞いたことはあるが、全項目をきちんと理解できていない」

Webアプリケーションのセキュリティ対策を体系的に学ぼうとすると、必ずといっていいほど「OWASP Top 10」という名前が出てきます。世界中の開発者・セキュリティ担当者が参照する、最も権威あるWebセキュリティリストです。

この記事では、OWASP Top 10（2021年版）の全10項目を、現場で使えるレベルで解説します。各リスクの意味・具体的な攻撃例・中小企業でも実践できる対策まで、一気に整理します。

OWASP Top 10とは？なぜ重要なのか

OWASP（オワスプ）は「Open Worldwide Application Security Project」の略で、Webアプリケーションセキュリティに関する情報を無償公開している非営利団体です。

その中で最も有名なドキュメントが「OWASP Top 10」です。Webアプリケーションで最も重要なセキュリティリスクを10項目にまとめたリストで、3～4年ごとに更新されています。最新版は2021年に公開されました。

なぜこれほど重要視されるかというと、理由は3つあります。

・世界標準の参照元として機能： PCI DSS（クレジットカードセキュリティ基準）、NIST、ISO 27001など主要なセキュリティフレームワークがOWASP Top 10を参照しています。
・実際の侵害データに基づく： 数十万件に及ぶ実際のアプリケーション脆弱性データを分析して作成されており、現実の脅威を正確に反映しています。
・開発者と情シス双方の共通言語： 「A01（アクセス制御の不備）が検出されました」という形で、開発チームとセキュリティ担当者が同じ枠組みで議論できます。

「自社はWebアプリを自作していないから関係ない」と思う方もいるかもしれません。しかし、WordPressなどのCMSやSaaSの設定ミスも、OWASP Top 10の範疇に入る脆弱性を生みます。情シス担当者も最低限の知識として押さえておくべきリストです。

2021年版 Top 10の全項目を解説

1. A01: アクセス制御の不備（Broken Access Control）

2021年版で1位に躍り出た最重要リスクです。2017年版では5位でしたが、実際の侵害事例でこのカテゴリが急増したため、トップに昇格しました。

どんな問題か：
本来アクセスできないはずのデータや機能に、権限のないユーザーがアクセスできてしまう状態です。

具体例：
・URLを ?user_id=100 から ?user_id=101 に変えると他人のデータが見える（水平権限昇格）
・一般ユーザーが管理者専用のAPIエンドポイントを直接呼び出せる（垂直権限昇格）
・ログアウト後もセッショントークンが有効で悪用できる

対策：
・APIの全エンドポイントにサーバー側での権限チェックを必ず実装する
・デフォルトは「アクセス拒否」とし、明示的に許可したものだけ通す設計にする
・セッション管理を正しく実装し、ログアウト時はサーバー側でもトークンを無効化する

2. A02: 暗号化の失敗（Cryptographic Failures）

旧名称は「機密データの露出（Sensitive Data Exposure）」でした。2021年版から「暗号化の問題そのもの」にフォーカスした名称に変更されています。

どんな問題か：
パスワードや個人情報を適切に暗号化せず保存・通信している状態です。

具体例：
・パスワードをMD5でハッシュ化して保存している（MD5は現在解読可能）
・HTTPで氏名や住所を送信している
・古いTLSバージョン（TLS 1.0/1.1）を使い続けている

対策：
・パスワードはbcryptまたはArgon2など耐久性のある専用ハッシュ関数で保存する
・全通信をHTTPS（TLS 1.2以上）に限定する
・不要な個人データは保持しない（データを持たなければ漏洩しない）

3. A03: インジェクション（Injection）

2017年版では1位でしたが、2021年版では3位に。SQLインジェクションを筆頭に、コマンドインジェクション・LDAPインジェクションなど多様な形態を含みます。

どんな問題か：
アプリケーションが信頼できない入力データをコマンドやクエリとして処理してしまう問題です。

具体例：
・ログインフォームに ' OR '1'='1 を入力して認証を回避するSQLインジェクション
・ファイル名入力欄にシェルコマンドを仕込むOSコマンドインジェクション

対策：
・プリペアドステートメント（パラメータ化クエリ）を使い、SQLを直接文字列結合で組み立てない
・入力値のバリデーションとエスケープ処理を徹底する
・WAF（Webアプリケーションファイアウォール）で既知のインジェクションパターンをブロックする

4. A04: 安全でない設計（Insecure Design）

2021年版で新たに追加されたカテゴリです。実装のミスではなく、「設計段階でセキュリティが考慮されていない」という、より根本的な問題を指します。

どんな問題か：
脅威モデリングやセキュリティ要件を設計時に考慮していないため、後から修正が困難なリスクが構造として生まれる状態です。

具体例：
・パスワードリセット機能で「秘密の質問」だけで本人確認している
・業務フローで本来あってはならない処理順序（例：支払い確認前の出荷）を防ぐチェックがない

対策：
・開発初期から脅威モデリング（何を守るか・攻撃経路は何か）を実施する
・セキュアデザインの原則（最小権限・多層防御・フェイルセーフ）をアーキテクチャに組み込む

5. A05: セキュリティの設定ミス（Security Misconfiguration）

実際の侵害で最も頻繁に見られる原因の一つです。クラウドサービスやコンテナ環境の普及により、設定ミスの機会が格段に増えています。

どんな問題か：
デフォルト設定のまま運用したり、不要な機能を有効にしたりしている状態です。

具体例：
・S3バケットを誤ってパブリック公開状態にしている
・管理画面のデフォルトパスワード（admin/admin）を変更していない
・本番環境でデバッグモードが有効のまま、スタックトレースが外部に露出している

対策：
・デプロイ前に設定値を自動チェックするパイプラインを組む
・不要なポート・サービス・機能はすべて無効化する
・定期的に設定監査を実施し、意図しないパブリック公開がないか確認する

6. A06: 脆弱で古くなったコンポーネント（Vulnerable and Outdated Components）

OSS・フレームワーク・ライブラリの更新遅延は、情シス担当者が最も直接的に対処できるリスクです。

どんな問題か：
既知の脆弱性が修正されていない古いコンポーネントを使い続けることで、公開された攻撃手法で容易に侵害される状態です。

具体例：
・Log4Shell（CVE-2021-44228）のような重大脆弱性が公開された後も、対象のLog4jを更新していない
・WordPressプラグインを長期間放置している

対策：
・使用しているコンポーネントの一覧（SBOM：ソフトウェア部品表）を管理する
・CVSSスコア7.0以上の重大脆弱性は72時間以内の対応ルールを設ける
・不要なプラグインやライブラリは削除する（使わないコンポーネントは脆弱性リスクになる）

7. A07: 識別と認証の失敗（Identification and Authentication Failures）

旧称は「認証の不備（Broken Authentication）」。2017年版の2位から7位に下がりましたが、依然として重要なカテゴリです。

どんな問題か：
認証・セッション管理に欠陥があり、攻撃者がアカウントの乗っ取りや偽装をできてしまう状態です。

具体例：
・ブルートフォース攻撃（総当たり）を試みてもアカウントがロックされない
・「password123」のような弱いパスワードが登録を通過してしまう
・多要素認証（MFA）が実装されていない管理画面

対策：
・多要素認証（MFA）を導入する
・ログイン失敗回数に上限を設けてブルートフォースをブロックする
・パスワード強度ポリシーを強制し、過去に漏洩したパスワードリストと照合する

8. A08: ソフトウェアとデータの整合性の不具合（Software and Data Integrity Failures）

2021年版で新しく追加されたカテゴリで、CI/CDパイプラインやアップデート機構への攻撃（サプライチェーン攻撃）を含みます。

どんな問題か：
ソフトウェアの更新・設定変更・パイプラインが改ざん検証なしに信頼されてしまう状態です。

具体例：
・信頼されていないCDNからJavaScriptを読み込み、改ざんされたコードを実行してしまう
・シリアライズデータの整合性を検証せず、悪意ある入力でサーバーに任意コードを実行させる

対策：
・外部スクリプトにはサブリソース整合性（SRI: Subresource Integrity）ハッシュを設定する
・CI/CDパイプラインの各ステップで署名検証を実施する
・デシリアライズ処理は信頼できるソースからのデータのみに限定する

9. A09: セキュリティログ記録とモニタリングの失敗（Security Logging and Monitoring Failures）

攻撃を受けても気づけない状態が、この項目が指すリスクです。侵害を検出するまでの平均日数は200日以上と言われており、この問題の深刻さを物語っています。

どんな問題か：
ログが記録されていない、または記録されていても誰も見ておらず、侵害が長期間気づかれない状態です。

具体例：
・ログイン失敗を記録していないため、ブルートフォース攻撃を見逃している
・高額決済などの重要イベントに対するアラートが設定されていない
・ログを攻撃者がアクセスできる同一サーバーに保存している（改ざんリスク）

対策：
・認証失敗・権限エラー・入力検証失敗などのセキュリティイベントをすべてログに記録する
・ログは別サーバーまたはSIEM（セキュリティ情報・イベント管理）システムに集約する
・疑わしいパターン（短時間での大量ログイン失敗など）にはリアルタイムアラートを設定する

10. A10: サーバーサイドリクエストフォージェリ（SSRF）

2021年版で新たにTop 10入りしたカテゴリです。クラウドインフラが普及した現代において、特に危険度が高まっています。

どんな問題か：
攻撃者がWebアプリを踏み台にして、内部ネットワークやクラウドのメタデータAPIに対してリクエストを送れてしまう状態です。

具体例：
・Webアプリが外部URLを取得する機能があり、AWSのインスタンスメタデータAPIのURLを指定することで、IAMロールのクレデンシャルが取得できる
・内部サービスに対してアプリサーバー経由でリクエストを送り、ファイアウォールをバイパスする

対策：
・外部URLを取得する機能では、許可リストでアクセス先を制限する
・メタデータAPIへのアウトバウンド通信をネットワーク層でブロックする
・AWSではIMDSv2（Instance Metadata Service v2）を使用し、トークンなしのアクセスを無効化する

2017年版からの主な変更点

2021年版は2017年版から大きく再編されています。概要を整理しておきましょう。

変更内容	2017年版	2021年版
最大リスク	A01: インジェクション	A01: アクセス制御の不備
新追加	—	安全でない設計（A04）、ソフトウェア整合性の不具合（A08）、SSRF（A10）
統合・吸収	XXE（A04）、CSRF（A8）	インジェクション（A03）に統合
名称変更	機密データの露出	暗号化の失敗（原因にフォーカス）

CSRFとXXEが独立した項目から外れたことに驚く方もいるかもしれませんが、これらの脅威がなくなったわけではありません。インジェクションというカテゴリにまとめられた形です。現場での対策は引き続き必要です。

中小企業でも今日からできること

OWASP Top 10の全項目を一度に対応するのは現実的ではありません。情シス1人体制の中小企業であれば、まず以下の5点から着手することを推奨します。

・① 多要素認証（MFA）の導入（A07対策）： VPN・管理画面・クラウドコンソールへのログインにMFAを設定するだけで、パスワード漏洩による被害を大幅に抑えられます。Google Authenticatorなど無料ツールで今日から始められます。
・② WordPressや使用CMSの定期更新（A06対策）： プラグイン・テーマ・コアの更新を週1回確認する習慣をつけるだけで、既知脆弱性の大半をカバーできます。
・③ 管理画面のデフォルトパスワード変更（A05対策）： ルーター・NAS・管理ツールの初期パスワードを変更します。これだけで侵害の入口の多くを塞げます。
・④ 重要システムへのログイン失敗ログの確認（A09対策）： 週1回でもよいので、不審なログイン試行がないか確認する習慣をつけましょう。クラウドサービスであれば管理コンソールのアラート機能を有効化します。
・⑤ HTTPSの徹底（A02対策）： 自社Webサイトやツールが全てHTTPSで通信しているか確認します。Let’s Encryptで無料取得できます。

よくある誤解と注意点

「OWASP Top 10を全部対応すれば安全になる」は誤り
OWASP Top 10はWebアプリケーションのリスクに特化したリストです。フィッシング詐欺・ランサムウェア・内部不正・物理的な情報漏洩といった脅威はカバーされていません。あくまで「Webアプリセキュリティの出発点」として位置づけましょう。

「開発者だけが対応すればいい」は誤り
A05（設定ミス）・A06（古いコンポーネント）・A09（ログ監視）は、開発者ではなく運用担当者が主体で対応すべき項目です。セキュリティは開発と運用が連携して初めて機能します。

「最新版（2021）だから旧版は無視していい」は誤り
2017年版にあったCSRF・XXEは依然として実際の攻撃で使われています。2021年版でTop 10から外れたのは「別の脅威が相対的に増えた」からであり、脅威自体が消えたわけではありません。

本記事のまとめ

No.	リスク名	代表的な対策
A01	アクセス制御の不備	サーバー側権限チェック・デフォルト拒否設計
A02	暗号化の失敗	強力ハッシュ（bcrypt）・HTTPS強制
A03	インジェクション	プリペアドステートメント・WAF
A04	安全でない設計	脅威モデリング・セキュアデザイン原則
A05	セキュリティの設定ミス	設定監査・不要機能の無効化
A06	脆弱で古いコンポーネント	SBOM管理・定期アップデート
A07	識別と認証の失敗	MFA導入・ブルートフォース対策
A08	ソフトウェア整合性の不具合	SRI設定・CI/CD署名検証
A09	ログ記録とモニタリングの失敗	ログ集約・リアルタイムアラート
A10	SSRF	許可リスト・IMDSv2強制

OWASP Top 10は「覚えるもの」ではなく「参照するもの」です。脆弱性が報告されたとき・新しいシステムを導入するとき・開発チームとセキュリティ要件を議論するとき、このリストを手元に置いておくだけで、対話の質が変わります。

まず今日、自社システムでA05（設定ミス）とA06（古いコンポーネント）の確認から始めてみてください。この2項目は、ツールや予算がなくても、情シス担当者1人で対処できます。

Linuxサーバーのアクセス権限管理やログ設定については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。Webアプリのセキュリティと合わせて、インフラ側の対策も整えておきましょう。