--- title: "OWASP ZAPの診断項目とは？検出できる脆弱性一覧とOWASP Top 10 2025対応・使い方" url: "https://www.issoh.co.jp/tech/details/2958/" published: 2024-07-05 updated: 2026-10-15 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 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）と組で読む。リスク値は推測せず[公式のアラート一覧](https://www.zaproxy.org/docs/alerts/)で確かめる。 - 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）](/tech/details/15882/)のツールです。読み方は「ザップ」、正式名称はZed Attack Proxy（ゼッド・アタック・プロキシ）。稼働中のアプリにHTTPで問い合わせて判定するため、ソースコードがなくても診断できます。 ### OWASP離脱からCheckmarx参画までの運営体制 ZAPは長くOWASPのフラッグシッププロジェクトでしたが、[2023年8月1日の公式ブログ](https://www.zaproxy.org/blog/2023-08-01-zap-is-joining-the-software-security-project/)でLinux Foundationの新組織Software Security Projectへの参加とOWASPからの離脱を発表しました。その後[2024年9月24日](https://www.zaproxy.org/blog/2024-09-24-zap-has-joined-forces-with-checkmarx/)に3人のプロジェクトリーダー全員がCheckmarxに雇用され、名称が「ZAP by Checkmarx」に変わっています。ライセンスはApache License 2.0のままで、2023年のブログには現在「Checkmarxの支援を受け、どの財団にも属していない」との注記が付いています。「OWASP ZAP」と書かれていても同じツールです。 ## OWASP ZAPの診断項目の全体像｜パッシブとアクティブの2系統 診断項目の一覧は、ZAP公式サイトの[Alert Details](https://www.zaproxy.org/docs/alerts/)が正本です。この一覧の元データ（zaproxy-website リポジトリ、2026年10月14日時点）を集計すると、Releaseのルールはパッシブ55・アクティブ49でした。1つのルールが複数のアラートを出すことがあり（例：HSTS関連は1ルールで8種類）、アラート単位で数えると件数はさらに増えます。 ### パッシブスキャンルール（Release 55ルール・追加リクエストなし） パッシブスキャンは、ブラウジングやスパイダーで発生した通信を観察し、ヘッダーやCookie、情報漏えいの兆候を調べます。解析そのものは通信を書き換えず、攻撃リクエストも送らないため、**本番環境にも向けやすい**のが利点です。ただし通信を集めるスパイダーはフォームも送信するので、本番では巡回範囲と負荷を先に確かめます。主なアドオンは`pscanrules`ですが、55ルールには別アドオンのRetire.jsも含みます。代表的なルールと、そのリスク値は次のとおりです。 | 診断項目（パッシブ） | ID | リスク | | ------------------------- | ----- | ---------------- | | CSPヘッダー未設定 | 10038 | Medium | | クリックジャッキング対策ヘッダー欠如 | 10020 | Medium | | CSRF対策トークンの欠如 | 10202 | Medium | | クロスドメイン設定の不備 | 10098 | Medium | | ディレクトリブラウジング | 10033 | Medium | | 既知の脆弱性を持つJSライブラリ | 10003 | 脆弱性による（既定Medium） | | SRI属性の欠如 | 90003 | Medium | | Secure属性のないCookie | 10011 | Low | | HttpOnly属性のないCookie | 10010 | Low | | X-Content-Type-Options未設定 | 10021 | Low | | HSTSヘッダー未設定 | 10035 | Low | | タイムスタンプの開示 | 10096 | Low | | PII（クレジットカード番号等）の露出 | 10062 | High | ヘッダーと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を超えます）。 | 診断項目（アクティブ） | ID | リスク | | -------------------------- | ----------- | ------ | | SQLインジェクション | 40018 | High | | クロスサイトスクリプティング（反射型） | 40012 | High | | クロスサイトスクリプティング（格納型） | 40014 | High | | OSコマンドインジェクション | 90020 | High | | パストラバーサル | 6 | High | | XXE（XML外部実体参照） | 90023 | High | | サーバーサイドテンプレートインジェクション | 90035 | High | | 外部へのリダイレクト | 20019 | High | | クラウドメタデータの露出 | 90034 | High | | Log4Shell／Spring4Shell | 40043／40045 | High | | React2Shell（RSCのRCE） | 40048 | High | | CRLFインジェクション | 40003 | Medium | | パラメータ改ざん | 40008 | Medium | | Billion Laughs（XML実体の指数展開） | 40044 | Medium | 「攻撃系はMedium程度」と思い込むと読み違えます。外部リダイレクトもクラウドメタデータの露出もHighです。一方、セッション固定（40013）、SSRF（40046）、MongoDBへのNoSQLインジェクション（40033）、CSRFトークンの能動検査（20012）はBetaで、既定のReleaseには入っていません。XSSとCSRFの仕組みと防御の実装は[XSSとCSRFの違いと対策](/tech/details/4109/)で扱っています。 ### リスク4段階と確信度（Confidence）の読み方 各アラートには重大度の**リスク（High／Medium／Low／Informational）**と、誤検知でない度合いの**確信度**が付きます。確信度はFalse Positive・Low・Medium・High・Confirmedの5段階で、ZAPが自動で付けるのはLow〜Highだけです。ConfirmedとFalse Positiveは人が手動か[Alert Filter](https://www.zaproxy.org/docs/desktop/addons/alert-filters/)で設定します。レポートは「High (Medium)」のように**リスク（確信度）**の順で並ぶので、業務への影響とリスクを先に評価し、確信度Lowの項目も再現確認の対象に含めます。 2.17.0からは、サイト全体に共通する指摘（ヘッダー欠如など）が[「Systemic」として印が付き](https://www.zaproxy.org/docs/desktop/releases/2.17.0/)、重複アラートもまとめられるようになりました。ページ数が多いサイトで同じ指摘が何百件も並ぶ状況は減っています。 ### 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日）](https://github.com/zaproxy/zap-extensions/blob/main/addOns/commonlib/CHANGELOG.md)でOWASP Top 10 2025のアラートタグを追加し、2026年4月14日の`pscanrules` 73と`ascanrules` 81で各ルールに付けました。公式アラート定義のタグから、Releaseルールを2025年版のカテゴリ別に数えた結果が次の表です（1ルールが複数カテゴリに付くことがあります）。カテゴリ名は[OWASP Top 10 2025の解説](/tech/details/9917/)の日本語表記に合わせています。 | OWASP Top 10 2025 | パッシブ | アクティブ | 代表的な診断項目 | | ------------------ | ---- | ----- | ------------------------- | | A01 アクセス制御の不備 | 14 | 2 | パストラバーサル／CSRFトークン欠如 | | A02 セキュリティ設定の不備 | 17 | 9 | CSP・HSTS欠如／.env漏えい | | A03 サプライチェーンの不備 | 2 | 6 | 脆弱なJSライブラリ／Log4Shell | | A04 暗号化の不備 | 4 | 4 | HTTPのみのサイト／Padding Oracle | | A05 インジェクション | 5 | 30 | SQLi／XSS／OSコマンド／SSTI | | A06 安全性を欠いた設計 | 8 | 3 | パラメータ改ざん／PII露出 | | A07 認証の不備 | 3 | 0 | 弱い認証方式（Basic認証等） | | A08 完全性の不備 | 4 | 0 | 外部ドメインJSの読み込み | | A09 ログとアラートの不備 | 0 | 0 | なし | | A10 例外的な状況への不適切な対応 | 0 | 3 | バッファオーバーフロー／書式文字列 | 件数の偏りは公式タグ上の対応範囲を示しますが、検出精度や網羅率を直接示すものではありません。アクティブの攻撃ルールの6割がA05インジェクションに集中し、A09は外からHTTPで観察しても判定できないため1ルールもありません。A07もパスワード総当たりやMFA回避を試すReleaseルールはなく、平文で認証情報が流れていないかをパッシブで見る程度です。A01の16ルールも大半は情報漏えい系で、「一般ユーザーが他人の注文を見られる」といった認可の欠陥を確かめるにはAlphaの[Access Control Testing](https://www.zaproxy.org/docs/desktop/addons/access-control-testing/)アドオンに複数ユーザーの権限を設定する必要があります。 2021年版の対応表を使い回している解説は、カテゴリ番号がずれる点に注意します。2021年版のA03インジェクションは2025年版でA05に、A05設定ミスはA02に移り、SSRF（旧A10）はA01に統合されました。なおZAPのSSRF検査ルール（40046・Beta）のタグはA01でなくA05です。 ## スキャンポリシー別の診断範囲と選定基準 アクティブスキャンで「どの診断項目を回すか」はスキャンポリシーで決めます。公式イメージには[Scan Policies](https://www.zaproxy.org/docs/desktop/addons/scan-policies/)アドオン（Alpha・0.8.0）が同梱され、用途別のポリシーを名前で呼び出せます。Releaseのアクティブ49ルールのうち、各ポリシーに入るルール数を公式タグで数えると次のとおりです。 | ポリシー（AFでの名前） | 想定環境 | Releaseルール数 | 主な方針 | | ------------ | --------- | ----------- | ------------------- | | Dev CICD | 開発のCI/CD | 10 | 長時間・誤検知多・情報のみを除外 | | Dev Standard | 開発環境 | 13 | Dev CICDに長めのルールを追加 | | Dev Full | 開発環境 | 26 | 環境・サーバー系は最小限 | | QA CICD | QAのCI/CD | 14 | Dev CICDに重要な環境系を追加 | | QA Standard | 検証・ステージング | 26 | Dev Standardに環境系を追加 | | QA Full | 検証・ステージング | 46 | 環境・サーバー系も広く有効 | | API | APIのみ | 20 | 画面でなくAPIに効くルール | | Pen Test | 診断者 | 48 | Example以外の全ルール | 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連携」の例とほぼ同じ構成（実行ごとにスパイダーの種類とポリシーを差し替え）です。 | 実行内容 | 所要時間 | アラート種類 | うちHigh | | --------------------- | ------ | ------ | ------ | | zap-baseline.py（既定） | 2分24秒 | 9 | 0 | | AF：従来スパイダー＋パッシブ | 1分31秒 | 3 | 0 | | AF：Client Spider＋パッシブ | 6分48秒 | 9 | 1 | | AF：両スパイダー＋Dev CICD | 7分04秒 | 12 | 3 | | AF：両スパイダー＋QA Standard | 12分34秒 | 12 | 3 | ### 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](https://github.com/zaproxy/zaproxy/releases/tag/v2.17.0)です。[公式のダウンロードページ](https://www.zaproxy.org/download/)から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日のブログ](https://www.zaproxy.org/blog/2026-07-06-client-spider-now-recommended/)で、モダンなWebアプリにはAJAXスパイダーでなく**Client Spider**を使うよう推奨を切り替えました。ZAP自身のブラウザ拡張でDOMの変化を追うため同じ画面を開き直さず、大規模なアプリでも所要時間がほぼ線形に収まるのが理由です。従来のスパイダーとの併用も勧めています。 ### 手動探索（Manual Explore）とプロキシ診断 Manual Exploreは、ZAP経由のブラウザで実際に操作し、通ったリクエストを記録・改変しながら調べる方法です。ログイン後の画面や、入力値によって分岐する画面など、自動巡回で届かない箇所をここで拾います。記録したリクエストを右クリックして、そのURLだけにアクティブスキャンをかけることもできます。手動の改ざんや繰り返し送信を中心に診断するなら、[Burp Suite](/tech/details/9699/)と比べて道具を選ぶ余地があります。 ### ベースライン／フル／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の解説記事](/tech/details/15882/)で扱っているので、ここでは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](https://github.com/zaproxy/action-af)（v0.3.0）があります。前の3つは検出結果をIssueとして起票・更新できます。 ### Python APIクライアントでの制御 プログラムから細かく制御するなら公式のPythonクライアントを使います。PyPIのパッケージ名は`zaproxy`（[0.6.0](https://pypi.org/project/zaproxy/)）で、インポートは`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連携アドオン](https://www.zaproxy.org/blog/2026-04-02-zap-mcp-server/)を入れると、ClaudeやCursorなどのMCPクライアントから、スパイダーやアクティブスキャンの開始とアラートの取得を指示できます。公式が「明確にAlpha」と書いているため、検証環境での試用に留めます。[2026年10月8日](https://www.zaproxy.org/blog/2026-10-08-oauth2-support/)にはAuthentication HelperアドオンがOAuth2の`client_credentials`と`password`グラントに対応しました。公式はAPI向けに限って勧めており、ログイン画面のあるWebアプリは従来どおりブラウザベース認証を使います。 ## OWASP ZAPの自動スキャンの限界とペネトレーションテストでの補完 ZAPの出力が空でも「安全」とは言えません。前章のTop 10対応のとおり、ログとアラートの不備（A09）は1ルールもなく、認証と認可の欠陥もReleaseのルールではほとんど検査されません。権限昇格、他人のデータの参照、価格の改ざんといった**業務ロジックに依存する脆弱性**は、正常なリクエストと見分けが付かないため、パターン照合では拾えません。 ZAPは診断の入口を自動化する道具で、それ単体で脆弱性診断は完結しません。認可の設計と実装を確かめるには、権限仕様のレビューと、複数ユーザーでアクセス可否を比較する手動診断を組み合わせます。社内で回しきれない範囲は[脆弱性診断・セキュリティ診断の支援](/service/system/vulnerability/)のような外部の手動診断やペネトレーションテストに任せると、ZAPで潰した基礎項目の上に、自動スキャンでは判断しにくい認可や業務ロジックの検査を補えます。攻撃側の道具立ては[Kali Linux](/tech/details/9369/)の記事にまとめています。 ## 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の記事](/tech/details/5056/)を参照。 - **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組み込みと導入判断を実装視点で解説](/tech/details/15882/) - [OWASP Top 10の最新版は2025年版｜10項目と2021年版からの変更点・公式日本語訳](/tech/details/9917/) - [Burp Suiteとは？通信傍受の仕組みとエディションの選び方・初期設定](/tech/details/9699/) - [DVWAとは？脆弱性を安全に学べる環境構築とセキュリティレベルの使い方](/tech/details/5056/) - [OWASPとは？主要プロジェクトの全体像とアプリ開発への組み込み方【2026年時点】](/tech/details/13128/) --- 出典: [OWASP ZAPの診断項目とは？検出できる脆弱性一覧とOWASP Top 10 2025対応・使い方]()（株式会社一創）