OWASP ZAPの診断項目とは？検出できる脆弱性一覧とOWASP Top 10 2025対応・使い方

OWASP ZAP（Zed Attack Proxy）の「診断項目」とは、ZAPが検出できる脆弱性の種類、つまりスキャンルールのことです。通信を観察するだけのパッシブスキャンと、攻撃を模したリクエストを送るアクティブスキャンの2系統があり、2026年10月時点の公式アラート定義では、既定で有効なRelease版がパッシブ55・アクティブ49ルールあります。本記事では、その中身とリスクの読み方、OWASP Top 10 2025との対応、スキャンポリシーによる絞り込み、OWASP Juice ShopにZAP 2.17.0を当てた実測結果、導入から自動化までを順に整理します。

まとめ：OWASP ZAPの診断項目の要点

• 診断項目＝スキャンルール。Release版はパッシブ55ルール（追加リクエストなし）とアクティブ49ルール（攻撃リクエストを送信）。Beta・Alphaは追加で導入する。
• アラートのリスクはHigh／Medium／Low／Informationalの4段階で、確信度（Confidence）と組で読む。リスク値は推測せず公式のアラート一覧で確かめる。
• 2026年4月のルール更新でOWASP Top 10 2025のタグが付いた。インジェクション（A05）はアクティブ30ルールで厚い一方、ログとアラートの不備（A09）に対応するルールは0、認証の不備（A07）はパッシブ3ルールだけ。
• どの診断項目を回すかはスキャンポリシーで決める。CIには攻撃系を絞った「Dev CICD」、リリース前の検証環境には「QA Full」など、用途別の公式ポリシーがある。
• 最新はZAP 2.17.0（2025年12月15日）。WindowsとLinuxはJava 17以上が必要。運営は2023年にOWASPを離れ、現在は「ZAP by Checkmarx」としてApache 2.0のまま無料で開発が続いている。

OWASP ZAP（Zed Attack Proxy）の仕組みと「ZAP by Checkmarx」への改称

ZAPは、ブラウザとWebサーバーの間にプロキシとして入り、通信を記録・改変しながら脆弱性を探す動的アプリケーションセキュリティテスト（DAST）のツールです。読み方は「ザップ」、正式名称はZed Attack Proxy（ゼッド・アタック・プロキシ）。稼働中のアプリにHTTPで問い合わせて判定するため、ソースコードがなくても診断できます。

OWASP離脱からCheckmarx参画までの運営体制

ZAPは長くOWASPのフラッグシッププロジェクトでしたが、2023年8月1日の公式ブログでLinux Foundationの新組織Software Security Projectへの参加とOWASPからの離脱を発表しました。その後2024年9月24日に3人のプロジェクトリーダー全員がCheckmarxに雇用され、名称が「ZAP by Checkmarx」に変わっています。ライセンスはApache License 2.0のままで、2023年のブログには現在「Checkmarxの支援を受け、どの財団にも属していない」との注記が付いています。「OWASP ZAP」と書かれていても同じツールです。

OWASP ZAPの診断項目の全体像｜パッシブとアクティブの2系統

診断項目の一覧は、ZAP公式サイトのAlert Detailsが正本です。この一覧の元データ（zaproxy-website リポジトリ、2026年10月14日時点）を集計すると、Releaseのルールはパッシブ55・アクティブ49でした。1つのルールが複数のアラートを出すことがあり（例：HSTS関連は1ルールで8種類）、アラート単位で数えると件数はさらに増えます。

パッシブスキャンルール（Release 55ルール・追加リクエストなし）

パッシブスキャンは、ブラウジングやスパイダーで発生した通信を観察し、ヘッダーやCookie、情報漏えいの兆候を調べます。解析そのものは通信を書き換えず、攻撃リクエストも送らないため、本番環境にも向けやすいのが利点です。ただし通信を集めるスパイダーはフォームも送信するので、本番では巡回範囲と負荷を先に確かめます。主なアドオンはpscanrulesですが、55ルールには別アドオンのRetire.jsも含みます。代表的なルールと、そのリスク値は次のとおりです。

