OWASP Top 10 2025（最新版）の10項目と2021年版からの変更点｜公式日本語訳と移行手順

OWASP Top 10の最新版は、2025年に公開された「OWASP Top 10:2025」です。2003年の初版から数えて第8版にあたります。2025年11月6日にリリース候補（RC）として公開され、2025年12月24日（UTC）に公式リポジトリでRC表記が外れて正式版になりました。この記事では、2025年版の10項目と公式日本語名、2021年版からの変更点を整理します。あわせて、2021年版を前提にした報告書や診断ツールの設定を2025年版へ移す手順、スコア表の読み方、社内の開発基準や診断のチェックリストに使うときの限界も説明します。OWASPという団体そのものについてはOWASPの読み方と組織の実体の解説を参照してください。

まとめ：OWASP Top 10 2025年版の要点

• 2026年10月時点の最新版は2025年版です。2021年版を前提にした社内資料や診断報告書は、項目番号が変わっているので読み替えが必要です。
• 新設は2つです。A03「ソフトウェアサプライチェーンの不備」は2021年版A06の範囲をビルドや配布の経路まで広げたもので、A10「例外的な状況への不適切な対応」はエラー処理の失敗とフェイルオープンを扱います。
• 2021年版A10のSSRFは独立項目ではなくなり、A01「アクセス制御の不備」に統合されました。A02「セキュリティ設定の不備」は5位から2位に上がっています。
• 公式日本語訳は2026年7月から公式サイト（top10.owasp.org/2025/ja/）で読めます。2021年版の訳語の「失敗」「不具合」「設定ミス」は「不備」に置き換わりました。
• 2021年版で対応付けられていたCWEのうち32件は、2025年版のどの項目にも入っていません。ZAPとSemgrepは2025年版の分類を追加済みですが、2021年版の分類も残しているので、報告書の「A03」がどちらの版かを必ず確かめてください。
• 10項目のうち8つは280万件超のアプリケーションの検査データから、2つはコミュニティ調査の投票から選ばれています。順位は発生率の順ではありません。
• OWASP自身がTop 10を「最低限の出発点」と位置付けています。開発基準や診断範囲の根拠にするなら、検証可能な要件として作られたASVSを使います。

OWASP Top 10 2025年版の10項目と公式日本語名

2025年版の10項目を、公式日本語訳の名称と2021年版での位置つきで示します。CWE数は各項目のページ末尾にある対応CWE一覧を数えた値です。

公式日本語訳の入手先と訳語の変更

日本語訳はOWASP Japanのメンバーが別リポジトリ（owasp-ja/Top10）で進めていたもので、2026年7月12日（UTC）のコミット「Activate Japanese Translation」で公式サイトに組み込まれました。現在は top10.owasp.org/2025/ja/ で各項目の説明・防止方法・攻撃シナリオまで日本語で読めます。Markdownの原文は公式リポジトリ（OWASP/Top10）の 2025/docs/ja/ にあります。

2021年版の日本語訳から名称がかなり変わっており、社内資料で旧訳を使っていると検索や読み替えで取りこぼしが出ます。

• 「暗号化の失敗」「識別と認証の失敗」「セキュリティログとモニタリングの失敗」の「失敗」は「不備」になりました。
• 「安全が確認されない不安な設計」は「安全性を欠いた設計」に、「セキュリティの設定ミス」は「セキュリティ設定の不備」になりました。
• 「ソフトウェアとデータの整合性の不具合」は「ソフトウェアまたはデータの完全性の不備」です。英語名も「and」から「or」に変わっています。

2021年版からの変更点：新設2項目とSSRFの統合

公式の序文は、2025年版の変更を「2つの新カテゴリと1つの統合」と説明しています。順位の入れ替わりは、A02（設定の不備）とA03（サプライチェーン）が上がった分、2021年版で2〜4位だった暗号化・インジェクション・安全でない設計がそれぞれ2つずつ下がった結果です。

A03 ソフトウェアサプライチェーンの不備の対象範囲

A03は、2021年版A06「脆弱で古くなったコンポーネント」を拡張した項目です。2021年版は「既知の脆弱性がある部品を使っている」ことが中心でしたが、2025年版は依存関係に加えて、ビルドシステム、CI/CDパイプライン、開発者のIDE、成果物リポジトリ、コンテナレジストリまで対象にしています。コミュニティ調査では、回答者のちょうど50%がこの項目を1位に挙げました。

