網站弱點掃描能檢測什麼？不能檢測什麼？完整覆蓋範圍解析

先講結論：掃描結果不是網站安全的合格證書

網站弱點掃描通常以 DAST（Dynamic Application Security Testing，動態應用程式安全測試）方式，從網站外部送出安全測試請求，再根據 HTTP 回應、頁面行為、Cookie、標頭與錯誤訊息判斷是否存在風險。它特別適合檢查已部署的網站與 API，並在版本或設定持續變動時排程重複執行。

但掃描器不會自動理解企業完整的業務規則，也看不到沒有被爬取的頁面、未提供帳號的角色、沒有匯入的 API，或只在特定資料狀態下出現的流程。OWASP Web Security Testing Guide 明確指出，黑箱測試難以遍歷整個程式碼與所有執行路徑；每增加一個決策分支，可能路徑就會快速成長。

所以專業報告不能只寫『通過』或『未發現』。正確說法應包含檢測時間、目標版本、資產範圍、帳號與角色、成功爬取的頁面或端點，以及受限制或沒有測試的項目。只有把覆蓋範圍說清楚，掃描結果才具有決策價值。

掃描器如何看網站：從攻擊面到可重現證據

一次網站掃描通常從種子網址開始，解析頁面連結、表單、前端路由與網路請求，逐步建立可到達的攻擊面。掃描器接著辨識輸入位置，例如查詢參數、表單欄位、JSON 欄位、HTTP 標頭與 Cookie，再對適合的輸入點發送受控探測。

可靠的判定必須建立在可觀察差異上。例如輸入特殊字元後，回應是否出現資料庫錯誤；植入測試字串後，內容是否未經編碼就反射進 HTML；移除或替換驗證資訊後，伺服器是否仍回傳受保護資料；安全標頭或 Cookie 屬性是否缺失。這些請求與回應就是後續人工確認及修復複驗的證據。

掃描器的能力不只取決於弱點規則，也取決於探索能力。若網站大量使用 JavaScript、WebSocket、一次性 Token、複雜表單或多步驟流程，掃描器是否能維持狀態並正確走完流程，往往比規則數量更影響結果。

• 範圍：哪些網域、子網域、路徑、API 與環境被授權納入
• 探索：掃描器實際找到多少頁面、表單、參數、端點與內容類型
• 狀態：是否能維持登入、Token、CSRF 防護與必要的流程資料
• 探測：針對輸入、設定與行為執行哪些測試，測試是否被 WAF 或限流阻擋
• 證據：每項發現是否能對應到明確位置、請求、回應與重現條件

自動化掃描最擅長檢測哪些問題？

自動化掃描最擅長處理『可以由外部輸入觸發，並能從回應確認』的技術問題。這些檢查規則可以在大量頁面與端點上反覆執行，適合建立公開網站的基礎安全覆蓋，也適合在改版與設定變更後重新驗證。

常見項目包含部分輸入驗證與注入風險、反射型跨網站指令碼、錯誤訊息或敏感資訊暴露、目錄列表、公開管理介面、危險 HTTP 方法，以及部分伺服器與中介軟體設定。掃描器也能檢查 TLS、HTTP 安全標頭、CORS、Cookie 的 Secure、HttpOnly 與 SameSite 屬性等可直接觀察的安全基線。

需要注意的是，『可以自動化檢測』不代表對所有網站都有相同準確度。相同弱點在不同框架、回應格式與防護機制下會呈現不同訊號；掃描器通常會提供疑似或已驗證程度，仍應由人員確認證據與業務影響。

• 公開頁面、表單、查詢參數與可辨識的 API 輸入點
• 部分 SQL Injection、命令注入、路徑穿越與伺服器端請求偽造跡象
• 反射型 XSS、未編碼輸出與部分用戶端腳本風險
• 敏感錯誤、版本資訊、備份檔、目錄與非預期資源暴露
• TLS、HTTP 標頭、CORS、Cookie 與快取等部署安全設定
• 已知伺服器或元件特徵及其可能對應的公開弱點

哪些項目有機會檢測，但必須先具備條件？

許多重要風險不是掃描器完全做不到，而是需要額外的存取權與測試資料。登入後頁面必須提供可用帳號與穩定的登入方式；API 必須讓掃描器知道端點、方法、欄位與驗證資訊；多角色系統必須為每一種角色建立獨立的測試身分。

例如水平權限問題需要至少兩個同級帳號，才能確認 A 使用者是否能讀取 B 使用者的資料；垂直權限問題則需要一般使用者與管理角色進行比較。若只提供單一帳號，掃描器可能找到可疑識別碼，卻無法可靠證明跨帳號存取是否成立。