ヘッダーとCookieの設定不備が大半で、Webサーバーやフレームワークの設定で直せます。パッシブでもHighはあり、レスポンスにカード番号らしき数字列が出ていればPII露出（10062）がHighで上がります。

アクティブスキャンルール（Release 49ルール・攻撃リクエストを送信）

アクティブスキャンは、攻撃を模したパラメータを送り込み、脆弱性が発火するかを確かめます。データの書き換えや大量リクエストを伴うため、許可を得た検証環境に対してだけ実行します。主なアドオンはascanrulesですが、49ルールには別アドオンのDOM XSS Active Scan Rule（40026）も含みます。Releaseの49ルールをリスク別に数えると、High 30・Medium 14・Low 2・Informational 4でした（1ルールが複数のリスクのアラートを持つため合計は49を超えます）。

「攻撃系はMedium程度」と思い込むと読み違えます。外部リダイレクトもクラウドメタデータの露出もHighです。一方、セッション固定（40013）、SSRF（40046）、MongoDBへのNoSQLインジェクション（40033）、CSRFトークンの能動検査（20012）はBetaで、既定のReleaseには入っていません。XSSとCSRFの仕組みと防御の実装はXSSとCSRFの違いと対策で扱っています。

リスク4段階と確信度（Confidence）の読み方

各アラートには重大度のリスク（High／Medium／Low／Informational）と、誤検知でない度合いの確信度が付きます。確信度はFalse Positive・Low・Medium・High・Confirmedの5段階で、ZAPが自動で付けるのはLow〜Highだけです。ConfirmedとFalse Positiveは人が手動かAlert Filterで設定します。レポートは「High (Medium)」のようにリスク（確信度）の順で並ぶので、業務への影響とリスクを先に評価し、確信度Lowの項目も再現確認の対象に含めます。

2.17.0からは、サイト全体に共通する指摘（ヘッダー欠如など）が「Systemic」として印が付き、重複アラートもまとめられるようになりました。ページ数が多いサイトで同じ指摘が何百件も並ぶ状況は減っています。

Release・Beta・Alphaのルール階層

ルールにはRelease・Beta・Alphaの成熟度があり、Docker公式イメージ（stable）が同梱するスキャンルールのアドオンはReleaseだけです（pscanrules・ascanrules・domxss・retire）。pscanrulesBeta／ascanrulesBetaやAlpha版はMarketplaceから追加して初めて動きます。実際に有効なルールは、アドオンの導入状況に加え、アクティブはScan Policy Manager、パッシブはOptionsのPassive Scan Rulesで確かめます。前述のSSRFやNoSQLインジェクションのほか、Betaのアクティブルールには.gitやバックアップファイルの露出、HTTPパラメータ汚染などがあり、網羅を広げたい検証環境では入れる価値があります。追加するルールによって誤検知や所要時間が変わるため、CIではReleaseを出発点とし、必要なBetaルールは検証環境で結果と実行時間を確かめてから追加します。

OWASP Top 10 2025とZAPの診断項目の対応

ZAPは共通ライブラリ1.40.0（2026年3月19日）でOWASP Top 10 2025のアラートタグを追加し、2026年4月14日のpscanrules 73とascanrules 81で各ルールに付けました。公式アラート定義のタグから、Releaseルールを2025年版のカテゴリ別に数えた結果が次の表です（1ルールが複数カテゴリに付くことがあります）。カテゴリ名はOWASP Top 10 2025の解説の日本語表記に合わせています。

件数の偏りは公式タグ上の対応範囲を示しますが、検出精度や網羅率を直接示すものではありません。アクティブの攻撃ルールの6割がA05インジェクションに集中し、A09は外からHTTPで観察しても判定できないため1ルールもありません。A07もパスワード総当たりやMFA回避を試すReleaseルールはなく、平文で認証情報が流れていないかをパッシブで見る程度です。A01の16ルールも大半は情報漏えい系で、「一般ユーザーが他人の注文を見られる」といった認可の欠陥を確かめるにはAlphaのAccess Control Testingアドオンに複数ユーザーの権限を設定する必要があります。

