[安全測試] 002 DAST 動態測試實戰：用 OWASP ZAP 掃描你的網站，讓漏洞無所遁形

「程式碼寫得再安全，上線後不實際攻攻看，你怎麼知道門有沒有鎖好？」
— SSDLC by 飛飛

為什麼你需要 DAST？靜態掃描抓不到的，動態掃描來補

在 SSDLC 的學習旅程中，我們已經走過了安全需求定義、安全設計、安全編碼，也認識了 OWASP Top 10 的攻防手法。現在，來到了階段四：安全驗證（Verification）——是時候真正「動手打打看」了。

延續蓋房子的比喻：前面的階段就像畫好了防震設計圖（安全設計）、用了防火建材施工（安全編碼）。但房子蓋好後，你總得找人來實際搖一搖、敲一敲、拿火燒一下，確認這些防護真的有效吧？

這就是 DAST（Dynamic Application Security Testing，動態應用程式安全測試） 在做的事。

SAST vs. DAST：一個看設計圖，一個看成品

你可能聽過 SAST（靜態分析），它是在程式碼層面找問題，就像看建築設計圖找結構缺陷。而 DAST 則是在系統實際運行的狀態下，從外部發動攻擊，看看能不能打進去。

比較項目	SAST（靜態分析）	DAST（動態分析）
檢測時機	開發階段，分析原始碼	測試/上線階段，攻擊運行中的系統
比喻	X 光片看骨骼結構	請專業小偷實際測試防盜系統
需要原始碼？	需要	不需要（黑箱測試）
能找到的問題	程式碼邏輯缺陷、不安全的寫法	實際可被利用的漏洞、設定錯誤
找不到的問題	執行環境的設定問題	程式碼內部邏輯（看不到原始碼）
誤報率	較高（不確定是否真的能被利用）	較低（真的打進去了才算）
代表工具	SonarQube、Semgrep	OWASP ZAP、Burp Suite

飛飛觀點：
SAST 和 DAST 不是二選一，而是互補。SAST 像是你的家庭醫生做健檢，DAST 像是找專業駭客做滲透測試。兩個都做，才能最大程度確保系統安全。在 SSDLC 裡，我們建議兩者都整合進 CI/CD Pipeline。

什麼是 OWASP ZAP？免費又強大的安全掃描神器

ZAP（Zed Attack Proxy） 是全世界最廣泛使用的網頁應用程式安全掃描器。它是開源免費的，由社群持續維護，是 GitHub Top 1000 專案之一。目前由 Checkmarx 贊助維護，最新穩定版本為 2.17.0。

用一句話解釋 ZAP 在做什麼：它模擬駭客的行為，自動對你的網站發動各種攻擊，然後告訴你哪裡有漏洞。

ZAP 的核心運作原理：中間人代理

ZAP 的工作方式就像一個「翻譯官」，站在你的瀏覽器和網站之間：

你的瀏覽器 ←→ ZAP（攔截、分析、修改請求） ←→ 你的網站

就像便利商店的監視器——所有進出的人（HTTP 請求與回應）都會被記錄下來。ZAP 不只記錄，還會分析這些流量，找出可疑的安全問題。

ZAP 能幫你找到什麼？

ZAP 的掃描規則涵蓋了 OWASP Top 10 的大部分類別：

OWASP Top 10 類別	ZAP 能偵測的範例
A01 Broken Access Control	目錄遍歷、敏感檔案暴露
A02 Security Misconfiguration	缺少安全標頭、錯誤頁面洩漏資訊
A03 Software Supply Chain	使用已知有漏洞的 JavaScript 函式庫
A05 Injection	SQL Injection、XSS、OS Command Injection
A07 Authentication Failures	弱密碼、Session 管理問題
A08 Integrity Failures	缺少 SRI 標籤
A09 Logging & Alerting	無法直接檢測（需要人工審查）

安裝 OWASP ZAP：三種方式任你選

方式一：桌面版安裝（推薦新手）

最直覺的方式，有圖形化介面，適合學習和手動探索。

系統需求： Java 17 或更高版本