複雜 SPA、GraphQL、行動應用程式後端與大量非同步請求，也通常需要匯入 OpenAPI、GraphQL Schema、瀏覽器錄製流程或代理流量。這些設定不是附加工作，而是測試範圍本身的一部分。

• 登入後功能：需要測試帳號、登入巨集或可更新的 Session／Token
• 角色與物件權限：需要多個角色及足以建立、讀取與修改的測試資料
• REST／GraphQL API：需要規格、請求範例、驗證方式與環境端點
• 多步驟交易：需要可重複的起始狀態、流程錄製與資料清理方式
• SPA 與動態介面：需要支援瀏覽器執行、前端路由及非同步請求探索
• 受 WAF 或限流保護的環境：需要核准來源、速率上限與監控協調

登入後掃描：不是成功登入就代表完整覆蓋

登入後掃描的第一個關卡是維持有效狀態。Session 可能在固定時間失效，Token 可能需要刷新，MFA 可能要求人工或測試專用流程，CSRF Token 也可能隨每個請求改變。若掃描器在執行中悄悄登出，後續請求仍可能回傳 200 狀態碼與登入頁，造成表面成功、實際未覆蓋的假象。

專業做法是設定登入成功與失敗的辨識條件，並在報告中記錄驗證狀態維持時間、到達的受保護頁面及角色。對不同權限的使用者應分開掃描，避免管理員帳號的廣泛權限掩蓋一般使用者本來不應接觸的功能。

測試帳號也要遵循最小必要原則。應建立專用帳號與隔離資料、限制可造成真實交易的操作，並在掃描前定義哪些刪除、付款、通知或外部整合端點禁止自動執行。

API 掃描：規格完整度直接決定檢測深度

API 沒有傳統頁面與連結可供爬取時，掃描器很難靠猜測找出完整攻擊面。OpenAPI 文件、GraphQL Schema、Postman Collection、代理錄製流量或閘道匯出資料，可以提供端點、HTTP 方法、欄位型別、必要標頭與範例內容，讓掃描器從『發現端點』進入真正的安全探測。

只有端點名稱仍然不夠。許多 API 需要先建立資源才能查詢或修改，需要特定 ID、租戶、角色與狀態，也可能透過短效 Token 或簽章驗證。若測試資料無法建立、狀態不能重置，掃描就容易停在第一步。

API 結果應同時記錄端點覆蓋與方法覆蓋。只測到 GET 不代表同一路徑的 POST、PATCH 與 DELETE 已被檢查；只測匿名請求，也不代表登入後的物件權限與資料暴露已經驗證。

哪些問題不能只靠網站弱點掃描判定？

最明顯的邊界是需要理解『這件事在業務上是否合理』的問題。掃描器可能看得懂價格欄位與訂單 API，卻不知道折扣是否可以重複套用、退款是否必須經過第二人核准、或新客優惠是否不應轉讓。這類業務邏輯必須先知道正常規則，才能設計濫用情境。

複雜權限、跨角色攻擊鏈與多個低風險問題的組合，也很難由單一掃描結果準確評估。NIST SP 800-115 提醒，多個個別看似低風險的弱點可能結合成更高風險，而掃描器無法遍歷幾乎無限的攻擊組合；這類情境需要滲透測試與具備脈絡的人工分析。

此外，網站 DAST 不會讀取所有原始碼與第三方套件清單，因此不能取代 SAST、程式碼審查與 SCA；它也不能單獨驗證架構設計、雲端身分權限、社交工程、實體安全、內部流程或事件應變能力。

• 業務邏輯濫用、價格或額度操弄、流程跳步與競態條件
• 需要多個帳號、租戶、角色或系統才能證明的複雜授權關係
• 多個弱點、設定與人員行為串連後形成的完整攻擊路徑
• 原始碼中的不可達風險、未部署程式與第三方元件完整清冊
• 架構與信任邊界是否合理，以及安全控制是否符合業務需求
• 社交工程、實體安全、內部人員、監控告警與事件應變成效

網站弱點掃描覆蓋能力比較表

下表描述一般網站 DAST 的典型能力，而不是對所有工具的功能保證。實際結果仍取決於網站技術、帳號、資料、規格、測試限制與掃描設定。

用三層覆蓋模型規劃檢測，而不是只買一套工具