2021年版の対応表を使い回している解説は、カテゴリ番号がずれる点に注意します。2021年版のA03インジェクションは2025年版でA05に、A05設定ミスはA02に移り、SSRF（旧A10）はA01に統合されました。なおZAPのSSRF検査ルール（40046・Beta）のタグはA01でなくA05です。

スキャンポリシー別の診断範囲と選定基準

アクティブスキャンで「どの診断項目を回すか」はスキャンポリシーで決めます。公式イメージにはScan Policiesアドオン（Alpha・0.8.0）が同梱され、用途別のポリシーを名前で呼び出せます。Releaseのアクティブ49ルールのうち、各ポリシーに入るルール数を公式タグで数えると次のとおりです。

Dev CICDの10ルールは、SQLインジェクション・反射型XSS・OSコマンド・XXE・SSTI・XPath／XSLTインジェクション・外部リダイレクト・React2Shellで、「短時間で回せて誤検知が少ない高リスク項目」に絞られています。逆に言えば、CIでDev CICDが通っても、パストラバーサルやリモートファイルインクルード（Dev StandardとQA Standard以上）、格納型XSS（Dev FullとQA Standard以上）は検査されていません。QA CICDにもこの3つは入りません。CIはDev CICDかQA CICDで常時回し、リリース前にQA Fullを検証環境へ1回当てる、という分担にすると漏れと所要時間の釣り合いが取れます。

Juice ShopにZAP 2.17.0を当てた実測結果

2026年10月15日に、公式イメージghcr.io/zaproxy/zaproxy:stable（ZAP 2.17.0・pscanrules 76・ascanrules 84を同梱）を、同じDockerネットワーク内で動かしたOWASP Juice Shop 20.3.0に向けました。スキャン先は手元のコンテナだけです。Automation Framework（AF）のプランはスパイダーの種類とポリシーだけを変え、ほかは同じ設定にしています。所要時間はコンテナ起動から終了までの実時間です。QA Standardだけは別のJuice Shopコンテナに対して他の4本と並行して走らせたため、時間は目安として読んでください。イメージのdigestはsha256:7aaa659b0d43…で、AFのプランは後述の「Automation Frameworkのジョブ定義とGitHub Actions連携」の例とほぼ同じ構成（実行ごとにスパイダーの種類とポリシーを差し替え）です。

Juice Shop実測でのスパイダー別アラート種類数

パッシブスキャンだけの比較でも、従来のスパイダー（18秒で132 URL）はCSP未設定など3種類しか拾えず、Client Spiderに替えると9種類に増えました。増えた中には、/redirect?to=で外部サイトへ飛ばすオープンリダイレクトの兆候（Off-site Redirect・High）があり、Angularの画面を操作して初めて発生する通信なので、HTMLのリンクを辿るだけでは届きません。同時に増えた「URL中のセッションID」（Medium・確信度High）は、5件ともSocket.IOの通信用パラメータsidを指したもので、ログインセッションの漏えいではありませんでした。確信度Highでも中身を見て仕分ける必要がある例です。Client Spiderは上限に設定した5分を使い切っており、SPAの診断では時間の大半がこの巡回に掛かります。

Dev CICDとQA Standardの検出差

