採購規格寫「系統須符合 OWASP Top 10」，廠商建議書寫「依 OWASP Top 10 開發」，滲透測試報告寫「已涵蓋 OWASP Top 10」。三句話聽起來都很專業，卻都很難驗收：OWASP Top 10 列的是十類風險，不是可以逐項打勾的需求清單，OWASP 自己也這麼說[1]。

這篇寫給委外開發網站或 App、負責撰寫 RFP 或驗收檢測報告的主管與 IT 人員：先說明 OWASP Top 10 是什麼、2025 版列了哪些風險、和 2021 版差在哪裡；再談寫需求與合約時該引用什麼、看到「涵蓋 OWASP Top 10」的報告要追問什麼；最後整理《資通安全責任等級分級辦法》的資通系統防護基準，對開發與測試各階段的要求。

OWASP Top 10 是什麼，不是什麼

OWASP 把 Top 10 定位為給開發人員與網頁應用程式安全的「標準意識文件」（standard awareness document），代表業界對網頁應用程式最關鍵安全風險的廣泛共識[2]。

2025 版最初以候選版（Release Candidate）公開，OWASP 在 2025 年 12 月下旬把專案原始檔標題中的「Release Candidate」字樣移除[3]；專案頁目前把 2025 版列為最新發布的版本，2021 版改列為前一版[2]。新的 RFP、合約與檢測範圍應以 2025 版為準，但引用 2021 版的既有合約還會存在一段時間，兩版要分清楚（見下一節）。

2025 版是第八版，資料貢獻者提供了超過 280 萬個應用程式的測試資料[4]。十個類別中，八個依資料排名，另外兩個由社群問卷選出：OWASP 的理由是測試資料只反映工具已經能大規模檢測的弱點，看的是過去，有些重要風險可能永遠無法可靠地測試、也就不會出現在資料裡[4]。每個類別是一組 CWE（常見弱點列舉）的集合，十個類別共涵蓋 248 個 CWE[4]。

它不是標準，也不是完整清單

OWASP 在 Top 10 文件中直說：Top 10 是意識文件，不是完整清單，只是起點；自 2003 年推出以來，許多組織把它當成事實上的業界標準，但若拿來當開發或測試標準，它只是「最低限度」[1]。原因是 Top 10 記錄的是風險，不一定是容易測試的問題：例如 A06 不安全設計超出多數測試方式的範圍；日誌與監控是否真的有效，只能靠訪談與調閱實際的事件應變紀錄來確認[1]。OWASP 也指出，工具無法全面偵測、測試或防護 Top 10 的風險，因此不鼓勵任何「完整涵蓋 OWASP Top 10」的宣稱，因為那根本不是事實[1]。要採用應用程式安全標準，OWASP 建議改用 ASVS（應用程式安全驗證標準），因為它的設計就是可驗證、可測試[1]。

2025 版十大風險

