本篇將進一步聚焦OWASP Top 10的A01至A05，涵蓋「注入」、「加密機制失效」、「軟體供應鏈失效」、「安全設定錯誤」與「存取控制失效」等常見風險。這些問題可能發生在應用程式架構、權限管理、資料處理與系統設定等不同層面，一旦遭到攻擊，可能導致未授權存取、敏感資料外洩，甚至進一步影響整體系統安全。
以下將針對各項風險的漏洞成因與實際攻擊情境進行解析，並進一步說明其可能造成的安全影響，以及開發與維運階段可採取的防護策略，協助企業更全面地掌握應用程式安全風險，降低系統在開發與運行過程中遭受攻擊的可能性。

A05：2025 Injection（注入）

由2021年版的A03下降至2025年版的A05。雖然排名下降，但這並不代表Injection的風險已降低。由於XSS的發生頻率較高，但整體風險程度相對較低；SQL Injection則可能發生頻率較低，但一旦遭到利用，往往會造成嚴重影響，因此XSS的大量案例可能拉低Injection整體的平均風險評估。OWASP也指出，Injection在測試中仍是受到高度關注的項目，且此類別擁有最多的CVE，因此仍是應用程式安全中不可忽視的風險。

描述說明 

Injection是一種應用程式漏洞，攻擊者可透過輸入介面加入惡意指令或內容，欺騙系統將原本的使用者輸入當成指令執行，進而改變系統原有的執行邏輯。

攻擊者可能利用這些漏洞進行以下行為：

• 繞過身分驗證或存取控制
• 竊取或取得未經授權的敏感資訊
• 修改或刪除系統資料
• 執行未經授權的系統指令

常見的Injection類型包括SQL、NoSQL、OS、XSS等。隨著生成式AI應用快速發展，Injection的風險也延伸至大型語言模型（LLM）。例如OWASP Top 10 for LLM Applications中的LLM01:2025 Prompt Injection，攻擊者可透過Prompt Injection輸入惡意提示，誘導模型忽略原有指示或安全限制，以達成攻擊目的。

如何預防

核心原則在於是「將指令與查詢分開」，避免系統將使用者輸入的內容直接當成可執行的指令或查詢。

• 優先使用安全API（Safe API），避免直接使用Interpreter；或透過參數化介面，將使用者輸入視為資料，而非指令內容
• 避免透過字串串接的方式，直接將使用者輸入加入SQL或其他動態指令中
• 若無法將資料與指令分離，可透過正向輸入驗證（Positive Server-side Input Validation）或適當的跳脫字元機制降低風險，但此類方式並非完整防護，也可能因實作複雜而產生錯誤
• 透過SAST、DAST、IAST等安全測試工具，及早發現並修補潛在的Injection漏洞

例如，當攻擊者輸入「1 OR 1=1」時，若系統直接將使用者輸入串接至SQL查詢中，可能改變原有的查詢邏輯；若透過Safe API或參數化介面處理，則會將使用者輸入視為資料，而不會被解析為SQL指令的一部分。

Injection的漏洞排名雖然有所下降，但並不代表此類風險已不再重要。尤其不同類型的Injection在發生頻率與影響程度上有所差異，整體排名並不能完全反映其實際威脅。因此，企業仍應持續關注Injection風險，並透過安全的開發方式與完善的安全測試機制，降低漏洞遭到利用的可能性。

A04:2025－Cryptographic Failures（加密機制失效）

由2021年版的A02下降至2025年版的A04。此類風險主要與敏感資料保護不當有關，例如使用弱加密或過時的雜湊演算法、密碼強度不足、敏感資訊未經適當加密，以及加密機制未正確實作等，都可能導致敏感資料遭到洩漏或被未經授權的攻擊者取得。

描述說明

主要發生於系統未能妥善保護敏感資訊，或加密機制存在設計與實作上的缺陷，實務上可從以下幾個面向進行檢視：

• 是否使用過舊、預設或強度不足的密碼
• 是否存在密碼重複使用的情況
• 是否使用MD5、SHA-1等已不建議使用的雜湊演算法
• 敏感資料是否有經過適當的加密保護
• 資料傳輸過程是否使用安全的加密通訊協定，例如HTTPS，而非未加密的HTTP

當系統未妥善保護密碼或敏感資料時，攻擊者可能透過暴力破解、彩虹表等方式進行攻擊，進一步取得原始密碼或敏感資訊，造成資料外洩與其他資安風險。

如何預防

關鍵在於「妥善保護敏感資訊，並採用適當且安全的加密機制」。

