ServiceDock
2026年8月16日 更新
約6分で読めます
自分の作ったサービスにセキュリティ対策を入れようとして、まずOWASP Top 10を開く。1位から順にメモを取り、10項目のチェックリストを作る——多くの人がここから始めます。そのチェックリストは、作った瞬間から目的とずれています。
OWASP Top 10:2025で1位のBroken Access Controlは、検査されたアプリの3.73%でしか見つかっていません。逆に、データ上の出現が最も少ないカテゴリが3位に入っています。この順位は「遭遇しやすい順」ではないからです。では何の順なのか。答えは公式の方法論のページに書かれています。
順位を出現率だと読むと優先順位を間違える。データ上の出現が最少のカテゴリが3位に入っており、10個のうち2つはデータではなく投票で決まっている。
OWASP Top 10の順位がどう決まるかは、公式が方法論の節で明言しています。“remains data-informed, but not blindly data-driven”。データに基づくが、盲目的にデータ駆動ではない——この一文が順位の性格を決めています。
具体的な手順はこうです。貢献されたデータで12カテゴリを順位付けし、そのうち2つをコミュニティ調査の回答で押し上げる。つまり10項目のうち2つは、測定結果ではなく現場の実務者による投票で入っています。
併用の理由も公式に書かれています。データを見ることは本質的に過去を見ることであり、新しい弱点を大規模に検査できるようになるまでには数年かかる、という説明です。検査ツールが対応していない脅威は、どれだけ実在してもデータに現れません。
この構造がそのまま表れているのがA03です。ソフトウェアサプライチェーンはデータ上の出現が10カテゴリで最も少ないのに3位に入っています。公式は理由を、コミュニティ調査で最大の懸念として票を集めたこと、そしてCVEから算出した平均の攻撃容易性と影響度が10カテゴリで最も高いことだと説明しています。
順位は横軸だけでは決まらない。A03は出現率が10カテゴリで最少なのに3位。出現率で優先順位を組むと、最も影響の大きい領域を後回しにする。
順位はあくまで全体の平均像です。決済を持たないサービスにとってのA04（暗号化の不備）と、カード情報を扱うサービスにとってのA04では、同じ4位でも意味がまったく違います。順位を自分の優先順位として輸入しない——これが編集部の見立てです。使うべきは順位ではなく分類の方です。
This installment of the Top Ten remains data-informed, but not blindly data-driven. We ranked 12 categories based on the data contributed, and allowed two to be promoted or highlighted by responses from the community survey.出典OWASP Top 10:2025「Introduction」Methodology 節 一次情報を確認2026-08-16 この内容の有効期限2027-02-16
8回目の改訂で新設されたのはサプライチェーンと例外条件。SSRFは独立カテゴリをやめてアクセス制御に吸収された。名前の変更にも意図がある。
OWASP Top 10:2025は8回目の版です。分析対象は約17.5万件のCVE記録で、2021年版の約12.5万件から増えました。マッピングされたCWEは589個に及び、そのうち248個が10カテゴリに収まっています。
| 順位 | カテゴリ | 2021年版から | 含まれるCWE数 |
|---|---|---|---|
| A01 | Broken Access Control（アクセス制御の不備） | 1位を維持・SSRFを統合 | 40 |
| A02 | Security Misconfiguration（設定不備） | 5位から上昇 | 16 |
| A03 | Software Supply Chain Failures（サプライチェーン） | 新設（旧A06を拡張） | 5 |
| A04 | Cryptographic Failures（暗号化の不備） | 2位から下降 | 32 |
| A05 | Injection（インジェクション） | 3位から下降 | 38 |
| A06 | Insecure Design（安全でない設計） | 4位から下降 | — |
| A07 | Authentication Failures（認証の不備） | 7位を維持・改称 | 36 |
| A08 | Software or Data Integrity Failures（完全性の不備） | 8位を維持 | — |
| A09 | Security Logging & Alerting Failures（ログと通知） | 9位を維持・改称 | — |
| A10 | Mishandling of Exceptional Conditions（例外条件の扱い） | 新設 | 24 |
2021年版で10位だったSSRF（Server-Side Request Forgery）は、独立したカテゴリではなくなりA01に統合されました。公式は改訂の方針を「症状より根本原因に焦点を当てる」と説明しています。サーバーに意図しない宛先へリクエストさせる問題を、アクセス制御の失敗の一種として扱い直したということです。
同じ考え方は改称にも表れています。A09は「Logging and Monitoring」から「Logging & Alerting」へ変わりました。理由は明快で、通知のない優れたログは、インシデントの特定にほとんど価値がないという判断です。記録することと気づくことは別だ、という指摘になっています。
新設のA10は、不適切なエラー処理・論理エラー・フェイルオープンなど、システムが異常な状態に置かれたときの振る舞いを24個のCWEでまとめたものです。攻撃そのものではなく失敗したときにどう倒れるかが独立した観点になりました。
アクセス制御を実装するなら、A01の具体的な失敗例を知っておくと役に立ちます。当メディアではIDOR（安全でない直接オブジェクト参照）とCSRFを個別に解説しています。どちらもA01と隣接する領域です。
A01:2025 - Broken Access Control maintains its position at #1 as the most serious application security risk; the contributed data indicates that on average, 3.73% of applications tested had one or more of the 40 Common Weakness Enumerations (CWEs) in this category.出典OWASP Top 10:2025「Introduction」What's changed 節 一次情報を確認2026-08-16 この内容の有効期限2027-02-16
10項目を潰す作業に変換せず、自分の機能を10カテゴリへ割り当てる。1つも該当機能が書けないカテゴリが、検討していない領域を指している。
OWASP Top 10を実務で使う方法は、上から順に対策する形にはなりません。10カテゴリは248個のCWEを束ねた分類であって、検査項目の一覧ではないからです。使い道は分類器として使うことにあります。
この順番が重要です。カテゴリから始めると一般論の対策メモになりますが、機能から始めると自分のコードの話になります。空白行が出たときに初めて、そのカテゴリの詳細ページを読む価値が生まれます。
どこから着手するか迷うなら、A01のアクセス制御が最初の候補です。認証（本人確認）を実装した直後は、ログイン済みであれば誰のデータでも触れる状態になりがちで、認可（権限確認）の実装が抜けやすい箇所だからです。
確認の方法は単純で、自分のアカウントでログインした状態のまま、URLやAPIのIDを他人のものに書き換えて叩くだけです。データが返ってきたらA01に該当します。この検証はIDORの記事で具体的な手順を扱っています。
分母は常に10。割り当てただけの数ではなく、実際にコードを見た数で計算する。割り当てと確認の差が、そのまま未着手の量になる。
この作業の成果は対策の実装ではなく、10行の表が埋まることだと編集部は考えています。「A03は依存パッケージがnpmの公式レジストリのみ、ビルドはGitHub Actions、該当あり」と書ける状態と、空欄のまま放置されている状態では、次に何を調べるべきかの見え方が変わります。空欄は無害ではなく、単に見ていない場所です。
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る