Dev CICDのアクティブスキャン自体は45秒で終わり、検索API（/rest/products/searchのq）とログインAPI（/rest/user/loginのemail）のSQLインジェクションと、/redirectの外部リダイレクトをHighで検出しました。ログインAPIの方はJuice Shopの課題「Login Admin」が想定する脆弱性です。ただしSQLインジェクションの確信度はLowで、レポートの「High (Low)」は人が再現して確かめる前提の表示です。一方、難易度1の課題「DOM XSS」は検出されませんでした。DOM型XSSのルール（40026）はReleaseですが、Dev CICDには入っていません。そこで40026を含むQA Standardでも回すと、アクティブスキャンは5分57秒と約8倍に延びた一方、HighはSQL Injection・External Redirect・Off-site Redirectの同じ3種類で、DOM XSSはやはり検出されませんでした。アラートの顔ぶれの差は、Informationalが1種類入れ替わっただけでした。ポリシーを広げれば見つかるとは限らず、自動スキャンで出なかった項目は手動で確かめる対象として残ります。

ベースラインの結果には、Beta版のパッシブルール（Spectre対策ヘッダーの欠如など）の指摘も含まれていました。イメージ自体はBetaを同梱していませんが、zap-baseline.pyが起動時にpscanrulesBetaを追加インストールするためです（-aを付けるとAlphaも入ります）。またzap-baseline.pyは、FAILが0件でもWARNが1件あれば終了コード2を返します。CIを止めたくない段階では-Iで警告を無視し、ルールごとの扱いは設定ファイル（-c）でFAIL・WARN・IGNOREに振り分けます。

OWASP ZAPのインストールと初期設定

デスクトップ版（最新2.17.0・Java 17以上）

現行の安定版は2025年12月15日公開の2.17.0です。公式のダウンロードページからWindows・Linux・macOS向けを取得します。WindowsとLinux版はJava 17以上が必要で、macOS版はJava 17を同梱しています。起動後、ブラウザのプロキシをZAP（既定でlocalhost:8080）に向けると通信を捕捉でき、HTTPSを見るにはZAPのルート証明書をブラウザに取り込みます。Quick Startの「Manual Explore」から起動するブラウザなら、プロキシと証明書の設定は不要です。

Docker版（ghcr.io/zaproxy/zaproxy）

コンテナ版は用途別のスクリプトを同梱しています。旧来のowasp/zap2docker-stableは廃止され、現在のイメージ名は次のとおりです。

# 安定版（Docker Hubの zaproxy/zap-stable と同じもの）
docker pull ghcr.io/zaproxy/zaproxy:stable

# ベースラインスキャン（パッシブのみ）
docker run --rm -v "$(pwd):/zap/wrk/:rw" ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://example.com -r report.html

古い記事のowasp/zap2docker-*を使った手順は、そのままでは動きません。

OWASP ZAPの使い方｜自動スキャンから手動診断まで

まず自動で広く巡回して当て、自動では届かない画面や疑わしい箇所を手動で深掘りします。

自動スキャンとClient Spider（2026年7月からAJAXスパイダーより推奨）

Quick Startの「Automated Scan」にURLを入れると、スパイダーで巡回してパッシブスキャンを行い、続けてアクティブスキャンまで実行します。JavaScriptで画面を組み立てるSPAは、HTMLのリンクを辿る従来のスパイダーだけでは画面の中まで届きません。公式は2026年7月6日のブログで、モダンなWebアプリにはAJAXスパイダーでなくClient Spiderを使うよう推奨を切り替えました。ZAP自身のブラウザ拡張でDOMの変化を追うため同じ画面を開き直さず、大規模なアプリでも所要時間がほぼ線形に収まるのが理由です。従来のスパイダーとの併用も勧めています。

手動探索（Manual Explore）とプロキシ診断

Manual Exploreは、ZAP経由のブラウザで実際に操作し、通ったリクエストを記録・改変しながら調べる方法です。ログイン後の画面や、入力値によって分岐する画面など、自動巡回で届かない箇所をここで拾います。記録したリクエストを右クリックして、そのURLだけにアクティブスキャンをかけることもできます。手動の改ざんや繰り返し送信を中心に診断するなら、Burp Suiteと比べて道具を選ぶ余地があります。

ベースライン／フル／APIスキャンの使い分け

コンテナ版には3つのパッケージスキャンがあります。