以下依 OWASP 的編號與英文正式名稱列出，括號內為本文譯名，例子取自 OWASP 各類別頁面的攻擊情境：

  1. A01:2025 Broken Access Control（存取控制失效）：存取控制要確保使用者不能超出被授權的範圍行事，失效時常導致未經授權的資料揭露、竄改或刪除[5]。例：只要把網址中的帳號參數改成別人的帳號，系統沒有驗證就回傳別人的帳戶資料；或者權限檢查只寫在前端 JavaScript，攻擊者直接用命令列呼叫管理頁面就能繞過[5]。
  2. A02:2025 Security Misconfiguration（安全設定錯誤）：系統、應用程式或雲端服務的安全設定不當，例如沒有做安全強化、開著不需要的連接埠與功能、預設帳號密碼沒改、錯誤訊息洩漏堆疊追蹤[6]。例：正式環境留著應用程式伺服器附帶的範例程式，其中的管理主控台還用預設密碼，攻擊者登入後直接接管；或雲端儲存的分享權限預設對網際網路開放[6]。
  3. A03:2025 Software Supply Chain Failures（軟體供應鏈失效）：建置、散布或更新軟體的過程遭到破壞，常見原因是第三方程式碼、工具或相依套件的漏洞或惡意修改；沒有掌握所有元件（含間接相依）的版本、使用過時或不再支援的元件、CI/CD 流程比它部署的系統還不安全，都屬於這一類[7]。例：2025 年的 Shai-Hulud 是第一個成功自我散布的 npm 蠕蟲，透過被植入惡意版本的熱門套件竊取受害環境中的機敏資料，再用竊得的 npm 權杖發布更多惡意版本，被 npm 阻斷前已波及超過 500 個套件版本[7]。
  4. A04:2025 Cryptographic Failures（加密機制失效）：缺少加密、加密強度不足、金鑰外洩及相關錯誤[8]。例：密碼資料庫只用未加鹽或過於簡單的雜湊儲存，攻擊者透過檔案上傳漏洞取得資料庫後，就能用預先算好的彩虹表還原；即使加了鹽，使用快速雜湊函式的密碼仍可能被 GPU 破解[8]。
  5. A05:2025 Injection（注入）：不可信的使用者輸入被送進直譯器（瀏覽器、資料庫、命令列），其中一部分被當成指令執行，範圍從跨站腳本（XSS）到 SQL 注入[9]。例：程式把網址參數直接串進 SQL 查詢，攻擊者輸入 ' OR '1'='1 就能取回整張帳戶資料表[9]。大型語言模型的提示注入另由 OWASP 的 LLM Top 10 處理[9]。
  6. A06:2025 Insecure Design（不安全設計）：「缺少或無效的控制設計」，和實作缺陷是兩回事：設計不安全，程式寫得再完美也補不回來，因為需要的控制從一開始就不存在[10]。例：電影院的團體訂票要超過 15 人才需付訂金，攻擊者若分析這個流程，可能用幾個請求一次訂下所有影城共 600 個座位，造成大量營收損失[10]。
  7. A07:2025 Authentication Failures（身分驗證失效）：系統把無效或錯誤的使用者當成合法使用者，例如允許撞庫與暴力破解、允許弱密碼或已外洩的密碼、MFA 缺少或無效、登出或閒置後沒有讓工作階段失效[11]。例：攻擊者用外洩的帳密清單撞庫，或依人們改密碼的習慣把 Winter2025 換成 Winter2026 再試；應用程式沒有防範自動化攻擊，就成了幫攻擊者驗證帳密是否有效的工具[11]。
  8. A08:2025 Software or Data Integrity Failures（軟體或資料完整性失效）：沒有防範不可信的程式碼或資料被當成可信來使用，例如自動更新沒有驗證完整性、CI/CD 從不可信的來源拉取元件、不安全的反序列化[12]。例：公司把 support.myCompany.com 以 DNS 指向外部客服服務商，結果設定在 myCompany.com 網域上的所有 Cookie（包括登入用的 Cookie）都會送到服務商，任何能存取服務商基礎設施的人都能竊取使用者的工作階段[12]。
  9. A09:2025 Security Logging & Alerting Failures（安全日誌與告警失效）：登入、登入失敗、高價值交易等可稽核事件沒有記錄，日誌沒有被監控，或告警門檻與升級流程無效；沒有日誌與監控就偵測不到攻擊，沒有告警就很難及時回應[13]。例：一家兒童健康保險業者因為缺乏日誌與監控，直到外部通知才發現涉及超過 350 萬名兒童的敏感健康紀錄遭存取與竄改，入侵可能從 2013 年就開始，持續超過七年[13]。
  10. A10:2025 Mishandling of Exceptional Conditions（例外狀況處理不當）：程式沒有預防、偵測或妥善回應異常情況，導致當機、非預期行為甚至漏洞，包括錯誤處理不當、邏輯錯誤與「出錯時放行」（failing open）[14]。例：轉帳流程依序是扣款、入帳、記錄，攻擊者在中途切斷網路，系統若沒有讓整筆交易回滾（fail closed），帳戶可能被掏空，或因競爭條件重複匯款[14]。