攻撃シナリオには、約18,000組織に影響したSolarWinds侵害（2019年）、ウォレットソフトウェアへのサプライチェーン攻撃で15億ドルが盗まれたBybitの事件（2025年）、npmで初めて自己増殖したワーム「Shai-Hulud」（2025年、500以上のパッケージバージョンに到達）が挙がっています。Shai-Huludは開発者の端末にあるnpmトークンを使って拡散したため、開発者自身が攻撃対象になることを示した例として扱われています。

防止方法で2021年版から増えたのは次の点です。

• SBOM（ソフトウェア部品表、Software Bill of Materials）をソフトウェア全体で一元的に生成・管理し、推移的な依存関係まで追跡する
• OWASP Dependency-Trackなどで構成を継続的に棚卸しし、CVE・NVDに加えてOSV（Open Source Vulnerabilities）を監視する
• 全システムへ一斉に更新を配らず、段階的リリースやカナリアデプロイでベンダー侵害時の被害を抑える
• 環境ごとに再ビルドせず、署名済みの同一成果物を昇格させる
• 一人でコードの記述から本番反映まで完結できる状態をなくす（職務分掌）

依存関係の検出を自動化する手段はSCA（ソフトウェア構成分析）とSBOMの違いの解説で、ビルド経路まで含めた防御の組み立てはサプライチェーンセキュリティを開発工程に組み込む方法で扱っています。

A10 例外的な状況への不適切な対応とフェイルクローズ

A10は24のCWEをまとめた新設項目で、エラー処理の不備、ロジックエラー、フェイルオープンを扱います。代表的なCWEはCWE-209（機密情報を含むエラーメッセージ）、CWE-476（NULLポインタ参照）、CWE-636（安全側に倒れない失敗）です。公式の説明は、異常な状況を「防止」できない、発生を「識別」できない、発生後の「応答」が不適切、の3つの失敗のうち1つ以上が関わるとしています。

攻撃シナリオの3番目は金融取引です。「送金元から引き落とす→送金先に入金する→記録する」の途中でネットワークを切断されたとき、全体をロールバックしなければ、残高の消失や二重送金が起こります。公式はこれを「フェイルクローズ」と呼び、途中から回復させようとせず全体を取り消すよう求めています。次のPythonコードで違いを確かめられます（標準ライブラリsqlite3のみを使用。Python 3.9.6と3.14.6で同じ出力になることを確認）。

import sqlite3

def setup():
    conn = sqlite3.connect(":memory:")
    conn.execute("CREATE TABLE account (id TEXT PRIMARY KEY, balance INTEGER)")
    conn.executemany("INSERT INTO account VALUES (?, ?)", [("alice", 1000), ("bob", 0)])
    conn.commit()
    return conn

def transfer_fail_open(conn, amount, fail):
    # 例外を握りつぶし、途中まで進んだ更新を確定させてしまう
    try:
        conn.execute("UPDATE account SET balance = balance - ? WHERE id = 'alice'", (amount,))
        if fail:
            raise ConnectionError("network error")
        conn.execute("UPDATE account SET balance = balance + ? WHERE id = 'bob'", (amount,))
    except ConnectionError:
        pass
    conn.commit()

def transfer_fail_closed(conn, amount, fail):
    # with ブロック内で例外が出ると、ブロック全体をロールバックする
    try:
        with conn:
            conn.execute("UPDATE account SET balance = balance - ? WHERE id = 'alice'", (amount,))
            if fail:
                raise ConnectionError("network error")
            conn.execute("UPDATE account SET balance = balance + ? WHERE id = 'bob'", (amount,))
    except ConnectionError as e:
        print("rollback:", e)

for fn in (transfer_fail_open, transfer_fail_closed):
    conn = setup()
    fn(conn, 300, fail=True)
    print(fn.__name__, dict(conn.execute("SELECT id, balance FROM account")))

transfer_fail_open {'alice': 700, 'bob': 0}
rollback: network error
transfer_fail_closed {'alice': 1000, 'bob': 0}