• ベースラインスキャン（zap-baseline.py）：既定1分のスパイダーとパッシブスキャンのみ。本番でも利用できるが、事前に巡回対象・フォーム送信・負荷の影響を確認する。
• フルスキャン（zap-full-scan.py）：スパイダーに続けてアクティブスキャンまで実行する。検証環境向け。
• APIスキャン（zap-api-scan.py）：OpenAPI・SOAP・GraphQLの定義を読み込み、APIの各エンドポイントにアクティブスキャンをかける。

本番にはベースラインだけを向け、攻撃を伴うフルスキャンとAPIスキャンは検証環境に限ります。

CI/CD・Python・AIエージェントからの自動化

継続的に回すには、YAMLで手順を定義するAutomation Framework、プログラムから呼ぶAPI、AIアシスタントからのMCP連携の3通りがあります。DAST全体をCIのどこに置くかはDASTの解説記事で扱っているので、ここではZAP固有の書き方に絞ります。

Automation Frameworkのジョブ定義とGitHub Actions連携

Automation Framework（AF）は、1つのYAMLにスパイダー・スキャン・レポートなどのジョブを並べる仕組みです。アクティブスキャンにpolicyを渡せば、前述のスキャンポリシーで診断項目を絞れます。

env:
  contexts:
    - name: app
      urls:
        - https://staging.example.com
jobs:
  - type: spider
    parameters:
      maxDuration: 3
  - type: spiderClient          # SPAの画面を実ブラウザで巡回
    parameters:
      maxDuration: 5
  - type: passiveScan-wait
  - type: activeScan
    parameters:
      policy: "Dev CICD"        # CI向けの公式ポリシー
  - type: passiveScan-wait
  - type: report
    parameters:
      reportDir: /zap/wrk
      template: traditional-json
      reportFile: zap.json

GitHub Actionsには公式のzaproxy/action-baseline（v0.15.0）・action-full-scan（v0.13.0）・action-api-scan（v0.10.0）と、AFのYAMLをそのまま実行するaction-af（v0.3.0）があります。前の3つは検出結果をIssueとして起票・更新できます。

Python APIクライアントでの制御

プログラムから細かく制御するなら公式のPythonクライアントを使います。PyPIのパッケージ名はzaproxy（0.6.0）で、インポートはfrom zapv2 import ZAPv2です。実行前にPython環境へzaproxyをインストールし、ZAPを127.0.0.1:8080で起動しておきます。コード中のYOUR_API_KEYは、そのZAPのAPI設定に表示されるキーへ置き換え、targetには診断を許可された検証環境のURLを指定します。

import time
from zapv2 import ZAPv2

zap = ZAPv2(apikey='YOUR_API_KEY',
            proxies={'http': 'http://127.0.0.1:8080',
                     'https': 'http://127.0.0.1:8080'})
target = 'https://staging.example.com'

spider_id = zap.spider.scan(target)
while int(zap.spider.status(spider_id)) < 100:
    time.sleep(2)

scan_id = zap.ascan.scan(target)
while int(zap.ascan.status(scan_id)) < 100:
    time.sleep(5)

while int(zap.pscan.records_to_scan) > 0:
    time.sleep(2)

for alert in zap.core.alerts(baseurl=target):
    print(alert['risk'], alert['confidence'], alert['alert'])

MCP連携（Alpha）とOAuth2認証

2026年4月2日公開のMCP連携アドオンを入れると、ClaudeやCursorなどのMCPクライアントから、スパイダーやアクティブスキャンの開始とアラートの取得を指示できます。公式が「明確にAlpha」と書いているため、検証環境での試用に留めます。2026年10月8日にはAuthentication HelperアドオンがOAuth2のclient_credentialsとpasswordグラントに対応しました。公式はAPI向けに限って勧めており、ログイン画面のあるWebアプリは従来どおりブラウザベース認証を使います。

OWASP ZAPの自動スキャンの限界とペネトレーションテストでの補完

