ZAP（旧 OWASP ZAP）とは？ Baseline / Full Scan の違いと頻出アラートの概要

Web サイトの公開前後には、セキュリティ上の問題が残っていないかを点検する「脆弱性診断」が欠かせません。当社でも自社サイトの開発フローに ZAP による自動スキャンを組み込んでいます。

本記事では、その第一歩として ZAP とは何か、そして代表的なスキャン方式である Baseline Scan と Full Scan の違いと使い分け を解説し、自動スキャンで頻出するアラートを種別ごとに概観します。それぞれの「具体的な意味」と「より踏み込んだ対処方法」は、別記事で詳しく取り上げる予定です。本記事はまず全体像をつかむことを目的としています。

ZAP（旧 OWASP ZAP）とは

ZAP（Zed Attack Proxy）は、オープンソースの Web アプリケーション脆弱性診断ツールです。世界中で広く使われており、無償で利用できることから、セキュリティ診断の入門から実務まで幅広く活用されています。

ZAP は Web サイトに対してリクエストを送り、返ってきたレスポンス（HTTP ヘッダーや HTML の中身など）を解析して、セキュリティ上の問題や改善点を「アラート」として報告します。

なお、ZAP はかつて「OWASP ZAP」として OWASP（Open Worldwide Application Security Project）配下で開発されていましたが、2023 年に OWASP を離れて Linux Foundation の Software Security Project に参加し、2024 年 9 月には Checkmarx 社と合流して「ZAP by Checkmarx」へとブランドが変わりました。運営体制は変わったものの、引き続きオープンソース（Apache License 2.0）として ZAP Core Team の管理のもとで開発が続けられています。古い資料では「OWASP ZAP」と表記されていることも多いため、本記事では現在の名称である ZAP に統一して解説します。

スキャンの種類：Baseline Scan と Full Scan

ZAP の自動スキャン（パッケージ化されたスキャン）には、代表的なものとして Baseline Scan と Full Scan の 2 つがあります。両者の最大の違いは、「攻撃に近いリクエストを実際に送るかどうか（能動スキャンの有無）」 です。

Baseline Scan（受動スキャン中心）

Baseline Scan は、サイトを巡回しながら、返ってきたレスポンス（HTTP ヘッダーや HTML）を観測してアラートを報告します。攻撃に近いリクエストは送らないためサイトに副作用を与えにくく、短時間で完了します。本番環境に対しても比較的安全に実行でき、CI/CD パイプラインに組み込んで継続的に点検する用途に向いています。

受動的な観測が中心のため、報告される項目の多くは「セキュリティヘッダーの欠落」や「情報提供（参考情報）」です。深刻度の高い脆弱性をその場で実証するものではなく、多層防御の観点で改善余地がある箇所を洗い出すものだと捉えると理解しやすいでしょう。

Full Scan（能動スキャンを含む）

Full Scan は、Baseline Scan と同じ巡回・受動スキャンに加えて、能動スキャン（Active Scan） を実行します。ここで「Full Scan」は巡回・受動・能動をまとめて実行する一括スキャンの名前であり、「Active Scan」はそのなかで動く能動スキャンという手法の名前です（Full Scan が Active Scan を内部で呼び出すイメージです）。能動スキャンでは、SQL インジェクションやクロスサイトスクリプティングなどの脆弱性が無いかを、実際に攻撃に近いリクエストを送って確かめます。そのぶん検出力は高くなりますが、

• スキャンに時間がかかる
• フォーム送信やデータ更新が走り、対象サイトに負荷や副作用を与えうる

といった特性があるため、本番環境にむやみに実行するのは避け、検証（ステージング）環境やリリース前の詳細診断で用いるのが基本です。

どう使い分けるか

ざっくりとした目安は次の通りです。

• 日常的・継続的な点検 → Baseline Scan。軽量で副作用が小さく、自動化に向く
• リリース前や定期的な詳細診断 → Full Scan。時間と影響を許容できる検証環境で、より深く確認する