到 ZAP 官方下載頁面下載對應作業系統的安裝檔：

作業系統	安裝方式
Windows	下載 .exe 安裝檔，或用 <code>winget install ZAP</code>
macOS	下載 .dmg，拖到 Applications
Linux	下載 .tar.gz，或用 <code>flatpak install flathub org.zaproxy.ZAP</code>

方式二：Docker 安裝（推薦 CI/CD 整合）

不需要安裝 Java，一行指令搞定，最適合自動化：

# 拉取穩定版映像
docker pull zaproxy/zap-stable

# 或是拉取精簡版（CI 環境專用，體積更小）
docker pull ghcr.io/zaproxy/zaproxy:bare

方式三：套件管理器

# macOS（Homebrew）
brew install --cask zap

# Windows（Scoop）
scoop install extras/zap

# Windows（Chocolatey）
choco install zap

飛飛觀點：
如果你是第一次接觸 DAST，建議先用桌面版玩一玩，熟悉介面和概念後，再學 Docker 版做自動化。就像學開車，先在練習場熟悉方向盤，再上高速公路。

ZAP 基本操作：從零開始掃描你的第一個網站

重要提醒：只掃描你有權限的系統

在開始之前，最重要的事情：

絕對不要對沒有授權的網站執行安全掃描。 這不只是道德問題，還可能觸犯法律。就像你不能因為「想測試防盜系統」就去撬別人家的門。

安全的練習環境：

練習平台	說明	網址
OWASP Juice Shop	故意有漏洞的電商網站	https://owasp.org/www-project-juice-shop/
OWASP WebGoat	互動式資安教學平台	https://owasp.org/www-project-webgoat/
DVWA	經典的漏洞練習平台	https://github.com/digininja/DVWA
nodelab.feifei.tw	飛飛的 Node.js 練習靶站	https://nodelab.feifei.tw

以下示範，我們用 OWASP Juice Shop 作為掃描目標。

Step 1：啟動練習靶站

# 用 Docker 啟動 Juice Shop
docker run -d -p 3000:3000 bkimminich/juice-shop

# 確認靶站運行中
# 打開瀏覽器，連到 http://localhost:3000

Step 2：啟動 ZAP 並設定掃描目標

打開 ZAP 桌面版後，你會看到一個歡迎畫面，選擇「Automated Scan」（自動掃描）。

在「URL to attack」欄位輸入：

http://localhost:3000

Step 3：理解 ZAP 的三種掃描模式

ZAP 提供三種掃描模式，就像檢查房子安全的三種力道：

掃描模式	做了什麼	風險程度	適用場景
Spider（爬蟲）	自動探索網站的所有連結和頁面	低（只是瀏覽）	了解網站結構
Passive Scan（被動掃描）	分析經過 ZAP 的流量，不主動攻擊	低（只看不打）	快速找出明顯問題
Active Scan（主動掃描）	對目標發動實際攻擊測試	高（會送惡意 payload）	找出可被利用的漏洞

建議順序：

Spider → Passive Scan → Active Scan
先探索 → 再觀察 → 最後動手打

飛飛觀點：
被動掃描隨時可以跑，它就像站在路邊觀察交通流量。但主動掃描要小心，它會真的發送攻擊請求——所以千萬不要對正式環境的生產系統跑主動掃描，除非你有明確的授權和風險評估。

Step 4：執行自動掃描

在 ZAP 的 Quick Start 標籤中：

輸入目標 URL：<code>http://localhost:3000</code>
點擊「Attack」
ZAP 會依序執行：Spider → Passive Scan → Active Scan

掃描過程中，你可以在下方的面板看到即時進度：

Spider 標籤：顯示發現的 URL 數量
Active Scan 標籤：顯示掃描進度百分比
Alerts 標籤：顯示已發現的安全問題

掃描報告解讀：看懂 ZAP 告訴你的事

掃描完成後，ZAP 會產生一份包含所有發現的報告。讓我們學會怎麼看。

Alert 的風險等級

ZAP 用四種顏色標示風險等級：

