E2E テストを OWASP ZAP 経由で流して、脆弱性の一次チェックにする

Playwright の E2E を HTTP_PROXY で ZAP に通すと、テストの通信をそのまま ZAP が覚え、続けてアクティブスキャンをかけられる。エージェントに E2E を書かせているなら、環境変数1つで診断の入口ができる。

手順

bash

# ZAP をプロキシとして起動（アプリと同じ Docker ネットワークに入れる）
docker run --rm -d --name zap \
  --network <appのnetwork> -p 8080:8080 \
  ghcr.io/zaproxy/zaproxy:stable \
  zap.sh -daemon -host 0.0.0.0 -port 8080 -config 'api.disablekey=true'

# いつもの E2E を ZAP 経由で流す
HTTP_PROXY=http://localhost:8080 npx playwright test

# 覚えた URL にアクティブスキャン → HTML レポート
curl "http://localhost:8080/JSON/ascan/action/scan/?url=http://backend:8000&recurse=true"
curl "http://localhost:8080/OTHER/core/other/htmlreport/" > zap-report.html

レポートをエージェントに渡し「High と Medium について、本番に関係あるものだけ直す案を出して」と頼む。

記事の例（Todo アプリでの検証）

High 1（全 API が無認証）、Medium 4（CSP 未設定、クリックジャッキング対策なし、SRI なし、Stored XSS の可能性）、Low 3
SQL インジェクションは ORM のパラメータバインドで安全。こうした「安全だった」結果も確認材料になる
Playwright 側の小さな落とし穴: 件数入りの見出しは正規表現 /^未完了\(/ で、同じ文言の要素が複数あるなら { exact: true }、無効化されたボタンは Enter キーで送信して回避

注意点

api.disablekey=true はローカル検証用。CI や共有環境では API キーを有効にする
ZAP はビジネスロジックの欠陥（他人の Todo を操作できるか等）は見つけられない。誤検知も出る。一次スクリーニングと割り切る
認証付きのアプリ、SPA の画面遷移、CI に載せたときの所要時間は記事でも課題として残っている
E2E の数を増やしすぎないよう層を分ける: E2E に全部載せない：AI にテストを書かせる前に層を4つの基準で振り分ける

出典

@labelmake · 2026-03-17
記事「Playwright + OWASP ZAP + Claude Code で E2E テストから脆弱性診断まで一気通貫でできるかやってみた」: zenn.dev