両者は二者択一ではなく、「普段は Baseline で継続監視し、節目で Full を回す」 といった組み合わせが現実的です。本記事で扱うアラートは、このうち Baseline Scan で報告されたものを題材にしています。

頻出するアラートの種別と概要

ここからは、Baseline Scan で頻繁に登場するアラートを、性質ごとにグループ分けして概観します。

1. セキュリティヘッダーに関するアラート

Web サーバーがレスポンスに付けるべき「セキュリティ向けの HTTP ヘッダー」が欠けている、という指摘です。ブラウザに対して「このサイトはこう振る舞ってほしい」と伝えることで、攻撃の被害を抑える多層防御の仕組みです。

これらは「設定すれば即座に脆弱性が塞がる」というより、万一の攻撃に備えてブラウザ側の防御を一段強くする性格のものです。中には CSP の Report-Only のように、運用上あえてその状態にしている場合もあります。各ヘッダーをどう設定するのが適切かは、サイトの構成によって判断が分かれるため、別記事で具体的に解説します。

2. Cookie に関するアラート

ただし、アクセス解析用 Cookie のように仕様上 JavaScript から読む必要があるものや、CDN・プロキシが付与する Cookie もあり、どの Cookie に対する指摘なのかを見極めることが重要です。実際の対象を確認したうえで対応要否を判断します。

3. 外部リソース・サプライチェーンに関するアラート

外部サービスの JavaScript（アクセス解析、ボット対策、Web フォントなど）を読み込んでいる場合によく報告されます。

これらは「外部サービスを信頼して利用している」こと自体への指摘でもあります。アクセス解析タグやボット対策ウィジェットのように、提供元が内容を頻繁に更新するスクリプトでは SRI を付けにくいなど、現実的な制約もあります。CSP による読み込み元の制限など、別の手段と組み合わせて全体のリスクを下げる考え方が大切です。

4. キャッシュに関するアラート

キャッシュ系のアラートは、機微な情報が意図せずキャッシュに残らないかを確認する観点で報告されます。多くは現状を観測した「事実の記録」であり、扱う情報の性質に照らして問題が無ければ、必ずしも対応が必要なわけではありません。

5. 情報提供（参考情報）のアラート

これらは脆弱性の指摘ではなく、ZAP が「サイトをこう認識した」という情報提供です。後続の診断の精度を高めるための内部的なマーカーであり、基本的に対応は不要です。

アラートとの向き合い方

ここまで見てきたように、Baseline Scan のアラートには次のような幅があります。

• 対応すべきもの — 設定するだけで防御力が上がり、副作用も小さいヘッダーなど
• 状況を確認して判断するもの — Cookie や外部リソースのように、対象や用途を見極める必要があるもの
• あえて現状を選んでいるもの・対応不要なもの — 導入過渡期の設定や、情報提供のアラートなど

大切なのは、すべてのアラートを機械的に潰すことではなく、それぞれの意味を理解したうえで「対応する／状況に応じて判断する／リスクを受容する」を見極めることです。誤検知（False Positive）や、運用上あえて選んでいる設定も少なくありません。

まとめ

本記事では、OWASP ZAP の概要と Baseline Scan の位置づけ、そして頻出するアラートを種別ごとに概観しました。

• ZAP は無償で使えるオープンソースの脆弱性診断ツール
• Baseline Scan はサイトに負荷をかけにくく、継続的な点検に向く
• 頻出アラートの多くはセキュリティヘッダーの欠落や情報提供で、深刻度・対応要否はさまざま

次回の記事では、本記事で取り上げたアラートを種別ごとに掘り下げ、具体的に何が問題で、どう対処すればよいのかを、実際の設定例を交えて解説する予定です。自社サイトのセキュリティ点検を始めたい方の参考になれば幸いです。