フェイルオープン側では、送金元から引かれた300がどこにも入金されずに消えています。例外を except ConnectionError: pass のように握りつぶして処理を続けるコードは、コードレビューでA10の指摘対象です。公式の防止方法には、ほかに次の項目があります。

• 例外は発生した場所で捕捉して処理し、見落とし用にグローバルな例外ハンドラーも置く
• エラー処理・ログ・監視・アラートは1か所に集約し、アプリケーション内で処理方法を統一する
• レート制限・リソース上限・スロットリングを設ける（公式訳は「情報技術において無制限なものは何一つあってはなりません」と書いています）
• 同じエラーが一定の頻度を超えたら、個々のメッセージではなく統計として出力することを検討する

SSRFのA01統合と順位の入れ替わり

2021年版で独立していたA10「サーバーサイドリクエストフォージェリ（SSRF）」は、2025年版ではA01に統合されました。CWE-918はA01の対応CWE一覧に入っています。2021年版のSSRFは対応CWEが1件だけの項目でした。サーバーが「どの宛先へリクエストしてよいか」の制御の失敗として、アクセス制御の中で扱う整理です。SSRFの仕組みとクラウドのメタデータ悪用はSSRFの防御実装の解説で、A01の中心であるIDORや権限昇格は認可バイパスの仕組みと対策で扱っています。

A02「セキュリティ設定の不備」が5位から2位に上がったのは、今回のデータで設定の不備の発生が増えたためです。公式は、アプリケーションの挙動が設定に依存する割合が増え続けている以上、驚くことではないとしています。XXE（CWE-611）やCookieのHttpOnly・Secure属性の欠如（CWE-1004・CWE-614）もA02に入っています。

A07とA09の名称変更の意味

A07は「Identification and Authentication Failures」から「Authentication Failures」になりました。順位は7位のままです。公式は、標準的な認証フレームワークの普及で発生が抑えられつつあるとしています。

A09は「Monitoring」が「Alerting」に置き換わりました。公式訳の序文には「アラートを伴わないログ出力には、インシデント特定においてほとんど価値がありません」とあります。ログを出しているだけでは足りず、対応につながる通知まで設計されているかが問われます。A09はデータに現れにくいため、今回もコミュニティ調査の投票で選ばれています。

正式版になった日付と最新版の確かめ方

2025年版は2025年11月6日にリリース候補（RC1）として公開され、フィードバックを受けて修正が入りました。公式サイトには正式版の日付が明記されていません。ただしGitHubの公式リポジトリ（OWASP/Top10）では、2025年12月24日（UTC、日本時間では25日早朝）に「Remove RC notice」「Removed RC from ttitle」「Removed RC」の3つのコミットが入り、RC表記が外れました。同じ日に、プロジェクトページのリポジトリ（OWASP/www-project-top-ten）でも「The most current released version」の表記が2021から2025に書き換わっています。「正式版は2026年1月」と書く解説もありますが、一次情報の日付は2025年12月です。

RC表記が外れた日には、A04への耐量子暗号の指針追加やA03への段階的リリースの指針追加もマージされました。RC版をもとに作られた資料は、この修正を含んでいない可能性があります。その後の英語原文の更新は誤字の修正（2026年1月と4月）だけで、翻訳ではドイツ語の追加とスペイン語の品質修正（いずれも2026年9月）が入っています。項目の構成を変える更新は、2026年10月31日時点で入っていません。

最新版かどうかは次の2か所で確かめられます。

• 公式サイト top10.owasp.org のトップに表示される版（現在は2025）
• GitHubの OWASP/Top10 リポジトリにある版ごとのディレクトリと、直近のコミット履歴

これまでの版は2003年、2004年、2007年、2010年、2013年、2017年、2021年、2025年の8つで、2010年以降は3〜4年おきです。次の版の時期は公表されていません。

スコア表の読み方と、順位と発生率のずれ

2025年版では、Accenture、Bugcrowd、Contrast Security、Semgrep、Sonar、Veracodeなど12の組織と複数の匿名の提供者から、280万件を超えるアプリケーションの検査データが集まりました。分析対象のCWEは2017年版の約30、2021年版の約400から、589に増えています。ここから12のカテゴリをデータで順位付けし、8つを採用しました。残り2つ（A03とA09）はコミュニティ調査の投票で選ばれています。

各項目のページにあるスコア表から主な値を抜き出すと、次のとおりです。

