網站弱點掃描前要準備什麼？資產範圍、授權、帳號與安全窗口完整清單

先講結論：開始前至少備齊六類資料

一個可執行的弱點掃描任務，至少需要六類輸入：合法授權與測試規則、完整資產範圍、預期檢測目標、登入帳號與角色、API 或特殊流程資料，以及安全執行與事件聯絡機制。這些資料不只讓掃描器能運作，也決定結果能否代表真實風險。

如果只能先完成一件事，應先確認『誰有權授權這次測試』。網域出現在公司官網、由公司付款，或由某個部門使用，都不一定代表該窗口有權允許安全測試；CDN、SaaS、雲端平台、代管商與合作夥伴資產也可能有各自的測試政策。未確認授權前，不應直接對目標發起掃描。

準備清單的價值在於降低兩種風險：第一種是檢測不足，例如沒有登入帳號而漏掉會員與後台；第二種是營運副作用，例如測試觸發大量通知、帳號鎖定、付款或資料刪除。專業掃描要同時控制這兩類風險。

• 授權與規則：授權人、目的、期間、來源、方法、限制、停止條件與資料處理
• 資產與邊界：網域、子網域、API、環境、IP、技術入口、第三方依賴與排除項目
• 覆蓋目標：匿名／登入範圍、角色、關鍵流程、OWASP 測試面向與預期深度
• 存取資料：測試帳號、MFA、Token、憑證更新、租戶與權限矩陣
• 安全執行：窗口、速率、測試資料、禁止操作、監控、聯絡人與中止機制
• 交付治理：報告接收人、證據遮罩、加密、保存期限、刪除與複驗規則

第一步不是開工具，而是確認合法授權

NIST 將 Rules of Engagement（ROE，測試交戰規則）定義為測試前建立的詳細準則與限制，用來授權受測活動在明確範圍內執行。換句話說，ROE 不是形式文件，而是掃描團隊可以做什麼、何時必須停止，以及遇到異常時如何處理的操作依據。

授權文件應由具備資產管理或委任權限的人確認，並列出受測組織、服務提供者、執行期間與測試來源。若網站使用第三方代管、CDN、雲端平台、金流、身分提供者或供應商 API，還要查核服務條款與測試政策；企業對自己的應用程式有權限，不代表能測試底層共享服務。

授權範圍要能被技術人員直接執行，不能只寫『公司網站』。較好的寫法會明列網域、子網域、API Base URL、IP、環境與例外，並說明重新導向後的外部網域、第三方支付頁、客服系統與外掛服務是否在範圍內。

• 授權人與資產擁有者：誰核准、誰負責業務影響、誰可以變更範圍
• 執行單位：供應商、內部團隊、掃描來源 IP 與必要識別方式
• 允許期間：開始與結束日期、每日可執行時段、時區與維護窗口
• 允許方法：自動化掃描、登入測試、API 測試、檔案上傳或人工驗證
• 禁止行為：拒絕服務、社交工程、實際付款、資料刪除、權限持久化等
• 停止條件：錯誤率、延遲、告警、資料異常或業務窗口要求中止時的處理方式

把資產範圍寫成可驗證的清單

只提供首頁網址，通常只會得到首頁附近的觀察。現代網站可能由多個子網域、前端應用程式、後端 API、CDN、物件儲存、身分服務與管理介面組成；某些入口不會從公開導覽列連出，掃描器自然無法自行推導完整邊界。

資產清單應同時描述『包含什麼』與『不包含什麼』。如果排除付款、登出、刪除、批次匯入或特定第三方路徑，要記錄排除原因與補充驗證方式，否則報告中的低風險可能只是覆蓋不足。對 DNS 萬用字元、共享 IP 或自動擴縮環境，也要避免把不屬於授權範圍的服務一起納入。

範圍在任務期間可能改變。新子網域、藍綠部署、暫時測試主機或 API 版本切換，都應由指定窗口確認後再加入，而不是讓掃描團隊自行擴張。每次變更要保留時間、核准人與原因，才能支援日後稽核。

先定義檢測目標，才能選擇正確深度

弱點掃描的目的可能不同：建立公開攻擊面基線、檢查登入後功能、驗證 OWASP 類型問題、確認 API 權限、檢查版本上線，或複驗既有弱點。若沒有先寫目標，團隊很容易用一次淺層掃描回答所有問題。

OWASP Web Security Testing Guide 強調測試應依應用程式與業務風險調整。自動化工具適合提供廣度與持續性，但複雜業務邏輯、跨角色授權、跨租戶存取、競態條件與多步驟流程，通常仍需要人工或半自動驗證。準備階段就應說明哪些風險由本次掃描處理、哪些另由程式碼分析、SCA 或滲透測試補足。

目標也要包含成功條件。例如『會員與管理員主要流程均完成登入掃描』比『完成網站掃描』更可驗證；『已匯入 OpenAPI 並覆蓋所有對外 Endpoint』也比『包含 API』更具體。

登入帳號不是一組就夠：建立角色與權限矩陣

