OWASP 應用程式安全驗證標準報告

應用程序安全驗證標準（ASVS）是一份應用程序安全要求或測試的清單，可以被架構師、開發人員、測試人員、安全專業人員、工具供應商和消費者用來定義、建立、測試和驗證安全的應用程序。

應用程序安全驗證標準（ASVS）的目標

  • 為了幫助組織開發並維護安全的應用程式。
  • 為了讓安全服務供應商、安全工具供應商和消費者能夠對齊他們的需求和提供。

AppScan 和 ASVS 標準

這份AppScan合規報告使用了ASVS第三級。ASVS 第三級是針對最關鍵的應用程式，即執行高價值交易、包含敏感醫療數據，或需要最高信任級別的任何應用程式。

應用程序安全驗證標準是由OWASP開發和維護的。此標準是根據創用CC 姓名標示-相同方式分享 3.0 授權條款釋出。欲了解更多資訊，請參閱OWASP應用程式安全驗證標準V4.0.3

有關保護網路應用程式的更多資訊，請參閱HCL AppScan：進階應用程式安全測試

規定的部分

ID 名稱
1.2.1 驗證所有應用組件、服務和服務器的獨特或特殊的低權限操作系統帳戶的使用。
1.2.2 驗證應用程式組件之間的通訊，包括API、中介軟體和數據層，是否已經過身份驗證。組件應具備最少必要的權限。
1.2.3 驗證該應用程式是否使用單一經過審核的身份驗證機制，該機制已知為安全，可以擴展以包含強大的身份驗證，並具有足夠的日誌記錄和監控以檢測帳戶濫用或違規。
1.2.4 驗證所有身份驗證途徑和身份管理API實施一致的身份驗證安全控制強度，以確保根據應用程序的風險，沒有較弱的替代方案。
1.4.4 驗證應用程式使用單一且經過嚴格審核的訪問控制機制來訪問受保護的數據和資源。所有請求都必須通過這個單一機制，以避免複製和粘貼或不安全的替代路徑。
1.4.5 驗證是否使用基於屬性或特性的訪問控制，其中代碼檢查用戶對特性/數據項的授權，而不僅僅是他們的角色。權限應該仍然使用角色來分配。
1.5.2 驗證在與不受信任的客戶通信時不使用序列化。如果這不可能，請確保實施足夠的完整性控制（如果發送敏感數據，可能還需要加密）以防止包括對象注入在內的反序列化攻擊。
1.5.3 驗證信任服務層是否實施了輸入驗證。
1.5.4 驗證輸出編碼是否在或接近其預定的解釋器進行。
1.6.2 驗證加密服務的消費者是否透過使用金鑰保險庫或基於API的替代方案來保護金鑰材料和其他秘密。
1.6.3 確認所有的鑰匙和密碼都可以替換，並且是重新加密敏感數據的明確流程的一部分。
1.6.4 驗證該架構是否將客戶端秘密--如對稱鑰匙、密碼或API令牌--視為不安全，並且從不使用它們來保護或訪問敏感數據。
1.9.1 驗證應用程式是否加密元件之間的通訊，特別是當這些元件位於不同的容器、系統、站點或雲服務提供商中時。
1.9.2 驗證應用程式組件確認通訊鏈接中每一方的真實性，以防止中間人攻擊。例如，應用程式組件應驗證 TLS 憑證和鏈。
1.11.2 驗證所有高價值業務邏輯流程，包括身份驗證、會話管理和訪問控制，都不共享未同步的狀態。
1.11.3 驗證所有高價值業務邏輯流程，包括身份驗證、會話管理和訪問控制，都是線程安全的，並能抵抗檢查時間和使用時間的競爭條件。
1.14.6 驗證應用程式不使用不受支援、不安全或已被棄用的客戶端技術，如NSAPI插件、Flash、Shockwave、ActiveX、Silverlight、NACL或客戶端Java小程式。
2.1.1 驗證使用者設定的密碼至少有12個字符長度（在多個空格組合後）。
2.1.2 驗證至少64個字符的密碼是否被允許，並確認超過128個字符的密碼是否被拒絕。
2.2.1 驗證反自動化控制是否有效地緩解了被破壞的憑證測試、暴力破解和帳戶鎖定攻擊。這些控制包括阻擋最常被破解的密碼，軟鎖定，速率限制，CAPTCHA，嘗試間隔不斷增加，IP地址限制，或基於風險的限制，如位置，設備上的首次登錄，最近嘗試解鎖帳戶等等。驗證一個單一帳戶每小時失敗嘗試的次數不超過100次。
2.2.2 驗證弱身份驗證器（如簡訊和電子郵件）的使用是否僅限於二次驗證和交易批准，而不是作為更安全的身份驗證方法的替代品。確認在提供弱方法之前已提供更強大的方法，使用者已瞭解風險，或已有適當的措施來限制帳戶被侵害的風險。
2.2.4 驗證對釣魚的偽冒抵抗力，例如使用多因素認證，具有意圖的加密設備（例如連接的按鈕用於認證的鑰匙），或在更高的AAL級別，客戶端證書。
2.2.5 驗證在憑證服務提供商（CSP）與驗證身份驗證的應用程式分離的地方，兩個端點之間是否已經建立了相互認證的TLS。
2.2.6 通過強制使用一次性密碼（OTP）設備、加密驗證器或查詢代碼，驗證重播阻擋的效力。
2.3.1 驗證系統生成的初始密碼或激活碼應該安全地隨機生成，應該至少有6個字符長，並且可以包含字母和數字，並在短時間內過期。這些初始秘密絕不能被允許成為長期密碼。
2.4.1 驗證密碼是否以能抵抗離線攻擊的形式儲存。密碼必須使用經過批准的單向金鑰衍生或密碼雜湊函數進行鹽化和雜湊。密鑰導出和密碼雜湊函數在生成密碼雜湊時，將密碼、鹽和成本因子作為輸入。
2.4.2 驗證鹽的長度至少為32位元，並且應任意選擇以最小化存儲的雜湊值之間的鹽值碰撞。對於每個憑證，都應儲存唯一的鹽值和產生的雜湊。
2.4.3 請確認如果使用PBKDF2，迭代次數應盡可能大，以驗證伺服器的性能允許，通常至少100,000次迭代。
2.4.4 驗證如果使用bcrypt，工作因子應該盡可能大，以驗證伺服器的性能允許，最小值應為10。
2.4.5 驗證是否已執行密鑰衍生函數的額外迭代，使用的鹽值是秘密的，且只有驗證者知道。使用經過認證的隨機位元生成器[SP 800-90Ar1]生成鹽值，並提供至少達到最新版本SP 800-131A中指定的最低安全強度。秘密鹽值必須與雜湊密碼分開存儲（例如，在專門的設備中，如硬體安全模組）。
2.5.1 驗證系統生成的初始激活或恢復秘密是否未以明文形式發送給用戶。
2.5.2 驗證密碼提示或基於知識的驗證（所謂的秘密問題）是否不存在。
2.5.3 驗證密碼憑證恢復不會以任何方式揭示當前的密碼。
2.5.4 驗證共享或預設帳戶是否存在（例如：root、admin或sa）。
2.6.1 驗證查詢秘密只能使用一次。
2.6.2 驗證查詢秘密是否具有足夠的隨機性（112位的熵），或者如果熵少於112位，則使用唯一且隨機的32位鹽進行鹽化，並使用已批准的單向雜湊進行雜湊。
2.6.3 驗證查詢秘密是否能抵禦離線攻擊，例如可預測的值。
2.10.1 驗證內部服務的秘密不依賴於不變的憑證，如密碼、API金鑰或具有特權訪問權限的共享帳戶。
2.10.2 驗證如果服務需要密碼進行身份驗證，使用的服務帳戶不是預設的憑證。（例如，root/root或admin/admin在某些服務的安裝過程中是預設的）。
2.10.3 驗證密碼是否已經有足夠的保護來防止離線恢復攻擊，包括本地系統訪問。
2.10.4 驗證密碼、與資料庫和第三方系統的整合、種子和內部秘密，以及API密鑰都被安全地管理，並且不包含在源代碼中或存儲在源代碼庫中。這種儲存應該要能抵抗離線攻擊。建議使用安全的軟體金鑰儲存庫（L1）、硬體TPM或HSM（L3）來儲存密碼。
3.1.1 驗證應用程式絕不會在URL參數中顯示會話令牌。
3.2.1 驗證應用程式在用戶認證時生成新的會話令牌。
3.2.2 驗證會話令牌至少具有64位的熵。
3.2.3 驗證應用程式只使用安全的方法（如適當地保護的cookies（參見第3.4節）或HTML 5會話存儲）在瀏覽器中存儲會話令牌。
3.2.4 驗證會話令牌是否使用經過批准的加密算法生成。
3.3.1 驗證登出和過期是否使會話令牌無效，以確保返回按鈕或下游依賴方不會恢復已驗證的會話，包括跨依賴方。
3.3.2 如果驗證器允許用戶保持登錄狀態，請確認在積極使用或閒置一段時間後，都會定期重新進行驗證。
3.3.3 驗證應用程式在成功更改密碼（包括通過密碼重置/恢復更改）後，是否提供終止所有其他活動會話的選項，並確保這在整個應用程式、聯合登錄（如果存在）以及任何依賴方都有效。
3.3.4 驗證使用者能夠查看並（重新輸入登入憑證後）登出任何或所有目前活躍的會話和設備。
3.4.1 驗證基於cookie的會話令牌是否設置了'Secure'屬性。
3.4.2 驗證基於cookie的會話令牌是否設置了'HttpOnly'屬性
3.4.3 驗證基於cookie的會話令牌是否利用'SameSite'屬性來限制對跨站點請求偽造攻擊的暴露。
3.4.4 驗證基於cookie的會話令牌是否使用'__Host-'前綴，以便cookie只被發送到最初設置cookie的主機。
3.4.5 請確認如果應用程式是在與其他設置或使用可能會洩露會話cookies的應用程式共享的網域名稱下發布，則使用最精確的路徑設置基於cookie的會話令牌中的路徑屬性。
3.5.1 驗證應用程式允許用戶撤銷與鏈接應用程式形成信任關係的OAuth令牌。
3.5.2 驗證應用程式使用的是會話令牌，而不是靜態API秘密和鑰匙，除非是與傳統實施有關。
3.5.3 驗證無狀態會話令牌是否使用數位簽名、加密和其他防護措施來防止篡改、封裝、重播、空密碼和密鑰替換攻擊。
3.7.1 驗證應用程式是否確保完整、有效的登入會話，或在允許任何敏感交易或帳戶修改之前，需要重新驗證或二次驗證。
4.1.1 驗證應用程式是否在受信任的服務層上強制執行訪問控制規則，尤其是如果存在客戶端訪問控制並且可能被繞過。
4.1.2 驗證所有由訪問控制使用的用戶和數據屬性以及政策信息，除非特別授權，否則不能被終端用戶操縱。
4.1.3 驗證最小權限原則是否存在 - 使用者只應能夠訪問他們具有特定授權的功能、數據文件、URL、控制器、服務和其他資源。這意味著對抵禦偽冒和權限提升的保護。
4.1.5 驗證訪問控制在出現異常時能安全地失敗。
4.2.1 驗證敏感數據和API是否受到針對創建、讀取、更新和刪除記錄的不安全直接對象引用（IDOR）攻擊的保護，例如創建或更新他人的記錄，查看所有人的記錄，或刪除所有記錄。
4.2.2 驗證應用程式或框架是否強制執行強大的反CSRF機制以保護已認證的功能，並且有效的反自動化或反CSRF保護未認證的功能。
4.3.2 驗證除非特意需要，否則目錄瀏覽功能應該是關閉的。此外，應用程式不應允許發現或披露檔案或目錄的元數據，例如 Thumbs.db、.DS_Store、.git 或 .svn 文件夾。
5.1.1 驗證該應用程式是否具有防禦 HTTP 參數污染攻擊的防禦機制，特別是如果應用程式框架對請求參數的來源（GET、POST、cookies、標頭或環境變數）沒有區分。
5.1.2 驗證框架是否能防止大規模參數分配攻擊，或者應用程序是否有對策來防止不安全的參數分配，例如將字段標記為私有或類似的操作。
5.1.3 驗證所有輸入（HTML表單字段、REST請求、URL參數、HTTP標頭、cookies、批次檔案、RSS feeds等）是否使用正面驗證（允許列表）進行驗證。
5.1.4 驗證結構化數據是否強類型，並根據定義的模式進行驗證，包括允許的字符、長度和模式（例如信用卡號碼、電子郵件地址、電話號碼，或驗證兩個相關字段是否合理，例如檢查郊區和郵政編碼是否匹配）。
5.1.5 驗證URL重定向和轉發只允許出現在允許列表上的目的地，或在重定向到可能不受信任的內容時顯示警告。
5.2.1 請確認所有來自所見即所得編輯器或類似的不受信任的HTML輸入，都已使用HTML清潔劑庫或框架功能進行適當的清理。
5.2.2 驗證非結構化數據已經被清理，以實施安全措施，例如允許的字符和長度。
5.2.3 驗證應用程式在傳遞到郵件系統之前是否已清理用戶輸入，以防止 SMTP 或 IMAP 注入。
5.2.4 驗證該應用程式是否避免使用eval()或其他動態代碼執行功能。在沒有其他選擇的情況下，必須在執行之前對包含的任何用戶輸入進行清理或沙箱處理。
5.2.6 驗證該應用程式是否能防禦SSRF攻擊，通過驗證或清理不受信任的數據或HTTP文件元數據，如文件名和URL輸入字段，並使用允許的協議、域名、路徑和端口列表。
5.2.7 驗證應用程式是否清理、禁用或沙箱化使用者提供的可縮放向量圖形（SVG）可編程內容，尤其是與來自內聯腳本和foreignObject的跨站腳本攻擊（XSS）相關的內容。
5.2.8 驗證應用程式是否清理、禁用或沙箱化用戶提供的可編程或表達式模板語言內容，如 Markdown、CSS 或 XSL 樣式表、BBCode 或類似內容。
5.3.1 驗證輸出編碼對於所需的解釋器和上下文是否相關。例如，根據上下文的需要，特別是來自不受信任的輸入（例如，帶有Unicode或撇號的名稱，如ねこ或O'Hara），專門使用編碼器來處理HTML值、HTML屬性、JavaScript、URL參數、HTTP頭部、SMTP等等。
5.3.2 驗證輸出編碼是否保留了用戶選擇的字符集和地區設置，以確保任何Unicode字符點都是有效的並且可以安全處理。
5.3.3 驗證上下文感知，最好是自動化的 - 或者最壞的情況，手動的 - 輸出轉義能夠保護反映，儲存和基於DOM的XSS。
5.3.4 驗證數據選擇或數據庫查詢（例如 SQL、HQL、ORM、NoSQL）是否使用參數化查詢、ORM、實體框架，或者以其他方式受到防止數據庫注入攻擊的保護。
5.3.5 驗證在沒有參數化或更安全的機制存在的地方，是否使用了特定於上下文的輸出編碼來防止注入攻擊，例如使用SQL轉義來防止SQL注入。
5.3.6 驗證該應用程式是否能防禦JSON注入攻擊、JSON eval攻擊，以及JavaScript表達式評估。
5.3.7 驗證該應用程式是否能防禦LDAP注入漏洞，或者已實施特定的安全控制以防止LDAP注入。
5.3.8 驗證該應用程式能防禦作業系統命令注入，並確保作業系統呼叫使用參數化的作業系統查詢或使用上下文命令行輸出編碼。
5.3.9 驗證該應用程式是否能防禦本地文件包含（LFI）或遠程文件包含（RFI）的攻擊。
5.3.10 驗證該應用程式是否能防禦 XPath 注入或 XML 注入攻擊。
5.4.1 驗證該應用程式是否使用記憶體安全的字串，更安全的記憶體複製和指標運算來檢測或防止堆疊、緩衝區或堆積溢出。
5.4.2 驗證格式字串不會接收可能具有敵意的輸入，並且是常數。
5.4.3 驗證符號、範圍和輸入驗證技術是否被用來防止整數溢出。
5.5.1 驗證序列化對象是否使用完整性檢查或加密，以防止敵對對象創建或數據篡改。
5.5.2 驗證應用程式是否正確地限制XML解析器僅使用可能的最嚴格配置，並確保禁用不安全的功能，如解析外部實體，以防止XML外部實體（XXE）攻擊。
5.5.3 驗證在自訂代碼和第三方庫（如 JSON、XML 和 YAML 解析器）中都避免或保護了對不受信任的數據進行反序列化。
5.5.4 驗證在瀏覽器或基於JavaScript的後端解析JSON時，使用JSON.parse來解析JSON文件。不要使用 eval() 來解析 JSON。
6.1.1 請驗證受規範的私人數據在休息時是否已加密儲存，例如個人身份信息（PII）、敏感個人信息，或被評估可能受到歐盟GDPR規定的數據。
6.1.2 驗證受監管的健康數據在靜止時是否已加密儲存，例如醫療記錄、醫療設備詳情或去匿名化的研究記錄。
6.1.3 驗證受監管的財務數據在靜止時是否已加密儲存，例如財務帳戶、違約或信用歷史、稅務記錄、薪資歷史、受益人，或去匿名化的市場或研究記錄。
6.2.1 驗證所有加密模組都能安全地失敗，並且錯誤以不會啟用填充Oracle攻擊的方式處理。
6.2.2. 驗證是否使用經過行業驗證或政府批准的加密算法、模式和庫，而非自定義編碼的加密方式。
6.2.3 驗證加密初始化向量、密碼配置和區塊模式是否根據最新的建議安全配置。
6.2.4 驗證隨機數字、加密或雜湊演算法、金鑰長度、輪數、密碼或模式，可以隨時重新配置、升級或交換，以防止密碼破解。
6.2.5 驗證已知的不安全區塊模式（例如 ECB 等）、填充模式（例如 PKCS#1 v1.5 等）、具有小區塊大小的密碼（例如 Triple-DES、Blowfish 等）和弱哈希算法（例如 MD5、SHA1 等）是否未被使用，除非為了向後兼容性而需要。
6.2.6 驗證一次性數字、初始化向量和其他單次使用的數字在給定的加密鑰匙中不能被使用超過一次。生成的方法必須適合正在使用的演算法。
6.2.7 驗證加密數據是否通過簽名、認證密碼模式或HMAC進行認證，以確保密文不被未經授權的方修改。
6.2.8 驗證所有的加密操作都是常數時間，並且在比較、計算或返回中沒有「短路」操作，以避免洩露信息。
6.3.1 驗證所有隨機數字、隨機檔案名稱、隨機GUID和隨機字串是否都是使用加密模組的認可的加密安全隨機數字生成器生成的，當這些隨機值的目的是要防止攻擊者猜測。
6.3.2 驗證隨機GUID是使用GUID v4算法以及加密安全的偽隨機數生成器（CSPRNG）創建的。使用其他偽隨機數生成器創建的GUID可能是可預測的。
6.3.3 驗證即使在應用程式負載過重的情況下，隨機數字仍能以適當的熵生成，或者應用程式在這種情況下能夠優雅地降級。
6.4.1 驗證是否使用了像是金鑰保險庫這樣的秘密管理解決方案來安全地創建、儲存、控制訪問權限並銷毀秘密。
6.4.2 驗證密鑰材料並未暴露給應用程式，而是使用像是保險庫這樣的隔離安全模組進行加密操作。
7.1.1 驗證該應用程式是否不記錄憑證或付款詳情。會話令牌只應以不可逆的雜湊形式存儲在日誌中。
7.1.2 驗證該應用程式是否未記錄在當地隱私法或相關安全政策下定義的其他敏感數據。
7.1.3 驗證應用程式是否記錄了與安全相關的事件，包括成功和失敗的身份驗證事件、訪問控制失敗、反序列化失敗和輸入驗證失敗。
7.1.4 驗證每個日誌事件都包含了進行詳細調查事件發生時間線所需的必要信息。
7.3.1 驗證所有日誌組件是否適當地編碼數據以防止日誌注入。
7.3.3 驗證安全日誌是否受到保護，防止未經授權的訪問和修改。
7.4.1 驗證當發生意外或安全敏感的錯誤時，是否會顯示一條通用的訊息，可能會有一個唯一的ID，支援人員可以使用該ID進行調查。
7.4.2 驗證異常處理（或功能等效）是否在整個代碼庫中使用，以應對預期和意外的錯誤條件。
7.4.3 驗證是否已定義一個「最後手段」的錯誤處理器，該處理器將捕獲所有未處理的異常。
8.1.1 驗證應用程式保護敏感數據，防止其在伺服器組件（如負載平衡器和應用程式緩存）中被緩存。
8.1.2 驗證伺服器上儲存的所有緩存或臨時敏感數據副本是否受到未經授權訪問的保護，或在經授權的用戶訪問敏感數據後被清除/失效。
8.1.3 驗證應用程式在請求中最小化參數的數量，例如隱藏欄位、Ajax變數、cookies和標頭值。
8.1.4 驗證應用程式能否偵測並警報異常的請求數量，例如來自特定IP、用戶，或者每小時或每天的總數，或者對於應用程式來說有意義的任何事物。
8.3.1 驗證敏感數據是否已通過HTTP訊息主體或標頭發送到伺服器，並確保任何HTTP動詞的查詢字串參數不包含敏感數據。
8.3.6 驗證記憶體中包含的敏感信息在不再需要時立即被覆蓋，以防止記憶體傾卸攻擊，使用零或隨機數據。
8.3.7 驗證需要加密的敏感或私人信息，是否使用經過批准的算法進行加密，以提供機密性和完整性。
9.1.1 驗證所有客戶端連接都使用TLS，並且不會退回到不安全或未加密的通訊。
9.1.3 驗證只有啟用最新推薦的TLS協議版本，例如TLS 1.2和TLS 1.3。最新版本的 TLS 協議應該是首選選項。
9.2.1 驗證與伺服器的連接是否使用可信任的 TLS 憑證。在使用內部生成或自簽名證書的地方，伺服器必須配置為僅信任特定的內部 CA 和特定的自簽名證書。所有其他的都應該被拒絕。
9.2.2 驗證所有進出連接，包括管理端口、監控、認證、API或網絡服務呼叫、數據庫、雲端、無服務器、主機、外部和合作夥伴連接，是否都使用了加密通信，如TLS。伺服器絕對不能退回使用不安全或未加密的協議。
9.2.3 驗證所有涉及敏感信息或功能的對外系統的加密連接都已經過身份驗證。
10.2.1 驗證應用程式源碼和第三方庫是否不包含未經授權的撥打家庭電話或數據收集功能。在此功能存在的地方，請在收集任何數據之前獲得用戶的許可。
10.2.2 確認該應用程式不會要求不必要或過度的權限，以訪問與隱私相關的功能或感應器，例如聯絡人、相機、麥克風或位置。
10.2.3. 驗證應用程式源代碼和第三方庫是否包含後門，例如硬編碼或額外的未記錄帳戶或密鑰，代碼混淆，未記錄的二進制大塊，rootkits，或反調試，不安全的調試功能，或者其他過時，不安全，或隱藏的功能，如果被發現，可能會被惡意使用。
10.2.4 驗證應用程式源代碼和第三方庫是否包含時間炸彈，通過搜索日期和時間相關函數來確認。
10.2.5 驗證應用程式源代碼和第三方庫是否包含惡意代碼，如薩拉米攻擊、邏輯閃避或邏輯炸彈。
10.2.6 驗證應用程式源代碼和第三方庫是否包含彩蛋或任何其他可能不需要的功能。
10.3.1 驗證如果應用程式具有客戶端或伺服器自動更新功能，應通過安全通道獲取更新並進行數位簽名。更新程式碼必須在安裝或執行更新前驗證更新的數位簽章。
10.3.2 驗證該應用程式是否採用了完整性保護，如程式碼簽名或子資源完整性。該應用程式絕對不可以從不受信任的來源，例如從不受信任的來源或互聯網加載包括、模塊、插件、代碼或庫，加載或執行代碼。
10.3.3 確認如果應用程式依賴於DNS條目或DNS子域（如過期的域名、過時的DNS指標或CNAMEs、公開源代碼庫的過期項目，或者瞬態雲API、無伺服器功能、或儲存桶（autogen-bucket-id.cloud.example.com）等），該應用程式是否有防止子域接管的保護。保護措施可以包括確保定期檢查應用程序使用的DNS名稱是否過期或更改。
11.1.1 驗證該應用程式只會按照順序處理同一使用者的業務邏輯流程，並且不會跳過任何步驟。
11.1.2 驗證該應用程式只會處理所有步驟都在真實人類時間內處理的業務邏輯流程，即交易不會提交得太快。
11.1.3 驗證應用程式對特定業務操作或交易設有適當的限制，並且能夠正確地按照每個用戶進行執行。
11.1.4 驗證該應用程式是否具有防自動化控制，以防止過度的呼叫，例如大量數據外流、業務邏輯請求、檔案上傳或拒絕服務攻擊。
11.1.5 驗證應用程式是否具有業務邏輯限制或驗證，以防止可能的業務風險或威脅，這些風險或威脅是使用威脅建模或類似方法識別的。
11.1.6 驗證應用程式是否不受「檢查時間到使用時間」（TOCTOU）問題或其他敏感操作的競爭條件影響。
12.1.1 驗證該應用程式不會接受可能填滿儲存空間或導致服務中斷的大型檔案。
12.1.3 驗證是否有實施檔案大小配額和每位使用者的最大檔案數量，以確保單一使用者無法因過多的檔案或過大的檔案而填滿儲存空間。
12.3.1 驗證用戶提交的檔案名稱元數據是否直接被系統或框架檔案系統使用，並且使用URL API來防止路徑遍歷。
12.3.2 驗證用戶提交的檔案名稱元數據是否已經過驗證或被忽略，以防止本地文件（LFI）的洩露、創建、更新或刪除。
12.3.3 驗證用戶提交的檔案名稱元數據是否已經過驗證或被忽略，以防止透過遠程文件包含（RFI）或伺服器端請求偽造（SSRF）攻擊來洩露或執行遠程文件。
12.3.4 驗證該應用程式是否通過驗證或忽略JSON、JSONP或URL參數中的用戶提交的檔案名稱來防止反射檔案下載（RFD），回應的Content-Type標頭應設置為text/plain，並且Content-Disposition標頭應具有固定的檔案名稱。
12.3.5 驗證未受信任的檔案元數據是否直接與系統API或庫一起使用，以防止操作系統命令注入。
12.3.6 驗證應用程式不包含並執行來自不受信任來源的功能，例如未經驗證的內容分發網絡、JavaScript庫、node npm庫或伺服器端DLLs。
12.4.1 驗證從不受信任的來源獲得的文件是否存儲在網頁根目錄之外，並且權限有限。
12.5.1 驗證網路層是否已配置為僅提供具有特定檔案擴展名的檔案，以防止無意的資訊和源代碼洩露。例如，備份文件（例如 .bak）、臨時工作文件（例如 .swp）、壓縮文件（.zip、.tar.gz 等）以及編輯器常用的其他擴展名應被阻止，除非需要。
12.5.2 驗證直接請求上傳的文件絕不會作為HTML / JavaScript內容執行。
12.6.1 驗證網頁或應用程式伺服器是否已配置允許列表，該列表包含伺服器可以發送請求或從中加載數據/文件的資源或系統。
13.1.1 驗證所有應用程式組件使用相同的編碼和解析器，以避免解析攻擊，這種攻擊利用了不同的URI或文件解析行為，可能被用於SSRF和RFI攻擊。
13.1.3 驗證API網址不會暴露敏感信息，例如API密鑰，會話令牌等。
13.1.4 驗證授權決策是在URI和資源級別進行的，由控制器或路由器的程式或聲明性安全性強制執行，並由基於模型的權限在資源級別強制執行。
13.1.5 驗證包含意外或缺失內容類型的請求是否被適當的標頭（HTTP響應狀態406不可接受或415不支援的媒體類型）拒絕。
13.2.1 驗證已啟用的 RESTful HTTP 方法是否對用戶或操作是一個有效的選擇，例如防止普通用戶在受保護的 API 或資源上使用 DELETE 或 PUT。
13.2.2 驗證在接受輸入之前，已經設置並驗證了JSON模式驗證。
13.2.3 驗證使用cookies的RESTful網路服務是否通過使用以下一種或多種方式來防止跨站點請求偽造：雙重提交cookie模式，CSRF隨機數，或原始請求頭檢查。
13.2.5 驗證REST服務是否明確檢查進來的Content-Type是否為預期的類型，例如application/xml或application/json。
13.2.6 驗證訊息標頭和有效負載是否可信且在傳輸過程中未被修改。要求強大的傳輸加密（僅限TLS）在許多情況下可能足夠，因為它同時提供了保密性和完整性保護。每條訊息的數位簽章可以為高安全性應用程序提供額外的保證，以增強傳輸保護，但也帶來了額外的複雜性和風險，需要與其帶來的好處進行權衡。
13.3.1 驗證XSD模式驗證是否已進行，以確保形成正確的XML文件，然後在對該數據進行任何處理之前驗證每個輸入字段。
13.3.2 驗證訊息負載是否使用WS-Security進行簽名，以確保客戶端與服務之間的可靠傳輸。
13.4.1 驗證查詢允許列表或深度限制和數量限制的組合是否被用來防止由於昂貴的嵌套查詢而導致的GraphQL或數據層表達式服務拒絕（DoS）。對於更進階的情境，應使用查詢成本分析。
14.1.3 驗證伺服器配置是否根據使用中的應用伺服器和框架的建議進行了加固。
14.2.2 驗證所有不需要的功能、文件、示例應用程序和配置是否已被移除。
14.2.3 驗證如果應用程序資源，如JavaScript庫、CSS或網頁字體，是由內容傳遞網絡（CDN）或外部提供商托管的，則使用子資源完整性（SRI）來驗證資源的完整性。
14.2.4 驗證第三方組件來自於預定義的、值得信賴的並且持續維護的存儲庫。
14.3.2 14.3.2 - 驗證在生產中是否已禁用網頁或應用程式伺服器和應用程式框架的調試模式，以消除調試功能、開發者控制台和無意的安全揭露。
14.3.3 驗證HTTP標頭或HTTP響應的任何部分是否未暴露系統組件的詳細版本信息。
14.4.1 驗證每個HTTP回應都包含一個Content-Type標頭。同時，如果內容類型為 text/*，/+xml 和 application/xml，請指定一個安全的字符集（例如，UTF-8，ISO-8859-1）。內容必須與提供的Content-Type標頭相符。
14.4.2 驗證所有API回應都包含一個Content-Disposition: attachment; filename='api.json'標頭（或其他適合內容類型的檔名）。
14.4.3 驗證是否已放置內容安全政策（CSP）回應標頭，以幫助緩解像HTML、DOM、JSON和JavaScript注入漏洞等XSS攻擊的影響。
14.4.4 驗證所有回應都包含一個 X-Content-Type-Options: nosniff 標頭。
14.4.5 驗證所有回應和所有子域都包含Strict-Transport-Security標頭，例如Strict-Transport-Security: max-age=15724800; includeSubdomains。
14.4.6 請確認是否已包含適當的「Referrer-Policy」標頭，以避免透過「Referer」標頭將URL中的敏感資訊暴露給不受信任的方。
14.4.7 驗證網路應用程式的內容預設無法被嵌入到第三方網站，並且只有在必要的情況下，才允許嵌入確切的資源，方法是使用適當的Content-Security-Policy：frame-ancestors和X-Frame-Options回應標頭。
14.5.1 驗證應用程式伺服器只接受應用程式/API使用的HTTP方法，包括預檢(OPTIONS)請求，並對任何不適用於應用程式上下文的請求進行記錄/警報。
14.5.2 請確認所提供的 Origin 標頭不會用於身份驗證或訪問控制決策，因為攻擊者可以輕易地更改 Origin 標頭。
14.5.3 驗證 Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin 標頭是否使用嚴格的允許列表來匹配信任的域和子域，並且不支持 'null' 來源。
14.5.4 驗證由受信任的代理或SSO設備添加的HTTP標頭，例如持有者令牌，是否由應用程序進行身份驗證。