この表から読み取れることは3つあります。

1つ目は、A03の数字の偏りです。検査対象になった割合（カバレッジ）は27.47%と最も低い一方で、検査された場合の平均発生率は5.72%で10項目中最高です。ただしこれは提供された検査データの中での比較で、個々のシステムでの検出頻度を保証するものではありません。悪用のしやすさ（Exploit）と影響（Impact）の平均もどちらも最大ですが、これは関連するCVEがわずか11件から出した値です。公式は、データが少ないのはテストの難しさのためだと説明しています。検出件数が少ないことを理由に優先度を下げるのは誤りです。

2つ目は、順位と平均発生率が一致しないことです。6位のA06は平均発生率1.86%で最も低く、9位のA09は3.91%で上位にあります。順位は発生率に加え、悪用のしやすさと影響の評価、投票を合わせて決まっています。自社の診断件数だけでTop 10の順位を再現することはできませんが、検査範囲や事業への影響を併せて比較すれば、対策の優先順位を検討する材料になります。

3つ目は、CWE数の原文内の食い違いです。英語の序文はA03を5 CWE、A05を38 CWE、合計を248 CWEとしています。一方、各項目のスコア表と対応CWE一覧ではA03が6件（CWE-1357を含む）、A05が37件で、10項目の一覧を数えると重複なしで249件になります。A03の差は、2025年12月24日の更新「Update CVE statistics and add CWE-1357 reference」で一覧側だけにCWE-1357が足されたことで説明できます。A05は項目ページが公開当初から37件で、序文の38件との差の理由は原文にありません。ほかにも、A03の背景説明の平均発生率は更新前の5.19%のまま残っています。CWE単位で社内ツールと突き合わせるときは、序文ではなく各項目の一覧を正としてください。

10項目の中身と代表的なCWE

10項目すべての防止方法は公式日本語訳に載っています。各項目が何を扱うかを1行ずつまとめると次のとおりです。

• A01 アクセス制御の不備：権限外のデータや機能に届いてしまう問題。IDOR、権限昇格、CSRF、SSRFを含む
• A02 セキュリティ設定の不備：既定のアカウント、不要な機能、詳しすぎるエラー表示、クラウドの権限設定など
• A03 ソフトウェアサプライチェーンの不備：依存部品の脆弱性と、ビルド・配布経路の侵害
• A04 暗号化の不備：暗号化の欠如、弱いアルゴリズム、鍵の漏えい、予測可能な乱数
• A05 インジェクション：SQL・OSコマンド・XSSなど、入力がコードとして解釈される問題
• A06 安全性を欠いた設計：実装を正しくしても直らない、設計段階の欠陥
• A07 認証の不備：総当たりへの無防備、弱いパスワードの許容、セッション管理の欠陥
• A08 ソフトウェアまたはデータの完全性の不備：署名のない更新、信頼できないデータのデシリアライズ
• A09 セキュリティログとアラートの不備：攻撃を記録しない、記録しても誰にも通知されない
• A10 例外的な状況への不適切な対応：エラー時に安全側へ倒れない、機密情報を含むエラーを返す

代表的なCWEと押さえる点を表にまとめます。「2025年新規」の行が、2021年版の知識のままだと外す箇所です。

A04の防止方法は、2025年12月24日の更新で次のように書き換わりました。

• 通信の暗号化はTLS 1.2以上に限定し、CBC暗号スイートのサポートをやめる。STARTTLSも非暗号化プロトコルと同列に扱う
• パスワードの保存はArgon2、yescrypt、scrypt、PBKDF2-HMAC-SHA-512（更新前はSHA-256）とし、bcryptは既存システム向けの扱い
• 耐量子暗号（PQC）は「検討する」から、EU加盟国が欧州委員会の支援を受けて策定したPQC移行ロードマップを参照し、高リスクのシステムを遅くとも2030年末までに量子攻撃に耐えられる状態にするよう「今から準備する」に強まった

A05のインジェクションは、XSS（高頻度・低影響）からSQLインジェクション（低頻度・高影響）までを含み、37のCWE（序文では38）に関連するCVEの数は10項目中で最多です。XSSの多層防御はCSPのnonce方式によるXSS対策で扱っています。A06はA02とA03に追い越されて4位から6位に下がり、公式は脅威モデリングの普及による改善も指摘しています。進め方はSTRIDEによる脅威モデリングの手順を、A08の中心である安全でないデシリアライゼーションはデシリアライゼーションの言語別の防御実装を参照してください。