• 針對涉及密碼與敏感資訊的應用程式，應識別相關資料是否屬於敏感資訊，並依循相關法規與資安要求進行保護
• 盡可能使用經過驗證且值得信賴的加密演算法與實作方式
• 密碼儲存應採用Hash + Salt等適當的雜湊機制，避免以明文方式保存
• 金鑰與密碼應使用高隨機性的方式產生，並妥善管理
• 避免使用未加密的通訊協定，例如FTP、SMTP，並優先採用具備加密機制的安全通訊方式
• 避免儲存不必要的敏感資訊，並依循PCI DSS等相關規範進行資料保護
• 對於高敏感資訊，可考慮將相關金鑰或資料存放於硬體安全模組（HSM）或雲端HSM中

在系統、應用程式與專案開發過程中，只要涉及密碼、加密與驗證機制，都可能因加密強度不足或實作不當而產生資安風險。因此，除了選擇適當的加密演算法，也應妥善管理密碼與金鑰，避免因敏感資訊遭洩漏而造成難以挽回的損失。隨著後量子運算技術持續發展，企業亦可開始關注後量子密碼學（Post-Quantum Cryptography, PQC）等新興技術，提前思考未來加密機制的演進與因應策略。

A03:2025－Software Supply Chain Failures（軟體供應鏈失效）

A03的風險排名持續上升，從2013年版的A09至2021年版上升至A06，到2025年版更進一步上升至A03。雖然目前此風險列在A03，但在OWASP的分析中，該風險的平均發生率為所有風險類別中最高，且在主流社群調查中，有50%的受訪者認為此風險應排名第一。值得注意的是，供應鏈問題往往涉及多個相互依賴的元件，相對不容易被識別與追蹤，故此類風險目前可對應的CVE與CWE數量相對較少。

描述說明

此漏洞是指因第三方套件、工具或軟體所引發的安全問題。隨著軟體開發日益依賴外部元件，若缺乏完整的追蹤與管理機制，可能無法及時掌握所使用的元件及其相依套件所存在的風險。

• 未追蹤或定期檢視所使用的第三方套件，以及套件所依賴的其他元件
• 使用過時或已停止支援的套件、Server、API或Package，卻未進行後續修補或更新
• 當供應鏈中的元件或開發環境發生變更時，未能持續追蹤與確認其安全性
• IDE、Sandbox、Images、CI/CD等開發工具與環境存在安全風險，卻未被納入供應鏈管理範圍

如何預防

面對日益複雜的軟體供應鏈，關鍵在於「掌握使用哪些元件，並持續追蹤其安全狀態」。

• 建立軟體物料清單（SBOM），完整掌握與追蹤所使用的第三方套件及元件
• 移除不必要或未使用的套件，降低潛在的攻擊面
• 持續監控NVD、CVE等漏洞資訊，當發現新的安全風險時，及時評估並安排修復時程
• 僅從安全且可信賴的來源下載與使用第三方套件
• 定期更新CI/CD、IDE等開發工具與相關環境，降低因過時版本所產生的安全風險

隨著軟體專案日益複雜，第三方套件與元件的使用比例也持續提高。然而，這些外部元件可能存在漏洞，甚至遭到植入惡意程式，因此企業需要定期追蹤與管理所有第三方套件及其相依關係。透過完善的軟體供應鏈管理，不僅能降低使用高風險元件的可能性，也能在第三方元件遭受攻擊或發生零時差（0-day）漏洞時，及早掌握影響範圍並採取應變措施，降低對自身專案與系統造成的衝擊。

A02:2025－Security Misconfiguration（安全設定錯誤）

從2021年版的A05上升至2025年版的A02。根據OWASP的測試結果，100%的受測應用程式中都至少存在一項Security Misconfiguration。隨著軟體架構與雲端服務提供更多元且彈性的設定選項，系統的安全設定也更加複雜，因此OWASP認為此類風險排名大幅上升並不令人意外。

描述說明

安全設定錯誤是指系統、應用程式或雲端服務因安全設定錯誤或缺乏適當限制所造成的風險。當應用程式架構或雲端環境中的任一部分未妥善設定安全機制，都可能增加系統遭受攻擊的風險。

• 啟用或安裝不必要的功能，例如不必要的Port、服務、頁面、帳號、測試框架或權限
• 使用預設帳號與密碼
• 系統升級後造成原有安全設定或功能失效
• 過度重視系統相容性，導致安全設定被降低
• 未設定適當的安全值或安全限制

當系統存在錯誤或不安全的設定時，攻擊者可能利用這些弱點取得未經授權的存取權限，進一步竊取敏感資訊或造成其他資安事件。