許多高影響弱點只存在於登入後，例如水平越權、管理功能暴露、跨租戶資料存取與物件層級授權錯誤。若只提供單一一般帳號，掃描結果無法比較不同角色能看見與操作的資源，也很難驗證權限邊界。

OWASP 建議先理解角色定義與權限配置，至少區分一般使用者與管理角色；在多租戶或複雜系統中，還要準備不同組織、部門、方案與資料所有權的帳號組合。最實用的做法是建立角色—功能—資料範圍矩陣，明確指出每個角色應允許與應禁止的操作。

帳號必須是專用測試帳號，不應提供員工個人帳密或正式客戶帳號。若使用 MFA、SSO、CAPTCHA、短效 Token、裝置綁定或 IP 限制，要提前決定自動化登入方式、Token 更新方式與安全例外；任何繞過都要限時、可追蹤並在任務後撤銷。

• 至少準備匿名、一般會員與管理員；多租戶系統再增加不同租戶的同級帳號
• 為帳號配置可識別的測試資料，避免存取真實客戶內容
• 記錄登入 URL、SSO 流程、MFA 方式、Token 壽命、登出與密碼重設路徑
• 確認鎖定門檻、同時登入限制、IP 限制、裝置信任與 Session 逾時
• 約定憑證傳遞、輪替、撤銷與外洩應變，不要把密碼放在一般 Email 或報告附件

API 掃描要準備規格、驗證方式與業務上下文

API 不一定能從網站連結完整發現。提供 OpenAPI／Swagger、Postman Collection、GraphQL Schema、gRPC 定義或其他介面文件，可以協助工具理解 Endpoint、參數、方法與資料格式。OWASP 也指出公開文件可能過時或不完整，因此規格仍要和實際路由、Gateway 與部署版本比對。

API 的授權問題往往需要多組 Token 或帳號才能驗證。準備資料時應說明 Token 取得方式、Scope、Audience、租戶、物件識別碼與可用測試資料，並標示哪些 API 會寄信、扣款、建立訂單、呼叫第三方或改變不可逆狀態。

若 API 有版本、區域、行動端專用入口、WebSocket、Webhook 或非公開管理介面，也要在範圍中獨立列出。掃描器成功匯入一份規格，不代表實際攻擊面已完整；未記錄或已棄用但仍在線的 Endpoint，反而常是重要風險來源。

• Base URL、版本、環境、Gateway 與允許來源
• OpenAPI／Swagger、Postman、GraphQL Schema、gRPC 或事件介面定義
• 驗證流程、Token 取得與刷新、Scope、角色、租戶與測試物件
• 會產生費用、通知、外部呼叫、資料寫入或大量處理的 Endpoint
• 速率限制、配額、冪等鍵、重試規則、Webhook 回呼與非同步完成方式

測試資料與業務副作用要提前隔離

自動化測試會重複提交表單、修改參數與建立請求。如果表單連到 CRM、Email、簡訊、客服、金流、物流或帳務系統，單次掃描就可能產生大量真實副作用。開始前應盤點所有會離開應用程式邊界的流程，並決定使用沙盒、攔截器、測試租戶或明確排除。

優先使用合成資料與專用測試物件，不要把真實個資、付款資訊、Token 或機密文件交給掃描流程。若正式環境無法完全隔離，至少要設定可辨識前綴、接收信箱、測試金額、資料保存時間與任務後清理方式，並確認清理不會破壞稽核或事件紀錄。

資料刪除、取消訂單、權限變更、帳號停用與批次操作通常不適合由一般自動化掃描直接執行。需要驗證時，應在受控資料與明確監看下進行針對性測試，而不是把高風險路徑開放給全站爬行。

正式站還是測試站？關鍵在環境代表性

測試環境較容易隔離資料與副作用，也適合執行侵入性較高的驗證；但若程式版本、WAF、CDN、TLS、Header、Cookie、SSO、雲端權限或第三方串接與正式環境不同，測試結果就無法完整代表正式風險。

較可靠的策略是分層執行：先在與正式環境高度一致的預備環境完成深度掃描，再於正式環境以授權、節流和排除條件執行必要的公開面與部署後驗證。環境差異應列入報告限制，而不是假設測試站安全就代表正式站安全。

若只能選擇一個環境，應由資產擁有者、技術團隊與安全人員共同評估代表性與營運風險。對正式環境的掃描要有監控與中止能力；對測試環境的結果則要明確說明哪些正式控制沒有被驗證。

安全窗口不是挑離峰而已，還要確保有人能處理

掃描窗口應同時考慮業務流量、批次作業、備份、部署、第三方配額與值班能力。把任務排在半夜不一定比較安全；如果沒有人能判斷錯誤率上升、停止任務或恢復服務，風險反而更高。

開始前應定義掃描速率、並行數、最大執行時間、逾時、重試與排除路徑，並由應用程式、網路或 SOC 團隊監看錯誤率、延遲、CPU／記憶體、WAF、登入失敗與第三方告警。掃描流量也應有可識別的來源 IP 或 Header，方便與真實攻擊區分。