2021年版の報告書・ツール設定を2025年版へ移す手順

2021年版を前提に作った診断報告書のテンプレート、SASTやDASTの検出ルール、研修資料は、項目番号を付け替えるだけでは移せません。同じ「A03」が、2021年版ではインジェクション、2025年版ではソフトウェアサプライチェーンの不備を指すからです。移行は、CWE単位で読み替える作業と、ツールが付ける分類タグの版を確かめる作業の2段階で進めます。

公式CWE一覧による2021年版・2025年版の対応表作成

各項目のページ末尾にある「List of Mapped CWEs」は、公式リポジトリ（OWASP/Top10）にMarkdownで置かれています。次のスクリプトは2021年版と2025年版の一覧を読み込み、2021年版の各項目のCWEが2025年版のどこへ移ったかを数えます。標準ライブラリだけで動き、GitHub APIを認証なしで2回呼びます（1時間60回の制限内）。2026年10月31日にPython 3.9.6と3.14.6で実行し、同じ出力になることを確認しました。

import json
import re
import urllib.request
from collections import Counter

API = "https://api.github.com/repos/OWASP/Top10/contents/{}"
RAW = "https://raw.githubusercontent.com/OWASP/Top10/master/{}"


def get(url):
    req = urllib.request.Request(url, headers={"User-Agent": "cwe-map"})
    with urllib.request.urlopen(req, timeout=30) as r:
        return r.read().decode("utf-8")


def load(edition):
    # 公式リポジトリの各項目ページから「List of Mapped CWEs」を読み、CWE番号→項目の辞書を作る
    mapping = {}
    for f in json.loads(get(API.format(f"{edition}/docs/en"))):
        m = re.match(r"(A(?:0[1-9]|10))_" + edition, f["name"])
        if not m:
            continue
        text = get(RAW.format(f["path"]))
        section = text.split("List of Mapped CWEs", 1)[1]
        for cwe in re.findall(r"CWE-(\d+)", section):
            mapping.setdefault(int(cwe), f"{m.group(1)}:{edition}")
    return mapping


old, new = load("2021"), load("2025")
print("2021:", len(old), "CWE / 2025:", len(new), "CWE")

for cat in sorted(set(old.values())):
    cwes = [c for c, v in old.items() if v == cat]
    dest = Counter(new.get(c, "選外") for c in cwes)
    print(cat, len(cwes), "->", ", ".join(f"{k} {n}" for k, n in dest.most_common()))

for cwe in (918, 1104, 209, 352, 79):
    print(f"CWE-{cwe}: {old.get(cwe, '-')} -> {new.get(cwe, '-')}")

2021: 196 CWE / 2025: 249 CWE
A01:2021 34 -> A01:2025 28, 選外 6
A02:2021 30 -> A04:2025 26, 選外 3, A07:2025 1
A03:2021 33 -> A05:2025 26, 選外 7
A04:2021 40 -> A06:2025 29, 選外 8, A10:2025 3
A05:2021 20 -> A02:2025 14, 選外 5, A10:2025 1
A06:2021 3 -> A03:2025 2, 選外 1
A07:2021 21 -> A07:2025 19, 選外 2
A08:2021 10 -> A08:2025 10
A09:2021 4 -> A09:2025 4
A10:2021 1 -> A01:2025 1
CWE-918: A10:2021 -> A01:2025
CWE-1104: A06:2021 -> A03:2025
CWE-209: A04:2021 -> A10:2025
CWE-352: A01:2021 -> A01:2025
CWE-79: A03:2021 -> A05:2025

この出力から、移行で手を入れる箇所が3つ分かります。

