OWASP Top 10とは何ですか？

Webアプリケーションセキュリティの非営利組織OWASPが定期的に公開する、最も重要なWebセキュリティリスクのトップ10リストです。開発者・セキュリティ担当者が優先的に対処すべきリスクをまとめており、最新版は2021年版です。

OWASP Top 10（2021）の1位は何ですか？

A01: アクセス制御の不備（Broken Access Control）です。認可が適切に実装されておらず、権限のないリソースにアクセスできてしまう問題です。2017年版の5位から1位に上昇し、94%のアプリで何らかの形で確認されています。

OWASP Top 10のA02：暗号化の失敗とは何ですか？

機密データを適切に保護しないリスクです。平文での通信・弱い暗号アルゴリズムの使用・秘密鍵の不適切な管理・平文でのパスワード保存などが含まれます。個人情報・クレジットカード情報・パスワードの取り扱いで特に注意が必要です。

OWASPはどのくらいの頻度で更新されますか？

数年に一度更新されます。現在の最新版は2021年版、その前は2017年版です。次のバージョンの策定作業が継続的に行われています。毎年変わるわけではありませんが、業界のトレンドと脅威の変化を反映して改定されます。

OWASP Top 10に対応するにはどこから始めればよいですか？

まず既存のシステムで各リスクが存在しないかを確認するセキュリティレビューから始めます。A01（アクセス制御）・A02（暗号化）・A03（インジェクション）は影響が大きいため優先度が高いです。OWASPが公開する無料のチートシートやテストガイドが参考になります。

OWASP Top 10 入門 - Webアプリの主要セキュリティリスクを解説

OWASP Top 10 とは

OWASP（Open Worldwide Application Security Project）は Web アプリケーションセキュリティのオープンコミュニティで、ボランティアによって運営されています。彼らが数年に一度公開する Top 10 は、世界中の脆弱性データを集計して「実務で本当に多発している Web リスクの上位10カテゴリ」を示したもので、事実上の業界標準として ISO 27001 や PCI DSS の参照資料にも組み込まれています。

本記事では、最新版である OWASP Top 10 - 2021 の10項目を初学者向けに俯瞰します（次版は2025〜2026年中に出る見込み）。各項目には「何が問題か」「典型例」「対策の要点」を1セクションずつ。

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

前回（2017）から1位に躍進した、現在最も多発しているカテゴリです。「ログインしているユーザー X が、ユーザー Y のデータを閲覧/編集できてしまう」が典型。

URL の /users/123/profile の 123 を 456 に変えると他人のページが見える（IDOR）
管理画面 /admin がリンク無いだけで認証チェックされていない
API で「自分のデータだけ返す」ロジックを忘れて全件返してしまう

対策の要点: 「URL に出てる ID は信用しない」が鉄則。すべての操作で「セッション上のユーザーがそのリソースに権限を持つか」をサーバ側で必ず確認。デフォルト拒否、ホワイトリスト方式、ログ監査。

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

2017 年版では「機密データの露出」だったカテゴリ。原因が「適切な暗号化が無い／弱い」に絞られ改名。

ログインページが HTTP（盗聴可能）
パスワードを MD5 や SHA-1 で生のハッシュ保存（GPU で即時総当たり）
古い TLS 1.0 / 1.1 で運用
独自暗号アルゴリズム（ほぼ確実に弱い）

対策の要点: 通信は TLS 1.2 以上必須 + HSTS。パスワード保存は bcrypt / scrypt / Argon2。一般データ暗号化は AES-GCM 等の認証付き暗号。「自作するな、標準ライブラリを使え」。

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

SQL インジェクション、コマンドインジェクション、LDAP インジェクション、そして XSS もこのカテゴリに統合されました。共通点は「ユーザー入力を、別の言語の構文として解釈する場所にそのまま流し込んだ」こと。

SQLi: "SELECT * FROM users WHERE id = " + req.query.id
OS コマンド: exec("ping " + req.query.host)
XSS: html = "<p>" + userInput + "</p>"

対策の要点: パラメータ化クエリ（プリペアドステートメント）と出力時エスケープ。「文字列連結で組み立てない」が原則。ORM、テンプレートエンジンを通すこと。

本サイトを作りながら実感したのは、セキュリティツール系のサイトは「ユーザーが入力した値そのものが攻撃用の文字列になり得る」点で一般的な Web サイトと少し事情が違うということです。JSON 整形ツールや Regex テスターのように入力をそのまま画面に表示するツールでは、「自分専用のツールならそこまで気にしなくても」と思いかけたこともありましたが、公開サイトである以上は入力値を HTML として解釈させない・必要に応じてエスケープすることを、機能を1つ作るたびに意識するようになりました。

実際に <script>alert(...)</script> のような文字列を各ツールの入力欄に試しに入れてみて、意図せず HTML として解釈されないかを確認する習慣もつきました。本サイトは React（JSX）で作られているため、変数をそのまま表示する分には基本的に自動でエスケープされますが、それを知って「React だから XSS は大丈夫」と一瞬油断しかけたこともあります。dangerouslySetInnerHTML のような自動エスケープを外す仕組みを使えば話は別ですし、外部の HTML を扱う場面では別途注意が必要です。「フレームワークがどこまで守ってくれて、どこから先は自分の責任か」を線引きして意識するようになったのは、A03 を実際に自分のサイトに当てはめて考えた結果です。

関連: XSS の基礎と防御 · SQL インジェクション

A04: Insecure Design（セキュアでない設計）

2021 年版で新設。コーディングミスではなく 設計段階で抜けている脅威を扱います。

パスワードリセットを「秘密の質問」だけで通す（Q&A は公開情報になりがち）
レート制限なしで「年齢確認」だけで子供アカウント作成可
無料試用を電話番号で識別 → SMS の使い捨て番号で無限取得可