ZAPの出力が空でも「安全」とは言えません。前章のTop 10対応のとおり、ログとアラートの不備（A09）は1ルールもなく、認証と認可の欠陥もReleaseのルールではほとんど検査されません。権限昇格、他人のデータの参照、価格の改ざんといった業務ロジックに依存する脆弱性は、正常なリクエストと見分けが付かないため、パターン照合では拾えません。

ZAPは診断の入口を自動化する道具で、それ単体で脆弱性診断は完結しません。認可の設計と実装を確かめるには、権限仕様のレビューと、複数ユーザーでアクセス可否を比較する手動診断を組み合わせます。社内で回しきれない範囲は脆弱性診断・セキュリティ診断の支援のような外部の手動診断やペネトレーションテストに任せると、ZAPで潰した基礎項目の上に、自動スキャンでは判断しにくい認可や業務ロジックの検査を補えます。攻撃側の道具立てはKali Linuxの記事にまとめています。

OWASP ZAPの練習環境｜OWASP BWAは非推奨

ZAPの操作は、意図的に脆弱性を仕込んだアプリで練習します。古い解説で定番のOWASP BWA（Broken Web Applications）は2015年8月を最後に更新が止まっており、いまの脆弱性傾向を学ぶ教材には向きません。現在の選択肢は次の3つです。

• OWASP Juice Shop：Node.js／Angular製のSPA。本記事の実測にも使った。docker run -p 127.0.0.1:3000:3000 bkimminich/juice-shopで起動できる。
• DVWA：PHP／MySQL製で、セキュリティレベルを切り替えて同じ脆弱性の対策差を見られる。導入はDVWAの記事を参照。
• OWASP WebGoat：Java製で、脆弱性ごとのレッスン形式。

いずれも自分の管理下で動かし、許可のない外部サイトには絶対にスキャンをかけません。アクティブスキャンは不正アクセス禁止法などに触れるおそれがあります。

よくある質問

OWASP ZAPの読み方は？

「ザップ」と読みます。正式名称はZed Attack Proxyで、Zを英国式に「ゼッド」と読みます。OWASPは「オワスプ」です。

OWASP ZAPは無料ですか？商用利用もできますか？

無料です。ライセンスはApache License 2.0で、受託の診断業務や社内利用でも料金はかかりません。「ZAP by Checkmarx」になった後もライセンスは変わっていません。

診断項目の一覧はどこで確認できますか？

公式サイトのAlert Details（zaproxy.org/docs/alerts/）が正本で、各アラートのID・リスク・CWE・OWASP Top 10のタグ・ソースコードへのリンクまで載っています。ZAP上ではAnalyse→Scan Policy Managerでアクティブルールの一覧と有効・無効を確認できます。

OWASP ZAPとBurp Suiteはどう違いますか？

どちらもプロキシ型ですが、ZAPは全機能が無料でAutomation FrameworkやDockerによるCI連携が得意です。Burp Suiteは無料のCommunity版でもProxyやRepeaterを使え、Professional版では自動スキャナー、制限のないIntruder、専用拡張などが追加されます。無償でCIに組み込む用途ではZAPを候補にし、手動診断用の操作性や追加機能を重視する場合はBurp Suiteの各エディションと比較します。

OWASP ZAPだけで脆弱性診断は完結しますか？

完結しません。インジェクションや設定不備の検出には強い一方、認証・認可や業務ロジック、ログの不備を標準の自動スキャンだけで網羅することはできないため、追加設定や手動診断、ペネトレーションテストと併用します。

関連記事

• DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説
• OWASP Top 10の最新版は2025年版｜10項目と2021年版からの変更点・公式日本語訳
• Burp Suiteとは？通信傍受の仕組みとエディションの選び方・初期設定
• DVWAとは？脆弱性を安全に学べる環境構築とセキュリティレベルの使い方
• OWASPとは？主要プロジェクトの全体像とアプリ開発への組み込み方【2026年時点】