• 2021年版A10（SSRF）の唯一のCWEだったCWE-918は、A01:2025に入っています。SSRFの検出結果を「A10」で集計している報告書は、2025年版では「A01」に寄せ直します。
• 2021年版A04（安全でない設計）からCWE-209・CWE-235・CWE-280の3件が、A05（セキュリティの設定ミス）からCWE-756が、新設のA10:2025へ移っています。エラーメッセージからの情報漏えい（CWE-209）を「設計」で数えていた場合、2025年版では例外処理の項目で数えます。
• 2021年版のCWEのうち32件は、2025年版のどの一覧にもありません。多くはCWE-264（権限・特権・アクセス制御）、CWE-310（暗号の問題）、CWE-937（2013年版A9の分類）のような、個別の弱点ではなく分類用のカテゴリ番号です。ツールがこうした番号で結果を出している場合、配下の個別CWEに展開しないと2025年版の項目に割り当てられません。逆に、2025年版で新たに一覧に入ったCWEは85件あります。

ZAP・Semgrepの2025年版タグ対応と確認手順

主要なOSSの検査ツールは2025年版の分類を追加済みですが、2021年版の分類も残しています。DASTのZAPは、共通ライブラリのアドオン「commonlib」1.40.0（2026年3月19日）で「OWASP_2025_A01」〜「OWASP_2025_A10」のアラートタグの定義を追加し（commonlibの変更履歴）、2026年4月14日の能動スキャンルール（ascanrules）81と受動スキャンルール（pscanrules）73で、各スキャンルールが実際にそのタグを付けるようになりました。ソースコード上では、2021年版の「OWASP_2021_A01」などのタグも同じ列挙型に並んでいます。SASTのSemgrepの公開ルール集では、2026年1月15日にマージされたAdd owasp 2025 mappingで、各ルールのメタデータに2025年版の分類が足されました。PHPのSSRF検出ルールには「A10:2021 – Server-Side Request Forgery (SSRF)」と「A01:2025 – Broken Access Control」が両方書かれています。

そのため、検出結果を「A10」や「A03」で絞り込むと、どちらの版のタグで数えたかによって件数がまったく変わります。移行のときは次の順で確かめてください。

1. 使っている検出ルールが2025年版のタグを付けるか（ZAPの安定版ルールならcommonlib 1.40.0以上に加え、ascanrules 81以上・pscanrules 73以上を確認）
2. 報告書のテンプレートやダッシュボードが、どちらの版のタグで集計しているか
3. 報告書や社内規程の項目番号を「A01:2025」「A03:2021」のように版つきで書いているか

商用の診断ツールの対応状況は製品ごとに違うため、各社のリリースノートで2025年版のマッピングの有無を確認します。社内で診断の体制を持てない場合は、脆弱性診断・セキュリティ診断を外部に依頼する方法もあります。

Top 10をチェックリストや診断基準に使うときの限界

Top 10を「セキュリティ診断の項目」や「開発標準」としてそのまま使う組織は多いのですが、OWASP自身はこの使い方に明確な線を引いています。2025年版の「今日求められるアプリケーションセキュリティ・プログラムの構築」には、Top 10とASVS（アプリケーションセキュリティ検証標準）の用途を比べた表があります。

理由は、Top 10が「テストしやすい問題」ではなく「リスク」を並べた文書だからです。公式は2つの例を挙げています。A06の安全でない設計は、ほとんどのテスト手法の対象外です。A09のログとアラートが実際に機能しているかは、インタビューと過去のインシデント対応の記録を見ないと判断できず、静的解析ツールで分かるのはログ出力の有無までです。

このため、次の2つは避けてください。

• 「OWASP Top 10に完全対応」をツール選定の決め手にする：公式は、ツールがTop 10を網羅的に検出・テスト・防御することはできず、完全対応をうたうのは「単に真実ではない」と明記しています。ツールベンダーが採るべき基準はASVSだけだとも書いています。
• 診断報告書の「Top 10該当なし」を安全の根拠にする：A06やA09のように自動検査で判定できない項目は、報告書に何も出てこなくても対策済みとは限りません。

社内の開発標準や受入基準を作るなら、ASVSの要件（安定版は2025年5月の5.0.0）を検証レベルごとに採用し、Top 10は開発者研修の入口に使う分担が現実的です。SASTやDASTで自動化できる範囲の見極めはSASTとDAST・SCAの違いとCI/CDへの組み込み、DASTツールの具体的な検出項目はZAPの診断項目の一覧で確認できます。OWASPの他のプロジェクトとの組み合わせ方はOWASPの主要プロジェクトと開発への組み込み方にまとめています。

選外になった3項目とAI生成コードへの言及