風險等級	顏色	說明	處理優先順序
High（高）	🔴 紅色	可被直接利用的嚴重漏洞	立即修復
Medium（中）	🟠 橘色	有潛在風險但利用條件較複雜	盡快修復
Low（低）	🟡 黃色	資訊洩漏或最佳實踐未遵循	排程修復
Informational（資訊）	🔵 藍色	參考資訊，不一定是漏洞	評估後決定

常見的掃描發現與修復建議

以下是對 Juice Shop 或一般 Node.js 網站掃描時最常看到的問題：

🔴 High：SQL Injection

ZAP 發現什麼： 在搜尋功能或登入表單中，注入 SQL 語句後得到異常回應。

修復方式：

// ❌ 危險：字串拼接
const query = <code>SELECT * FROM products WHERE name = '${userInput}'</code>;

// ✅ 安全：參數化查詢
const query = 'SELECT * FROM products WHERE name = $1';
const result = await pool.query(query, [userInput]);

🔴 High：Cross-Site Scripting（XSS）

ZAP 發現什麼： 在輸入欄位注入 <code><script>alert(1)</script></code> 後，腳本被執行。

修復方式：

// ✅ 使用輸出編碼
const he = require('he');
const safeOutput = he.encode(userInput);

// ✅ 使用 DOMPurify 清理 HTML
const createDOMPurify = require('dompurify');
const { JSDOM } = require('jsdom');
const DOMPurify = createDOMPurify(new JSDOM('').window);
const cleanHTML = DOMPurify.sanitize(dirtyInput);

🟠 Medium：Missing Security Headers

ZAP 發現什麼： HTTP 回應缺少關鍵的安全標頭。

修復方式：

const helmet = require('helmet');
app.use(helmet());

// 或手動設定
app.use((req, res, next) => {
  res.setHeader('X-Content-Type-Options', 'nosniff');
  res.setHeader('X-Frame-Options', 'DENY');
  res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
  res.setHeader('Content-Security-Policy', "default-src 'self'");
  next();
});

🟡 Low：Cookie Without Secure Flag

ZAP 發現什麼： Session Cookie 沒有設定 <code>Secure</code> 和 <code>HttpOnly</code> 旗標。

修復方式：

app.use(session({
  secret: process.env.SESSION_SECRET,
  cookie: {
    secure: true,      // 只在 HTTPS 傳送
    httpOnly: true,     // JavaScript 無法存取
    sameSite: 'strict', // 防止 CSRF
    maxAge: 3600000     // 1 小時過期
  }
}));

🔵 Informational：Application Error Disclosure

ZAP 發現什麼： 錯誤頁面暴露了框架版本、堆疊追蹤等內部資訊。

修復方式：

// ✅ 自訂錯誤處理，不洩漏內部資訊
app.use((err, req, res, next) => {
  // 記錄完整錯誤到日誌（內部使用）
  logger.error('Application Error', { 
    error: err.message, 
    stack: err.stack 
  });

  // 回傳給使用者的只有通用訊息
  res.status(500).json({ 
    error: '系統處理時發生錯誤，請稍後再試' 
  });
});

// ✅ 在 Express 中隱藏框架資訊
app.disable('x-powered-by');

處理誤報（False Positives）

ZAP 不是完美的，它有時候會報告「假警報」。處理誤報的步驟：

手動驗證：對 ZAP 標記的漏洞，嘗試手動重現攻擊
分析上下文：看看這個 Alert 在你的系統中是否真的構成風險
標記為誤報：在 ZAP 中將確認的誤報標記為「False Positive」，避免下次重複出現
記錄原因：記下為什麼判定為誤報，方便團隊日後參考

產出掃描報告：給團隊和主管看的安全報告

從 ZAP 桌面版匯出報告

在 ZAP 中，選擇「Report」→「Generate Report」：

報告格式	適用對象	說明
HTML	團隊內部分享	最直觀，可在瀏覽器開啟
JSON	自動化處理	適合程式解析、整合到其他系統
XML	合規稽核	標準格式，適合提交給稽核單位
Markdown	文件紀錄	可直接放進 Git 做版本控制