如何預防

建議企業建立一致且可重複的安全設定流程，並持續驗證設定的安全性。

• 在使用不同的認證資訊（如帳號密碼、Token等）的前提下，建立可重複的資安設置流程，可方便且快速地在不同環境進行安全部署，同時降低人為設定錯誤
• 減少不必要的功能、服務與權限，降低潛在的攻擊面
• 進行系統修復時建立Patch，追蹤相關資安事件與修補狀態
• 採用分段（Segmentation）、容器化（Containerization）或雲端安全群組（ACLs）等方式，建立適當的安全區隔
• 透過自動化流程驗證系統與環境設定，確保安全配置符合預期

安全設定錯誤可能發生在系統、應用程式或雲端服務的各個層面，若因設定錯誤或使用預設值而缺乏適當的安全限制，可能讓攻擊者取得未經授權的存取權限，進一步竊取敏感資訊。因此，除了建立一致且可重複的安全設定流程，也應持續檢視與驗證系統配置，降低因設定錯誤所造成的資安風險。

A01:2025－Broken Access Control（存取控制失效）

在2021年版與2025年版皆排名第一，持續被列為應用程式最危險的安全風險之一。根據OWASP的測試結果，100%的受測應用程式中都至少存在一項Broken Access Control。在2025年版中，A10:2021的Server-Side Request Forgery（SSRF）相關風險也納入新版的Broken Access Control範疇，進一步擴大此類風險所涵蓋的情境。

描述說明

主要發生於應用程式未能正確限制使用者可以執行的操作，導致攻擊者取得原本不應擁有的權限，執行未經授權的動作。

• 違反最小權限原則（Principle of Least Privilege），使低權限使用者甚至未登入的使用者，能夠存取或修改高權限資訊
• 攻擊者透過修改URL、內部應用程式參數或API請求，取得未經授權的資源
• 透過修改自身的唯一識別碼（ID），存取其他使用者的資料
• API存取控制設定不足，例如JWT Token失效後仍可使用、CORS設定不當，或POST、PUT、DELETE等API缺乏適當的權限控管

當存取控制機制存在漏洞時，攻擊者可能取得超出自身權限範圍的操作能力，進一步竊取敏感資訊，甚至修改或刪除未經授權的資料。

如何預防

關鍵在於「將存取控制機制建立於可信任的伺服器端，並採取預設拒絕的安全原則」。

• 除了公開資源外，預設拒絕其他所有請求，並針對需要存取的資源明確定義權限
• 統一使用一致的Access Control機制，避免不同功能各自實作權限檢查，造成控管不一致
• 僅允許特定使用者擁有資料所有權（Record Ownership），並依據權限限制資料的新增、讀取、修改或刪除
• 將重要的業務限制交由系統的Domain Models執行，避免僅依賴前端進行權限控管
• 關閉Web伺服器的目錄列表功能，並確保.git等可能包含敏感資訊的檔案無法被外部查詢
• 建立Access Control Log，並在發生異常存取行為時向管理員發出警告
• 設定API速率限制，降低自動化工具大量請求可能造成的影響
• 使用者登出後，應撤銷或失效相關的存取權限與Token

存取控制失效的問題在於，應用程式未能正確執行權限檢查，導致系統給予攻擊者原本不應擁有的權限。這類漏洞可能讓攻擊者執行需要特定權限才能完成的操作，例如竊取敏感資訊，甚至修改或刪除資料。因此，企業應在伺服器端建立一致且完善的存取控制機制，並持續檢視API與應用程式的權限設定，降低未經授權存取所造成的資安風險。

在本篇的探討中，我們深入解析了OWASP Top 10 2025中A01至A05的風險類型，從存取控制、加密機制、注入、軟體供應鏈到安全設定等不同面向，了解應用程式可能面臨的各項安全風險。綜合上下篇的內容可以發現，現代應用程式安全所面臨的威脅日益複雜，除了程式碼本身的安全性，也涉及架構設計、第三方元件、系統配置與權限管理等不同層面。

面對不斷演進的資安威脅，企業除了掌握OWASP Top 10所揭示的常見風險，更應將安全思維融入軟體開發生命週期（SSDLC），從設計、開發、測試到部署與維運，持續檢視並強化應用程式的安全性，逐步建立更完整的應用程式安全防護機制。

如果您希望進一步了解OWASP Top 10 2025的風險評估，或想針對企業現有的應用程式安全開發流程進行檢視，歡迎於官網留下資訊，將會有專人與您聯繫➤ https://www.gss.com.tw/sca#cta