2025年版の「次の一手（Next Steps）」には、Top 10には入らなかったものの取り組む価値のある3項目が載っています。

• X01 アプリケーション・レジリエンスの欠如：2021年版で選外だった「サービス拒否」を、症状ではなく原因の名前に改めたものです。CWE-400（制御されないリソース消費）、CWE-409（高圧縮データの不適切な処理）、CWE-674（制御されない再帰）などが入り、スコアはA10と僅差でした。
• X02 メモリ管理の失敗：関連するCVEの数は3番目に多いものの、コミュニティ調査では最下位でした。公式はWebアプリケーションが中心のデータであるためと説明しています。
• X03 AI生成コードへの不適切な信頼（Vibe Coding）：2025年12月24日に追加されました。対応するCVEもCWEもまだ無いと明記したうえで、AIが生成したコードも含め「提出するコードはすべて自分で読んで理解できなければならない」「複雑な機能、業務上重要なプログラム、長く使うプログラムでのVibe Codingは推奨しない」としています。

X03の防止方法には、社内のセキュアコーディング規約を入れたRAGサーバーの利用、IDEとAIの間にMCPサーバーを置いてセキュリティツールの実行を強制する方法、シャドーAIの利用を技術的に検知する仕組みまで挙がっています。AIコーディングツールを導入済みのチームは、X03の防止方法をコードレビューやツール利用規程の見直しに使い、生成されたコードについてもTop 10本体のリスクを確認してください。

API・LLM向けのOWASP Top 10との使い分け

OWASPのTop 10は対象ごとに別文書です。Webアプリケーション全般を扱うのがこの記事のOWASP Top 10で、API、LLMアプリケーション、AIエージェントにはそれぞれ独立したリストがあります。

原文は、API Security Top 10 2023、GenAI LLM Top 10 2026、Top 10 for Agentic Applications、Mobile Top 10で読めます。LLM版はgenai.owasp.orgの項目ページが2025年版のまま残っているため、2026年版はGitHubの最終版で確認してください。

APIを公開しているなら、Web版のA01だけでは足りません。API版はオブジェクト単位・プロパティ単位・機能単位の認可を別々の項目にしており、確認の粒度が細かくなっています。詳細はOWASP API Security Top 10 2023の全10項目を、プロンプトインジェクションや過剰な権限を扱うLLM版はOWASP Top 10 for LLMの全項目の解説（2025年版が対象）を参照してください。

よくある質問

OWASP Top 10の最新版はいつ正式版になりましたか？

2025年版は2025年11月6日にリリース候補として公開され、2025年12月24日（UTC）に公式リポジトリでRC表記が外れて正式版になりました。2026年10月時点でもこれが最新版です。

OWASP Top 10 2025の日本語版はどこで読めますか？

公式サイトの top10.owasp.org/2025/ja/ で読めます。2026年7月12日に日本語訳が公式サイトで有効化されました。2021年版の訳で「失敗」だった項目は「暗号化の不備」「認証の不備」のように「不備」に改められています。

2021年版と2025年版の一番大きな違いは何ですか？

A03「ソフトウェアサプライチェーンの不備」とA10「例外的な状況への不適切な対応」の新設です。A03は2021年版A06の部品の脆弱性に加え、ビルド環境や配布経路の侵害まで対象を広げました。2021年版A10のSSRFはA01に統合されています。

OWASP Top 10のA03とは何ですか？

2025年版のA03はソフトウェアサプライチェーンの不備です。2021年版のA03はインジェクションだったので、版を明記せずに「A03」と書くと別の項目を指してしまいます。社内資料では「A03:2025」のように版つきで書いてください。

OWASP Top 10をセキュリティ診断のチェックリストとして使えますか？

最低限の出発点としては使えますが、網羅的な基準にはなりません。OWASPは、検証可能な要件として作られたASVSを開発標準や診断基準に使うよう勧めており、Top 10への完全対応をうたうツールの主張も否定しています。

関連記事

• OWASPとは？読み方・組織の実体と主要プロジェクトの全体像
• OWASP API Security Top 10 2023の全10項目｜APIセキュリティのガイドラインと対策
• OWASP Top 10 for LLMとは？2025年版の全10項目と変更点・実務での対策
• サプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断
• 脅威モデリングとは？STRIDEでの脅威抽出手順とツール選定を実装目線で解説