対策の要点: 設計レビューに 脅威モデリング（STRIDE 等）を組み込む。ビジネス要件と一緒に「悪用シナリオ」も列挙する。実装前に「この機能を悪用されたら何が起きるか」を必ず議論。

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

コードは正しいのに、サーバ・フレームワーク・クラウドの設定で穴を開けてしまうカテゴリ。

本番にデバッグモードが有効でスタックトレースが出ている
S3 バケットがパブリック公開
不要なサービス（管理ポート、デフォルト管理者アカウント）が開いたまま
CSP / HSTS / X-Frame-Options 等のセキュリティヘッダ未設定

対策の要点: 「最小権限」「不要なものは無効化」。Infrastructure as Code（Terraform 等）で設定を版管理し、定期スキャンで逸脱検出。本サイト自身も securityheaders.com で A 評価を維持しています。

実際に CSP などのセキュリティヘッダーを自分で設定してみると、「厳しくすればするほど安全」という単純な話ではないと感じます。本サイトも現状は CSP で unsafe-inline を許容して A 評価にとどめており、A+ 相当にするには nonce/hash 方式へ切り替える必要がありますが、それは静的化のメリットとのトレードオフです。セキュリティ設定はサイトの機能や外部サービスとの兼ね合いを見ながら決めるものだと、手を動かして初めて実感しました。実際に一度厳しめの CSP を試して外部スクリプトの読み込みがブロックされ、ブラウザのコンソールに違反エラーが並んだこともあります。「セキュリティを強くしただけなのにサイトが壊れるのか」と感じたその経緯は、HTTP セキュリティヘッダー詳解の方に詳しくまとめています。

A06: Vulnerable and Outdated Components（古い・脆弱なコンポーネント）

Apache Struts の脆弱性で Equifax が 1.5 億人分の個人情報を流出させた事件が代表例。使っているライブラリ・OS・フレームワークが脆弱なまま放置されているケース。

対策の要点: SBOM（依存リスト）の管理と自動アップデート。GitHub なら Dependabot、Node なら npm audit、Python なら safety、コンテナイメージは Trivy / Snyk でスキャン。本サイトも Dependabot + npm audit を CI に組み込み済みです。

関連: サプライチェーン攻撃の6類型と防御

A07: Identification and Authentication Failures（識別・認証の失敗）

旧「Broken Authentication」。ログイン・セッション管理周りの脆弱性全般。

クレデンシャルスタッフィング（漏洩パスワード辞書での総当たり）に無防備
セッション ID が予測可能 / URL に出ている
パスワードリセットで脆弱なトークン
多要素認証なし

対策の要点: 強いパスワードポリシー + 漏洩パスワードチェック（HIBP API）、レート制限・アカウントロック、TOTP / FIDO2 (Passkey) による MFA、セッション ID は cryptographically random。

A08: Software and Data Integrity Failures（整合性の検証不足）

2021 年版で新設。サプライチェーン攻撃と CI/CD パイプラインへの注目で追加されました。

npm パッケージを署名検証なしで取得（依存パッケージ乗っ取りで RCE）
CDN から JS を読み込むが SRI（Subresource Integrity）未設定で改ざん検出不可
署名なしオートアップデート（SolarWinds 事件型）
シリアライズデータの逆シリアライズで任意コード実行

対策の要点: ライブラリは lockfile + ハッシュ検証、外部スクリプトは SRI、デプロイは署名済みアーティファクト。逆シリアライズは信頼できる入力のみ。

A09: Security Logging and Monitoring Failures（ロギング・監視の不足）

実際に侵害が起きても気付けない、調査できない問題。検知までの平均日数（MTTD）は業界平均で 200 日以上と言われています。

ログイン失敗・権限拒否・入力バリデーションエラーが記録されていない
ログが平文で書かれパスワードまで含む
アラートがそもそも設定されていない

対策の要点: 認証・権限・入力検証・サーバ側エラーは必ず記録。中央集約型のログ基盤（ELK / CloudWatch / Datadog）と異常検知。インシデント対応プレイブックを事前に用意。

関連: インシデント対応の進め方

A10: Server-Side Request Forgery（SSRF）

2021 年版で新設。「サーバ側で URL を取得しに行く機能」を悪用される攻撃。クラウド時代の代名詞的な脆弱性です。

// プレビュー機能で任意URLをfetch
const url = req.body.url
const html = await fetch(url).then(r => r.text())

攻撃者が http://169.254.169.254/latest/meta-data/iam/security-credentials/（AWS インスタンスメタデータ）を渡すと、サーバは内部ネットワークから一時クレデンシャルを取得して返してしまいます（Capital One 事件型）。

対策の要点: URL ホワイトリスト、内部ネットワーク・IMDS への接続をファイアウォールで遮断、IMDSv2 強制、HTTP リダイレクト追跡しない / 追跡先も検証。

使い方: チェックリストとして

OWASP Top 10 は「これだけ守れば安全」というリストではない点に注意。あくまで「最頻出のカテゴリ」であって、業界・サービス特性によっては他のリスクが上回ることも普通にあります。とはいえ、新規プロジェクトの設計レビューや既存システムの自己診断には最良の出発点。

実務での使い方の例：

新機能の設計時、10項目をチェックリストで通す
外部監査・ペネトレ依頼前のセルフチェック
セキュリティ研修の構成テンプレ
SOC 2 / ISO 27001 等のコンプライアンス文書の参照

おわりに

OWASP Top 10 はWebセキュリティの共通言語。エンジニア・PM・経営層が同じ用語で会話するために整備されているとも言えます。各項目を深掘りした記事は本サイトの Learn に順次追加していくので、関連記事リンクから掘り下げてみてください。