停止條件要可量化，例如 5xx 錯誤率、回應時間、資源使用、帳號鎖定、告警數或業務交易異常超過門檻。指定聯絡人應有權要求暫停，掃描執行方則必須能立即停止並保留當下任務與日誌。

不要為了讓掃描通過，就把所有防護關掉

WAF、Bot 防護、CDN、Rate Limit、MFA 與存取控制本身就是正式攻擊面的一部分。若全部停用，掃描看到的是一個不存在於日常營運的環境；但若所有請求都被封鎖，報告也只會顯示防護層，而看不到後端應用程式。

合理做法是先定義測試目的。若要評估外部攻擊者可見面，應保留正式控制並記錄阻擋結果；若要深入檢查應用程式，可對指定來源做最小、限時且可稽核的 Allowlist，或在等價預備環境補做。兩種結果應分開呈現，不應混為同一次『完整掃描』。

任何例外都要記錄啟用時間、對象、範圍、核准人與撤銷驗證。任務結束後應確認臨時規則、測試帳號、Token、VPN、DNS 與防火牆例外都已復原。

把準備、掃描、報告與清理連成一條可稽核流程

好的準備不是把文件交給供應商後就結束。授權範圍要轉成任務設定，角色矩陣要轉成登入覆蓋，安全窗口要連到監控與停止機制，最後再以報告與清理紀錄證明任務按約定完成。任何一段斷裂，都可能讓掃描結果失真。

下圖把網站掃描的預備流程整理成四個關卡：先確認授權範圍，再準備角色與 API 規格，接著在受控窗口執行，最後交付證據並清理測試資料。每個關卡都應有負責人與可驗證輸出。

報告與證據本身也是敏感資料

弱點報告可能包含內部路徑、技術版本、請求與回應、Session、Token、個資片段、資料庫欄位與可重現攻擊的方法。若透過一般 Email、公開連結或過度寬鬆的協作空間傳遞，報告本身就可能成為新的外洩來源。

開始前應定義接收人、加密與傳輸方式、存取權限、保存期限、備份、下載紀錄與刪除程序。證據應採最小揭露原則：能證明問題即可，敏感值要遮罩；若完整內容對修復必要，則用受控附件或安全平台交付。

測試帳號、API Key 與 Token 不應永久寫進報告。報告完成後還要確認暫存檔、瀏覽器 Session、掃描器憑證庫與供應商工作空間中的資料依約清理，並保留必要的刪除或撤銷證明。

如何判定『準備完成』？用驗收條件取代口頭確認

準備完成不應只靠一句『帳號已給』。每一類輸入都要有可驗證的驗收條件，並在掃描前做小範圍連線與登入測試。若登入失敗、API 文件無法匯入、Allowlist 未生效或監控窗口無人值班，應先修正再啟動完整任務。

預檢不需要執行深度探測。它的目的是確認 DNS、TLS、網路、登入、角色、API、速率、告警與停止流程都能運作，並建立正常回應的基線。這能避免掃描跑了數小時後，才發現所有請求都停在登入頁或被 WAF 擋下。

可直接使用的掃描前最終檢查清單

下列項目可作為內部需求單、供應商進場表或正式掃描前的 Go／No-Go 檢查。若某一項不適用，也應記錄理由，而不是留白。

• 已由具備權限的資產擁有者或委任人完成書面授權
• ROE 已列出範圍、來源、時段、方法、限制、停止條件與聯絡人
• 已列出網域、子網域、API、環境、IP／Port、第三方邊界與排除項目
• 已確認受測版本、部署時間與測試環境和正式環境的差異
• 已定義匿名、登入、角色、API、業務流程與人工補充測試的覆蓋目標
• 已準備專用測試帳號、角色矩陣、MFA／SSO、Token 更新與撤銷方式
• 已提供可用的 API 規格、驗證方式、測試物件與高副作用 Endpoint 清單
• 已隔離 Email、簡訊、金流、CRM、物流、儲存與其他外部副作用
• 已設定速率、並行、逾時、最大時長、禁止路徑與可辨識掃描來源
• 監控、值班、通報與立即停止機制已確認，必要時可安全恢復
• 已確認報告接收人、加密、證據遮罩、保存期限與刪除方式
• 任務後會撤銷憑證與臨時例外、清理測試資料，並安排修復複驗

準備做得越精確，掃描結果才越接近真實風險

網站弱點掃描的品質，不只由掃描引擎決定。合法授權確保測試有明確邊界，資產清冊決定是否漏測，角色帳號與 API 規格決定能看多深，安全窗口與停止條件則確保檢測不會犧牲營運穩定。

企業可以先從一個重要網站建立標準化預備包：一份 ROE、一份資產清冊、一張角色矩陣、一組 API 與登入資料，以及一套窗口、監控和交付規則。流程跑順後再複製到其他資產，會比每次臨時收集資訊更可靠，也更容易持續掃描與修復追蹤。