和 2021 版相比，改了什麼

OWASP 說明 2025 版有兩個新類別、一項合併[4]：

  • A03 軟體供應鏈失效擴大自 2021 版的 A06:2021 Vulnerable and Outdated Components，範圍延伸到相依套件、建置系統與散布基礎設施；它在社群問卷中被壓倒性票選為首要關切，在資料中出現次數最少，但相關 CVE 的平均可利用性與衝擊分數最高[4]。
  • A10 例外狀況處理不當是全新類別[4]。
  • 伺服器端請求偽造（SSRF）併入 A01 存取控制失效[4]；它在 2021 版是獨立的 A10[15]。
  • 更名：A07 原名 Identification and Authentication Failures；A09 原名 Security Logging and Monitoring Failures，改名是為了強調告警，因為只有日誌、沒有告警，對發現資安事件幫助很小[4]；A08 從 Software and Data Integrity Failures 微調為 Software or Data Integrity Failures[12]。
  • 排名變動：安全設定錯誤從第 5 升到第 2；加密機制失效從第 2 降到第 4；注入從第 3 降到第 5；不安全設計從第 4 降到第 6[4]。

實務上最容易出錯的是編號：A03 在 2021 版是 Injection，在 2025 版是軟體供應鏈失效[15]。合約、檢測報告與修補工單引用時，一律寫完整編號（例如 A03:2025），不要只寫 A03。

委外開發：需求寫 ASVS，不要只寫 Top 10

「符合 OWASP Top 10」沒辦法驗收，因為它沒有定義什麼叫符合。可以驗收的寫法是引用 OWASP ASVS：目前的穩定版是 2025 年 5 月 30 日發布的 ASVS 5.0.0，專案的目標之一就是在合約中作為指定應用程式安全驗證需求的依據[16]。ASVS 規定每項需求都必須可以驗證，結果只能是「通過」或「不通過」[17]。

ASVS 分三級：L1 是最低要求與起點，約占全部需求的 20%；L2 是大多數應用程式應該努力達到的等級，要做到 L1 加 L2、約全部需求的 70%；L3 給要展現最高安全等級的應用程式，補上最後約 30%，多為縱深防禦或不容易實作的控制[17]。ASVS 不替你決定等級，要組織依風險與使用者的期待自行判斷；它舉的例子是，只蒐集少量敏感資料的新創可以先以 L1 為目標，但銀行的網路銀行很難說服客戶接受低於 L3[17]。ASVS 也寫明它適合用在軟體與客製開發服務的採購：買方要求軟體依 ASVS 第 X 級開發，並請賣方證明軟體符合[17]。因為需求編號可能隨版本改變，引用時要帶版本號，例如 v5.0.0-1.2.5 代表 5.0.0 版「編碼與淨化」章「注入防護」節的第 5 項[16]。

RFP 與合約可以寫進去的事

  • 指定標準與等級：例如「依 OWASP ASVS 5.0.0 L2 開發，並提出符合性證明」，個別關鍵需求以 v5.0.0 格式列出。
  • 交付安全決策文件：ASVS 有一類「文件需求」，要求把檔案上傳允許的類型、權限設計、輸入驗證規則等決策寫成文件，之後再比對實作是否一致[17]。把這些文件列為交付項目，驗收才有依據。
  • 開發工具與結果：OWASP 建議提供開發人員靜態分析、軟體組成分析（SCA）、機密資訊與基礎設施即程式碼（IaC）掃描工具，並教會他們使用[1]。可以要求廠商每個版本交付這些掃描結果與處理紀錄。
  • 第三方元件：A03 的風險來自你看不到的相依套件，要求廠商交付元件清單並承諾修補時限；SBOM 與廠商合約的做法見供應鏈攻擊。
  • 合約範本：OWASP 列出的參考範本之一是安全軟體合約附件（Secure Software Contract Annex），但它依美國契約法撰寫，使用前要請合格的法律顧問審閱[1]。