從 Docker 版產出報告

# Baseline Scan（被動掃描，適合 CI/CD）
docker run -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable \
  zap-baseline.py \
  -t http://your-staging-site.com \
  -r baseline-report.html

# Full Scan（完整掃描，含主動攻擊）
docker run -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable \
  zap-full-scan.py \
  -t http://your-staging-site.com \
  -r full-scan-report.html

# API Scan（API 專用掃描）
docker run -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable \
  zap-api-scan.py \
  -t http://your-staging-site.com/swagger.json \
  -f openapi \
  -r api-report.html

飛飛觀點：
報告不是掃完就丟的。好的做法是每次掃描完，把報告存進 Git，追蹤漏洞數量的趨勢變化。如果 High 和 Medium 的數量持續下降，就代表你們的安全做得越來越好——這就是用數據證明安全投資的價值。

自動化掃描：把 ZAP 整合進 CI/CD Pipeline

手動掃描很好，但我們的目標是讓安全檢查自動化——每次部署前自動跑掃描，發現問題就阻擋部署。

GitHub Actions 整合範例

name: DAST Security Scan

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  dast-scan:
    runs-on: ubuntu-latest

    services:
      # 啟動你的應用程式
      webapp:
        image: your-app:latest
        ports:
          - 3000:3000

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      # 等待應用程式啟動
      - name: Wait for app
        run: |
          for i in $(seq 1 30); do
            curl -s http://localhost:3000 && break
            echo "Waiting for app to start... ($i/30)"
            sleep 2
          done

      # ZAP Baseline Scan（被動掃描，速度快）
      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.14.0
        with:
          target: 'http://localhost:3000'
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a'

      # 上傳掃描報告
      - name: Upload Report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html

自訂掃描規則：控制哪些 Alert 該擋、哪些該放

建立 <code>.zap/rules.tsv</code> 檔案，定義每條規則的處理方式：

10011   IGNORE  (Cookie Without Secure Flag - 開發環境可忽略)
10015   IGNORE  (Incomplete or No Cache-control - 非安全關鍵)
10021   WARN    (X-Content-Type-Options Header Missing)
10038   WARN    (Content Security Policy Header Not Set)
40012   FAIL    (Cross Site Scripting - Reflected - 必須阻擋)
40014   FAIL    (Cross Site Scripting - Persistent - 必須阻擋)
40018   FAIL    (SQL Injection - 必須阻擋)
90022   FAIL    (Application Error Disclosure - 不應洩漏資訊)

FAIL：發現就阻擋部署（Pipeline 失敗）
WARN：發出警告但不阻擋
IGNORE：完全忽略（確認的誤報或可接受的風險）

ZAP Automation Framework：進階自動化

ZAP 的 Automation Framework 是官方推薦的自動化方式，用一個 YAML 檔案控制所有掃描行為：

# zap-automation.yaml
env:
  contexts:
    - name: "My App"
      urls:
        - "http://localhost:3000"
      includePaths:
        - "http://localhost:3000.*"
      excludePaths:
        - "http://localhost:3000/logout"

jobs:
  # Step 1: 被動掃描規則設定
  - type: passiveScan-config
    parameters:
      maxAlertsPerRule: 10
      scanOnlyInScope: true

  # Step 2: 爬蟲探索
  - type: spider
    parameters:
      context: "My App"
      maxDuration: 5  # 最多跑 5 分鐘

  # Step 3: 等待被動掃描完成
  - type: passiveScan-wait
    parameters:
      maxDuration: 10

  # Step 4: 主動掃描
  - type: activeScan
    parameters:
      context: "My App"
      maxRuleDurationInMins: 5
      maxScanDurationInMins: 30

  # Step 5: 產出報告
  - type: report
    parameters:
      template: "traditional-html"
      reportDir: "/zap/wrk/"
      reportFile: "zap-report.html"
    risks:
      - high
      - medium
      - low

用 Docker 執行：

docker run -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable \
  zap.sh -cmd -autorun /zap/wrk/zap-automation.yaml

