[脆弱性診断ツール自製] オープンソースで始めるWebサイト脆弱性診断｜OWASP ZAPの使い方ガイド

2026年2月16日

永井海斗

この記事のポイント

✓高額な外部診断に頼らず
✓自社でWebサイトの脆弱性診断を始める方法を解説
✓世界標準のOSSツール「OWASP ZAP」の最新版（2026年）の使い方から

「セキュリティ診断を外注したいが、見積もりが 150万円を超えていて手が出ない。自分たちで最低限のチェックはできないだろうか？」

小規模な開発チームやスタートアップから、このような切実な相談を受けることが非常に増えた。2026年、サイバー攻撃の標的は「大手」から「守りの手薄な中小」へと完全にシフトしている。攻撃者は自動化されたスクリプトを使い、わずか数分で世界中のWebサイトの脆弱性をスキャンしているのだ。これに対抗するには、年に数回の外注診断だけではもはや不十分と言える。

結論から言えば、「脆弱性診断の自製（内製化）」は可能だ。もちろん、プロの手動診断を 100% 代替することはできないが、オープンソースのデファクトスタンダードである「OWASP ZAP」を活用すれば、主要な脆弱性の 7〜8割を自分たちで早期に発見し、修正することができる。

本記事では、2026年最新版のOWASP ZAPを用いた、Webサイト脆弱性診断の「自製ガイド」を詳しく紹介する。

なぜ「自製」が必要なのか？

外注診断（記事61参照）にはメリットも多いが、以下のデメリットもある。

コストが高い：1回あたり 100万円単位の費用がかかる。スタートアップにとって、この金額は人件費やサーバー費に回せる貴重な資本だ。
頻度が低い：予算とスケジュールの関係上、年 1回程度になりがちだ。しかし、Webアプリケーションは日々更新されており、先週リリースした機能に深刻な穴が開いている可能性も否定できない。
リリースの足かせ：診断結果を待つために、数週間リリースのタイミングが遅れることがある。アジャイルな開発プロセスにおいて、セキュリティがボトルネックになるのは避けたい。

自製診断（内製化）を導入すれば、「開発の都度、0円で、即座に」セキュリティチェックが可能になる。これはモダンな開発サイクルにおいて、チームの自衛能力を高める強力な武器となる。

2026年版：OWASP ZAPの導入と準備

OWASP ZAP（現在はZAP by Checkmarxとして運営）は、世界中で使われている無料の診断ツールだ。オープンソースでありながら、商用ツールに匹敵する機能を有している。

動作環境とインストール

2026年の最新版（v2.18以降）では、Java 21 以降が必須となっている。

ダウンロード：公式サイト（zaproxy.org）からOSに合ったインストーラーを入手しよう。
メモリ割り当て：大規模なサイトを診断する場合、デフォルト設定ではメモリ不足で落ちることがある。インストールディレクトリにある設定ファイル（vmoptions）を編集し、少なくとも 4GB 〜 8GB のメモリを割り当てておくのがコツだ。これにより、複雑なJavaScriptを多用する現代的なWebアプリケーションでも安定してスキャンできる。

初期設定のポイント

インストール直後に必ず行うべき設定がある。それは「自動アップデート」の有効化だ。脆弱性診断ツールの命は「シグネチャ（攻撃パターンの定義）」にある。2026年現在、新たな攻撃手法は毎日のように生まれているため、ZAPを常に最新の状態に保つことが必須となる。

【実践】自製診断の5ステップ・ワークフロー

単にツールを動かすだけでは、誤検知（存在しない脆弱性をあると判断する）に振り回されることになる。以下の手順で進めることで、診断の精度は格段に上がる。

ステップ1：コンテキストの設定

診断対象のURLを「コンテキスト」に追加する。ここで重要なのは「スコープ（診断範囲）」の厳密な指定だ。

除外設定：外部の広告タグ（Google Ads等）や、SNSのシェアボタンのURLを除外する。これをしないと、他人のサイトへ攻撃を仕掛けてしまい、利用規約違反や法的トラブルになる可能性がある。必ず「自社ドメイン内のみ」を診断するように設定せよ。

ステップ2：手動探索（Manual Explore）

ZAP内のブラウザを起動し、人間が実際にサイトを操作する。

ログイン処理
フォームへの入力（会員登録、お問い合わせ、検索機能）
商品のカート投入・決済フロー自動クロール（スパイダー）は優秀だが、JavaScriptで動的に生成されるボタンや、ログイン後の認証が必要なページには到達できないことが多い。人間が「一通りの主要な機能」を操作して、その通信経路をZAPに覚え込ませるのが目的だ。

ステップ3：パッシブスキャン

操作している裏側で、ZAPが「通信内容（HTTPヘッダーなど）」を監視し、基本的な不備を自動で見つけてくれる。

CookieにSecure属性がない（通信の盗聴リスク）
X-Frame-Optionsヘッダーがない（クリックジャッキング対策）
不要なデバッグ情報がレスポンスに含まれているこれらは、疑似攻撃をしなくても見つかる「設定ミス」であり、修正の優先順位は高い。

ステップ4：アクティブスキャン（疑似攻撃）

いよいよSQLインジェクションやクロスサイトスクリプティング（XSS）などの攻撃リクエストを送信する。

注意：必ず「テスト環境」で実施すること。本番環境で実行すると、データベースが数千件のゴミデータで埋まったり、最悪の場合システムが過負荷でダウンしたりする。また、メール送信機能がある場合、大量のテストメールがユーザーやシステム管理者に届く恐れがあるため、メールサーバーを遮断する等の対策が必須だ。

ステップ5：レポート出力と修正

診断結果はHTML形式で出力できる。2026年版では開発者向けのSARIF形式出力も強化されており、GitHubのアクションと連携して自動でバグトラッカーに登録することも可能だ。脆弱性が発見されたら、修正→再スキャンのサイクルを回し、アラートが消えることを確認しよう。

【実体験】内製化でセキュリティ予算を 80% 削減したD社の例

あるSaaS開発のD社は、毎月の小規模な機能追加のたびにセキュリティ不安を感じていた。そこで私がOWASP ZAPの導入を支援した。

Before：半年に1回の外注診断（ 150万円）。それ以外の期間は「不安」を抱えたまま機能リリースを行っていた。
After：
- 開発環境でエンジニアがCIパイプラインの中でZAPを実行（コスト： 0円）。
- 重大な脆弱性の 90% をリリース前に自力で修正できるように。
- 年1回の「公式監査」としてのみ外注を利用（費用を 30万円のスポット診断に縮小）。

結果として、セキュリティ品質は向上しつつ、関連予算を年間 200万円以上削減することに成功した。さらに重要なのは、開発チームがセキュリティ意識を持ち、セキュアなコードを書く文化が根付いたことである。

自製診断を安全に行うための「鉄則」

許可のないサイトには絶対に実行しない：たとえ自社のサイトでも、他社のサーバー（レンタルサーバーや共有環境）を共有している場合、規約で禁止されていることがある。事前にサービスプロバイダーに確認するか、許可された環境で実施せよ。
バックアップを必ず取る：アクティブスキャンは「破壊的」な動作を含む。DBの中身が書き換わっても 10分以内に復旧できる体制で行うのがプロの鉄則だ。
「100%ではない」ことを理解する：ツールは万能ではない。ロジックの脆弱性や、最新の未公開攻撃手法は見逃す可能性がある。自製診断は「ガードレール」であり、最終的な「車検」はプロに任せるという使い分けが重要だ。