開發人員的實作指引看 OWASP Cheat Sheet Series：ASVS 只講要達成什麼，「這項需求在我的技術環境要怎麼實作」由 Cheat Sheet Series 回答，「要怎麼測」則由 Web Security Testing Guide（WSTG）回答[17]。OWASP 也建議設計階段參考 Cheat Sheets 與 Proactive Controls，從一開始就把安全設計進去，比事後補強划算得多[1]。另外要小心「通過 ASVS 認證」的說法：OWASP 不認證任何廠商、驗證者或軟體，任何宣稱 ASVS 合規的認證或標章都沒有經過 OWASP 正式背書[17]。

檢測報告上的「已涵蓋 OWASP Top 10」代表什麼

OWASP 自己的建議表把 Top 10 在滲透測試與工具支援上的角色標為「最低限度」，ASVS 才是完整的依據[1]。所以報告寫「已涵蓋 OWASP Top 10」，比較精確的理解是「測試人員針對這十類中測得到的部分做了檢查」，而不是「這十類風險都不存在」：

  • A06 不安全設計：多數測試方式測不到[1]，業務邏輯漏洞要靠威脅建模與設計審查。
  • A09 日誌與告警：滲透測試人員通常只能確認自己在測試環境中有沒有觸發應變，而測試環境很少像正式環境那樣被監控[1]。
  • A03 軟體供應鏈：在資料中出現次數最少，OWASP 認為原因是測試上的困難[4]；從外部做黑箱測試，通常看不到建置流程與相依套件。
  • 工具的極限：ASVS 提醒，「可以自動化測試」不等於「跑一套現成工具」[17]。

驗收時可以追問：

  • 哪一版、怎麼測：2021 還是 2025？每一類用什麼方法測（自動掃描、人工測試、原始碼檢視）？哪幾類不在範圍內？
  • 有沒有帳號與原始碼：ASVS 指出，驗證 L2、L3 需求除了用有效帳號做滲透測試，往往還需要調閱文件、原始碼、組態，並訪談開發人員；只跑自動化工具不足以作為驗證[17]。L1 也不一定能用沒有內部資訊的黑箱測試完成[17]。
  • 報告列出什麼：傳統滲透測試報告只列出失敗項目；ASVS 驗證報告則應包含範圍、所有檢查過的需求摘要、例外項目與修補建議，不適用的需求也要註明[17]。

弱點掃描與滲透測試的差別、交戰規則與報告驗收細節，見弱點掃描、滲透測試、紅隊演練；元件漏洞的 CVE 與分數怎麼讀，見看懂漏洞編號與分數。內部沒有人力判讀結果、排出修補順序時，可以參考弱點掃描與評估服務。

相關清單：API 與 LLM

  • API Security Top 10：目前的版本是 2023 版，第一名是 API1:2023 Broken Object Level Authorization（物件層級授權失效），也列了 API9:2023 Improper Inventory Management（API 清冊管理不當）等 API 特有的風險[18]。App 後端或對外提供 API 的系統，需求與測試範圍應同時涵蓋這份清單。
  • Top 10 for LLM Applications：目前的版本是 2024 年 11 月發布的 2025 版，第一名是 LLM01:2025 Prompt Injection（提示注入）[19]。系統有聊天機器人或接上大型語言模型的功能時，需求與測試都要納入。

台灣法規：資通系統防護基準怎麼要求

《資通安全責任等級分級辦法》第11條規定，公務機關與特定非公務機關自行或委外開發的資通系統，應依附表九完成資通系統分級，並依附表十「資通系統防護基準」執行控制措施；特定非公務機關的中央目的事業主管機關，也可以就特定類型的資通系統另訂防護基準，報主管機關核定[20]。現行條文於 2026 年 1 月 7 日修正，修正條文自發布日施行[20]。這是公務機關與特定非公務機關的法定義務，一般民間企業不受拘束；適用對象見資通安全管理法重點整理。