企業可以把網站檢測拆成三層。第一層是公開且可重複的技術攻擊面，交由排程掃描建立穩定基線；第二層是需要登入、角色、API 規格與交易資料的條件式覆蓋，必須由系統負責人與資安團隊共同維護；第三層則是依風險選擇的人工深度驗證。

這個模型的重點不是把所有項目都做成最高強度，而是讓每一個重要資產都有清楚的檢測責任。公開官網可以偏重第一層；會員、後台與 API 應加強第二層；付款、權限管理、個資與核心營運流程則應定期進入第三層。

• 第一層｜公開面：網站頁面、表單、標頭、Cookie、TLS、公開 API 與已知暴露
• 第二層｜條件面：登入後功能、多角色、租戶、API 規格、流程資料與狀態維持
• 第三層｜脈絡面：業務邏輯、信任邊界、攻擊鏈、重大交易與高風險濫用情境

誤報、漏報與不確定結果應該怎麼處理？

誤報是工具判定存在風險，但人工檢查後發現證據不足或防護有效；漏報則是風險確實存在，卻沒有被工具發現。兩者都無法只靠增加規則完全消除，因為網站回應、框架、WAF 與業務行為具有高度差異。

降低誤報需要保留原始證據、標示信心程度並進行人工判讀；降低漏報則要改善探索、登入、API 匯入、角色覆蓋與測試資料，並搭配其他測試方法。若工具沒有記錄爬取與測試範圍，團隊就無法分辨『真的沒有發現』與『根本沒有測到』。

對不確定結果，不應直接刪除或提升到最高等級。應建立待確認狀態，指派負責人補充資料或重現，並保留判讀理由。相同發現在後續版本重新出現時，這些脈絡能避免團隊重複調查。

讀報告時，務必區分三種完全不同的狀態

『已發現』表示掃描在本次範圍與條件下取得足以支持判定的證據，但嚴重度仍要結合資產暴露、可利用性與業務影響。『未發現』表示某項測試已實際執行，沒有觀察到符合判定條件的結果；它不是永久安全保證。

『未覆蓋』則代表項目不在範圍、頁面未被探索、登入失敗、權限不足、API 未匯入、流程無法建立，或測試因安全限制被跳過。這一欄往往比弱點數更重要，因為它直接揭露團隊目前看不見的地方。

高品質報告還應提供掃描版本、時間、來源、目標、帳號角色、成功與失敗的請求數、端點或頁面清單、排除項目、停止條件及異常紀錄。如此才能在下次掃描時比較覆蓋與風險是否真的改善。

如何驗收網站弱點掃描服務的真實覆蓋率？

採購與 PoC 不應只比較弱點數量。數量較多可能代表覆蓋較廣，也可能只是規則較敏感、重複結果較多或誤報未整理。企業應準備一個已知結構與測試案例的授權環境，檢查工具是否能抵達重要功能、維持登入、辨識多角色與留下可重現證據。

覆蓋率也不是單一百分比。網站可以分別衡量已知頁面、API 端點、HTTP 方法、輸入參數、角色與關鍵流程的覆蓋情形。這些分母必須來自資產清冊、路由、API 規格或業務流程，而不是由掃描器自己發現多少就算多少。

• 是否列出已探索與未探索的頁面、端點、方法、參數及排除原因？
• 登入中斷時是否會告警，而不是繼續把登入頁當成有效回應？
• 能否分別呈現匿名、一般使用者、管理者與不同租戶的覆蓋？
• 是否支援匯入 API 規格、瀏覽器流程與必要的測試資料？
• 每項發現是否有請求、回應、位置、判定依據與可執行的修復方向？
• 能否對修復項目精準複驗，並區分已修復、仍存在與無法驗證？
• 掃描變慢、被阻擋、出現大量錯誤或影響服務時，是否有明確停止機制？

把掃描放在正確位置，才能形成持續安全流程

網站弱點掃描不是因為有盲區就失去價值。相反地，它能以遠低於每次人工檢測的執行負擔，持續觀察公開網站、登入後功能與 API 的變化，提早發現重複出現的輸入處理、部署設定與暴露問題。前提是企業誠實管理它的覆蓋條件。

成熟做法是讓排程 DAST 負責可重複的外部檢測，以 SAST 與 SCA 補足程式碼和第三方元件，以威脅建模與架構審查處理設計風險，再對高影響流程安排滲透測試。所有發現進入同一套判讀、排序、修復與複驗流程，才不會形成彼此分離的報告。

真正值得追蹤的不是『今天掃出幾個弱點』，而是重要資產是否被正確覆蓋、盲區是否縮小、高風險發現是否在期限內修復，以及修復後是否留下可驗證的證據。