實戰案例：台灣電商平台的 DAST 掃描流程

場景

你的團隊正在為一家台灣電商平台的會員系統做上線前的安全驗證。系統使用 Node.js + Express + PostgreSQL，功能包含會員註冊、登入、商品瀏覽、購物車、結帳。

Step 1：規劃掃描範圍

## DAST 掃描計畫

### 掃描目標
- 測試環境：https://staging.your-ecommerce.com.tw
- 掃描時間：週末凌晨（避免影響測試環境使用者）
- 掃描工具：OWASP ZAP 2.17.0（Docker 版）

### 掃描範圍
✅ 包含：
- 會員註冊/登入/登出
- 商品搜尋與瀏覽
- 購物車操作
- 結帳流程（測試用信用卡）
- 會員資料修改
- API 端點（/api/v1/*）

❌ 排除：
- 第三方金流回呼（避免影響金流服務商）
- /admin/* 管理後台（另案處理）
- /healthcheck（監控端點）

### 掃描模式
1. Spider + Passive Scan（第一輪）
2. Active Scan（第二輪，針對高風險功能）
3. API Scan（針對 Swagger 定義的 API）

Step 2：執行掃描並記錄發現

假設掃描後得到以下結果：

風險等級	數量	關鍵發現
🔴 High	2	SQL Injection（商品搜尋）、Reflected XSS（會員暱稱）
🟠 Medium	5	缺少 CSP 標頭、CORS 設定過於寬鬆、Session Cookie 未設 SameSite
🟡 Low	8	X-Powered-By 洩漏框架資訊、Cookie 缺少 Secure flag
🔵 Info	12	各項資訊性發現

Step 3：建立修復追蹤表

| 編號 | 風險等級 | 漏洞類型 | 影響範圍 | 負責人 | 修復期限 | 狀態 |
|------|---------|---------|---------|--------|---------|------|
| V-001 | High | SQL Injection | 商品搜尋 API | 後端工程師 A | 3 天內 | 🔧 修復中 |
| V-002 | High | Reflected XSS | 會員暱稱顯示 | 前端工程師 B | 3 天內 | 🔧 修復中 |
| V-003 | Medium | Missing CSP | 全站 | DevOps C | 1 週內 | ⏳ 待處理 |
| V-004 | Medium | CORS 過寬 | API 端點 | 後端工程師 A | 1 週內 | ⏳ 待處理 |

Step 4：修復後重新掃描

修復完成後，一定要重新掃描，確認漏洞確實被修復了。這就像修完水管後要重新開水測試一樣。

# 修復後的驗證掃描
docker run -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable \
  zap-baseline.py \
  -t https://staging.your-ecommerce.com.tw \
  -r verification-scan-report.html

DAST 掃描 Checklist：團隊可直接使用

## DAST 掃描 Checklist

### 掃描前
- [ ] 已取得目標系統的掃描授權
- [ ] 掃描目標為測試/Staging 環境（非生產環境）
- [ ] 已確認掃描範圍（包含/排除的 URL）
- [ ] 已通知相關團隊掃描時程
- [ ] 測試資料已準備好（測試帳號、測試信用卡等）

### 掃描中
- [ ] Spider 探索完成，確認覆蓋率
- [ ] Passive Scan 完成，初步檢視結果
- [ ] Active Scan 完成（注意是否影響目標系統效能）
- [ ] API Scan 完成（如有 Swagger/OpenAPI 定義）

### 掃描後
- [ ] 匯出掃描報告（HTML + JSON）
- [ ] 逐一檢視 High 和 Medium 的 Alert
- [ ] 排除誤報（False Positive），記錄判斷原因
- [ ] 建立漏洞修復追蹤表
- [ ] 將報告存入版本控制（Git）
- [ ] 通知開發團隊修復發現的漏洞
- [ ] 排定修復後的驗證掃描時間

團隊落地建議：讓 DAST 變成日常

建議一：分階段導入，別一次到位

階段	做什麼	工具設定
Week 1-2	手動在 Staging 環境跑 ZAP Baseline Scan	ZAP 桌面版
Week 3-4	把 Baseline Scan 加入 CI/CD	GitHub Actions + ZAP Docker
Month 2	加入 Active Scan（僅限 Staging）	ZAP Automation Framework
Month 3	建立自訂規則和誤報管理流程	rules.tsv + 漏洞追蹤表
持續	每季做一次完整的手動滲透測試	ZAP + 專業資安團隊

建議二：從 Baseline Scan 開始，不要一開始就跑 Full Scan

Baseline Scan 只做被動掃描，速度快（通常幾分鐘內完成）、風險低（不會對目標系統造成影響），非常適合放在每次 PR 或部署前自動執行。

Full Scan 和 Active Scan 因為會實際發動攻擊，建議：

只在 Staging 環境 執行
安排在 非尖峰時段 執行
第一次跑的時候 有人監控 系統狀態

建議三：把 DAST 結果和 SAST 結果關聯起來

當 ZAP 發現一個 SQL Injection 漏洞時，對應回去看 SAST 工具有沒有在同一個位置標記問題。如果 SAST 沒抓到但 DAST 抓到了，代表你的 SAST 規則可能需要調整。反之亦然。

情境	代表的意義	行動
SAST ✅ DAST ✅	兩者都找到，很好	修復漏洞
SAST ❌ DAST ✅	SAST 漏掉了	修復漏洞 + 調整 SAST 規則
SAST ✅ DAST ❌	可能是 SAST 誤報	手動驗證
SAST ❌ DAST ❌	沒問題…或兩個都漏掉了	考慮搭配滲透測試

建議四：建立「安全品質門檻」

在 CI/CD Pipeline 中設定明確的門檻——什麼等級的漏洞會阻擋部署：

# 安全品質門檻定義
security_gate:
  block_deployment:
    - high_risk_count > 0      # 有任何 High 風險就擋
    - medium_risk_count > 5    # Medium 超過 5 個就擋
  warn_only:
    - low_risk_count > 20      # Low 超過 20 個發警告
    - new_alerts > 0           # 有任何新發現就通知

常見問題 FAQ

Q1：ZAP 掃描要跑多久？會不會影響系統效能？

Baseline Scan（被動掃描）通常幾分鐘內完成，對系統效能影響很小。Full Scan（含主動掃描）時間取決於網站大小，小型網站可能 30 分鐘到 1 小時，大型網站可能需要數小時。主動掃描會產生大量請求，建議在 Staging 環境執行，並在非尖峰時段進行。

Q2：ZAP 跟 Burp Suite 比，該選哪個？

ZAP 是開源免費的，功能已經非常強大，對於大部分團隊來說綽綽有餘。Burp Suite Professional 是付費工具（年費約 USD $449），在某些進階功能上更強（如更好的爬蟲引擎、Intruder 模組）。如果你是資安新手或預算有限，從 ZAP 開始絕對沒問題。如果團隊有專職的滲透測試人員，可以考慮 Burp Suite Professional 作為進階工具。

Q3：ZAP 掃不到某些頁面怎麼辦？

ZAP 的 Spider 有時候無法探索到需要登入才能看到的頁面，或是前端框架（如 React、Vue）動態生成的內容。解決方案：

登入問題：使用 ZAP 的 Authentication 設定，讓 ZAP 能自動登入
前端框架問題：使用 ZAP 2.16.0+ 的 Client Spider，它能更好地處理 JavaScript 驅動的頁面
手動探索：先手動瀏覽網站（透過 ZAP Proxy），讓 ZAP 記錄所有頁面，再執行主動掃描

Q4：掃描結果一大堆 Alert，怎麼分辨哪些是真的、哪些是誤報？

先從 High 風險開始看，數量通常不多。對每個 High Alert，用 ZAP 的「Resend」功能手動重送攻擊請求，看看回應是否真的表示漏洞存在。如果你不確定，可以請教資安同事或在 OWASP 社群發問。Medium 和 Low 的 Alert 可以先建立一份清單，逐步處理。

Q5：我的團隊只有開發人員，沒有資安專家，適合用 ZAP 嗎？

完全適合。ZAP 的設計目標之一就是讓開發人員也能做基本的安全測試。Baseline Scan 幾乎不需要安全知識就能執行和解讀結果。隨著團隊經驗累積，可以慢慢學習 Active Scan 和更進階的功能。記住，有做總比沒做好——就算只是跑一次 Baseline Scan，你已經比大多數團隊做得多了。

結語：安全測試不是找碴，而是找到讓系統更強的機會

很多開發者聽到「安全掃描」會緊張，覺得好像是要來挑自己程式碼的毛病。但換個角度想——DAST 就像你的系統的「健康檢查」。你不會因為醫生發現你膽固醇偏高就生醫生的氣，反而會感謝他提早發現問題，讓你有機會調整。

OWASP ZAP 就是你的系統醫生。它免費、開源、社群活躍，從個人專案到企業級應用都能勝任。

回到蓋房子的比喻——你的房子蓋好了，安裝了防盜門、監視器、消防設備。但你得真正測試一下這些設備有沒有用。DAST 就是幫你做這件事的。

安全不是恐懼，而是創造的基礎。
當你知道系統經過了真實的攻擊測試，你就能更有信心地面對使用者——因為你知道，你的房子不只看起來安全，而是真的安全。

[安全測試] 002 DAST 動態測試實戰：用 OWASP ZAP 掃描你的網站，讓漏洞無所遁形

為什麼你需要 DAST？靜態掃描抓不到的，動態掃描來補

SAST vs. DAST：一個看設計圖，一個看成品

什麼是 OWASP ZAP？免費又強大的安全掃描神器

ZAP 的核心運作原理：中間人代理

ZAP 能幫你找到什麼？

安裝 OWASP ZAP：三種方式任你選

方式一：桌面版安裝（推薦新手）

方式二：Docker 安裝（推薦 CI/CD 整合）

方式三：套件管理器

ZAP 基本操作：從零開始掃描你的第一個網站

重要提醒：只掃描你有權限的系統

Step 1：啟動練習靶站

Step 2：啟動 ZAP 並設定掃描目標

Step 3：理解 ZAP 的三種掃描模式

Step 4：執行自動掃描

掃描報告解讀：看懂 ZAP 告訴你的事

Alert 的風險等級

常見的掃描發現與修復建議

🔴 High：SQL Injection

🔴 High：Cross-Site Scripting（XSS）

🟠 Medium：Missing Security Headers

🟡 Low：Cookie Without Secure Flag

🔵 Informational：Application Error Disclosure

處理誤報（False Positives）

產出掃描報告：給團隊和主管看的安全報告

從 ZAP 桌面版匯出報告

從 Docker 版產出報告

自動化掃描：把 ZAP 整合進 CI/CD Pipeline

GitHub Actions 整合範例

自訂掃描規則：控制哪些 Alert 該擋、哪些該放

ZAP Automation Framework：進階自動化

實戰案例：台灣電商平台的 DAST 掃描流程

場景

Step 1：規劃掃描範圍

Step 2：執行掃描並記錄發現

Step 3：建立修復追蹤表

Step 4：修復後重新掃描

DAST 掃描 Checklist：團隊可直接使用

團隊落地建議：讓 DAST 變成日常

建議一：分階段導入，別一次到位

建議二：從 Baseline Scan 開始，不要一開始就跑 Full Scan

建議三：把 DAST 結果和 SAST 結果關聯起來

建議四：建立「安全品質門檻」

常見問題 FAQ

Q1：ZAP 掃描要跑多久？會不會影響系統效能？

Q2：ZAP 跟 Burp Suite 比，該選哪個？

Q3：ZAP 掃不到某些頁面怎麼辦？

Q4：掃描結果一大堆 Alert，怎麼分辨哪些是真的、哪些是誤報？

Q5：我的團隊只有開發人員，沒有資安專家，適合用 ZAP 嗎？

結語：安全測試不是找碴，而是找到讓系統更強的機會

延伸閱讀