附表十依防護需求等級分為高、中、普三欄，「系統與服務獲得」構面對系統發展生命週期各階段的要求如下[21]：

  • 需求階段（三級相同）：確認系統的安全需求，包含機密性、可用性與完整性。
  • 設計階段：高、中級要依系統功能與要求識別可能的威脅，進行風險分析及評估，並把結果回饋到需求；普級無要求。
  • 開發階段：中、普級要針對安全需求實作必要控制措施、注意避免軟體常見漏洞，發生錯誤時使用者頁面只顯示簡短的錯誤訊息及代碼；高級另外要執行「源碼掃描」安全檢測，並具備發生嚴重錯誤時的通知機制。
  • 測試階段：中、普級要執行「弱點掃描」安全檢測；高級另外要執行「滲透測試」。
  • 部署與維運階段：普級要針對資安威脅更新修補、關閉不必要的服務及埠口、不使用預設密碼、備份系統源碼；高、中級另外要做版本控制與變更管理。
  • 委外階段（三級相同）：系統開發委外時，應把各階段依等級的安全需求納入委外契約。
  • 獲得程序：普級要識別系統使用的第三方軟體、服務、函式庫或其他元件；高、中級另外要區隔開發、測試與正式作業環境。

附表十沒有點名 OWASP，但可以這樣對照：開發階段的「避免軟體常見漏洞」，就是 Top 10 與 ASVS 派上用場的地方；錯誤頁面只顯示簡短訊息，對應 A02 與 A10；識別第三方元件對應 A03；不使用預設密碼對應 A02 與 A07；設計階段的威脅分析對應 A06。

數位發展部的稽核則直接點名了 OWASP Top 10。115 年度（2026 年）的「政府機關受託者資通安全聯合稽核計畫」由資安署統籌、適用於行政院所屬機關，依廠商維運機關核心資通系統的數量與服務的機關數量遴選受稽核廠商[22]。它的「系統安全開發」檢視項目包括：開發程序是否依安全系統發展生命週期（SSDLC）納入資安要求；開發階段是否實作必要控制措施並避免常見漏洞（如 OWASP Top 10 等），防護需求等級高者是否執行源碼掃描；測試階段是否執行弱點掃描，等級高者是否執行滲透測試；開發、測試與正式環境是否區隔[22]。另一項則檢視受託業務包括客製化資通系統開發時，廠商是否提供安全性檢測證明[22]。承接政府機關系統開發的廠商，可能透過契約與稽核直接面對這些要求；其他企業也可以拿它當委外驗收的參考基準。

行動清單

  • 把採購規格與合約範本中的「符合 OWASP Top 10」改寫成「依 OWASP ASVS 5.0.0 第 X 級開發並提出證明」，引用個別需求時帶版本號。
  • 依系統敏感度決定 ASVS 等級：多數對外系統以 L2 為目標，涉及金流或大量個資的系統評估 L3。
  • 要求廠商交付安全決策文件、第三方元件清單，以及每個版本的靜態分析與軟體組成分析結果。
  • 檢測合約寫明 Top 10 版本、每一類的測試方法、是否提供測試帳號與原始碼，以及不在範圍內的類別；報告要列出所有檢查過與不適用的項目。
  • 所有文件引用 Top 10 時寫完整編號（例如 A03:2025），避免和 2021 版混淆。
  • 以 API 為主的系統加看 API Security Top 10，有 LLM 功能的系統加看 LLM Top 10。
  • 適用資安法的機關：確認每個自行或委外開發的資通系統已完成分級，委外契約已依等級載明各階段安全需求，以及高級系統的源碼掃描與滲透測試。
  • 追蹤本站的漏洞類通報，把正在被利用的元件漏洞列為下一次檢測的重點。