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

OWASP 應用程式安全驗證標準 (ASVS) 定義了一套全面的應用程式層級安全需求框架。它是一套由社群驅動的基準，用於設計、建置和驗證安全軟體，供架構師、開發人員、測試人員和風險團隊使用。

OWASP 應用程式安全驗證標準 (ASVS) 的目標

該標準的 5.0 版本著重於以下關鍵原則：

  • 精煉的範圍與焦點：圍繞四大支柱（應用程式、安全性、驗證和標準）重新建構該標準，並著重於必須達成的目標，而非規範性的操作步驟。
  • 記錄安全決策：新的元需求要求記錄設計選擇，以確保可追溯性、一致性和可驗證性。
  • 簡化的層級與可及性：保留三個層級（L1–L3），但釐清其範圍：層級 1 提供對常見攻擊的基線防護能力，層級 2 代表標準最佳實務，層級 3 適用於高保證和關鍵系統。
  • 重新建構並擴展的內容：約 350 項需求現涵蓋 17 個章節，引入更清晰的組織架構以及與 v4.0 的對應關係以利遷移。

AppScan Enterprise OWASP 應用程式安全驗證標準 (ASVS) 報告

此 AppScan Enterprise 產業標準報告根據 OWASP 應用程式安全驗證標準 (ASVS) V5.0.0（自 2025 年 5 月起生效）中定義的安全驗證等級來評估您的應用程式。

應用程式安全驗證標準 (ASVS)：

應用程式安全驗證標準由 OWASP 開發和維護。此標準依據 Creative Commons Attribution ShareAlike 3.0 授權條款發佈。如需相關資訊，請參閱 如需相關資訊，請參閱 OWASP 應用程式安全驗證標準 V5.0.0

如需保護 Web 應用程式安全的相關資訊，請參閱 HCL AppScan：進階應用程式安全測試

OWASP 應用程式安全驗證標準 (ASVS) 報告中的漏洞

ID 名稱
1.1.2 驗證應用程式是否在內容交由其預定使用的直譯器處理之前的最後步驟，或由直譯器本身，執行輸出編碼和跳脫處理。
1.2.1 驗證 HTTP 回應、HTML 文件或 XML 文件的輸出編碼是否符合所需情境，例如對 HTML 元素、HTML 屬性、HTML 註解、CSS 或 HTTP 標頭欄位中的相關字元進行編碼，以避免改變訊息或文件結構。
1.2.3 驗證在動態建構 JavaScript 內容（包括 JSON）時使用輸出編碼或跳脫處理，以避免變更訊息或文件結構（避免 JavaScript 和 JSON 注入）。
1.2.4 驗證資料選取或資料庫查詢（例如 SQL、HQL、NoSQL、Cypher）使用參數化查詢、ORM、實體框架，或以其他方式防範 SQL 注入和其他資料庫注入攻擊。這在撰寫預存程序時也同樣適用。
1.2.5 驗證應用程式可防範作業系統命令注入，且作業系統呼叫使用參數化查詢，或採用符合情境的命令列輸出編碼。
1.2.7 驗證應用程式透過使用查詢參數化或預先編譯的查詢來防範 XPath 注入攻擊。
1.3.1 驗證來自 WYSIWYG 編輯器或類似工具的所有不受信任的 HTML 輸入，均使用知名且安全的 HTML 淨化程式庫或框架功能進行淨化處理。
1.3.2 驗證應用程式避免使用 eval() 或其他動態程式碼執行功能，例如 Spring Expression Language (SpEL)。在沒有替代方案的情況下，任何納入其中的使用者輸入在執行前都必須先經過淨化處理。
1.3.3 驗證傳遞至潛在危險上下文的資料事先經過淨化處理以強制執行安全措施，例如僅允許對該上下文安全的字元，並裁剪過長的輸入。
1.3.4 驗證使用者提供的可縮放向量圖形 (SVG) 可執行指令碼內容經過驗證或淨化處理，僅包含對應用程式安全的標籤和屬性（例如僅限安全的繪圖相關標籤與屬性），例如不包含指令碼和 foreignObject。
1.3.5 驗證應用程式淨化或停用使用者提供的可執行指令碼或運算式範本語言內容，例如 Markdown、CSS 或 XSL 樣式表、BBCode 或類似內容。
1.3.6 驗證應用程式透過根據協定、網域、路徑和連接埠的允許清單驗證不受信任的資料，並在使用資料呼叫其他服務之前淨化潛在危險字元，以防範伺服器端請求偽造 (SSRF) 攻擊。
1.3.10 驗證在處理之前，對可能以非預期或惡意方式解析的格式字串進行淨化處理。
1.3.11 驗證應用程式在將使用者輸入傳遞至郵件系統之前進行淨化處理，以防範 SMTP 或 IMAP 注入。
1.4.1 驗證應用程式使用記憶體安全的字串、更安全的記憶體複製和指標運算來偵測或防止堆疊、緩衝區或堆積溢位。
1.4.2 驗證使用符號、範圍和輸入驗證技術來防止整數溢位。
1.5.1 驗證應用程式將 XML 剖析器設定為使用限制性組態，且停用不安全的功能（例如解析外部實體），以防範 XML 外部實體 (XXE) 攻擊。
1.5.2 驗證不受信任資料的反序列化強制執行安全的輸入處理，例如使用物件類型的允許清單或限制用戶端定義的物件類型，以防範反序列化攻擊。明確定義為不安全的反序列化機制不得與不受信任的輸入一起使用。
1.5.3 驗證應用程式中用於相同資料類型的不同剖析器（例如 JSON 剖析器、XML 剖析器、URL 剖析器）以一致的方式執行剖析，並使用相同的字元編碼機制，以避免 JSON 互通性漏洞或不同的 URI 或檔案剖析行為在遠端檔案包含 (RFI) 或伺服器端請求偽造 (SSRF) 攻擊中被利用等問題。
2.2.1 驗證是否已對輸入進行驗證，以強制符合該輸入在業務或功能上的預期。這應使用針對允許值、模式和範圍清單的正向驗證，或根據預先定義的規則，將輸入與預期的結構及邏輯限制進行比對。對於 L1，這可以著重於用於做出特定業務或安全決策的輸入。對於 L2 及以上等級，這應適用於所有輸入。
2.2.2 驗證應用程式是否設計為在受信任的服務層強制執行輸入驗證。雖然用戶端驗證可改善可用性且應予鼓勵，但不得將其視為可依賴的安全控制措施。
2.2.3 驗證應用程式是否確保相關資料項目的組合符合預先定義的規則且屬合理。
2.3.1 驗證應用程式僅按照預期的順序步驟處理同一使用者的業務邏輯流程，且不會跳過步驟。
2.3.2 驗證是否已根據應用程式文件實施業務邏輯限制，以避免業務邏輯缺陷遭到利用。
2.4.1 驗證已實施反自動化控制措施，以防止對應用程式功能的過度呼叫，這些過度呼叫可能導致資料外洩、垃圾資料產生、配額耗盡、速率限制違規、阻斷服務或高成本資源的過度使用。
2.4.2 驗證業務邏輯流程要求符合實際的人工作業時間，以防止過快提交交易。
3.2.1 驗證已實施安全控制措施，以防止瀏覽器在不正確的上下文中呈現 HTTP 回應中的內容或功能（例如，當直接請求 API、使用者上傳的檔案或其他資源時）。可能的控制措施包括：除非 HTTP 請求標頭欄位（如 Sec-Fetch-\*）指示其為正確的上下文，否則不提供內容；使用 Content-Security-Policy 標頭欄位的 sandbox 指令；或使用 Content-Disposition 標頭欄位中的 attachment 處置類型。
3.3.1 驗證 Cookie 已設定 'Secure' 屬性，且如果 Cookie 名稱未使用 '\__Host-' 前綴，則 Cookie 名稱必須使用 '__Secure-' 前綴。
3.3.2 驗證每個 Cookie 的 'SameSite' 屬性值已根據 Cookie 的用途進行設定，以限制使用者介面偽裝攻擊和基於瀏覽器的請求偽造攻擊（通常稱為跨站請求偽造 (CSRF)）的風險。
3.3.3 驗證 Cookie 的名稱使用 '__Host-' 前綴，除非該 Cookie 明確設計為與其他主機共用。
3.3.4 驗證如果 Cookie 的值不應被用戶端腳本存取（例如工作階段權杖），則該 Cookie 必須設定 'HttpOnly' 屬性，且相同的值（例如工作階段權杖）只能透過 'Set-Cookie' 標頭欄位傳送至用戶端。
3.4.1 驗證所有回應中都包含 Strict-Transport-Security 標頭欄位，以強制執行 HTTP 嚴格傳輸安全 (HSTS) 策略。必須定義至少 1 年的最大存留時間，且對於 L2 及以上級別，該策略也必須適用於所有子網域。
3.4.2 驗證跨來源資源共用 (CORS) 的 Access-Control-Allow-Origin 標頭欄位是由應用程式設定的固定值，或者如果使用了 Origin HTTP 請求標頭欄位的值，則該值已根據受信任來源的允許清單進行驗證。當需要使用 'Access-Control-Allow-Origin: *' 時，驗證回應中不包含任何敏感資訊。
3.4.3 驗證 HTTP 回應包含 Content-Security-Policy 回應標頭欄位，該欄位定義指令以確保瀏覽器僅載入和執行受信任的內容或資源，從而限制惡意 JavaScript 的執行。至少必須使用全域策略，其中包含 object-src 'none' 和 base-uri 'none' 指令，並定義允許清單或使用 nonce 或雜湊值。對於 L3 應用程式，必須定義使用 nonce 或雜湊值的逐回應策略。
3.4.4 驗證所有 HTTP 回應都包含 'X-Content-Type-Options: nosniff' 標頭欄位。這會指示瀏覽器不要對給定的回應使用內容嗅探和 MIME 類型猜測，並要求回應的 Content-Type 標頭欄位值與目標資源相符。例如，只有當回應的 Content-Type 為 'text/css' 時，才會接受對樣式表請求的回應。這也使瀏覽器能夠使用跨來源讀取封鎖 (CORB) 功能。
3.4.5 驗證應用程式設定了 Referrer Policy，以防止透過 'Referer' HTTP 請求標頭欄位將技術上敏感的資料洩漏給第三方服務。這可以透過使用 Referrer-Policy HTTP 回應標頭欄位或透過 HTML 元素屬性來完成。敏感資料可能包括 URL 中的路徑和查詢資料，對於內部非公開應用程式，還包括主機名稱。
3.4.6 驗證 Web 應用程式在每個 HTTP 回應中使用 Content-Security-Policy 標頭欄位的 frame-ancestors 指令，以確保預設情況下不能被嵌入，且僅在必要時才允許嵌入特定資源。請注意，X-Frame-Options 標頭欄位雖然受瀏覽器支援，但已過時，不應依賴。
3.5.1 驗證如果應用程式不依賴 CORS 預檢機制來防止不允許的跨來源請求使用敏感功能，則這些請求已經過驗證以確保它們來自應用程式本身。這可以透過使用並驗證防偽權杖，或要求使用不屬於 CORS safelisted request-header fields 的額外 HTTP 標頭欄位來完成。這是為了防禦基於瀏覽器的請求偽造攻擊，通常稱為跨站請求偽造 (CSRF)。
3.5.2 驗證如果應用程式依賴 CORS 預檢機制來防止不允許的跨來源使用敏感功能，則無法使用不會觸發 CORS 預檢請求的請求來呼叫該功能。這可能需要檢查 'Origin' 和 'Content-Type' 請求標頭欄位的值，或使用不屬於 CORS safelisted header fields 的額外標頭欄位。
3.5.3 驗證對敏感功能的 HTTP 請求使用適當的 HTTP 方法，例如 POST、PUT、PATCH 或 DELETE，而非 HTTP 規範定義為「安全」的方法，例如 HEAD、OPTIONS 或 GET。或者，可以使用對 Sec-Fetch-* 請求標頭欄位的嚴格驗證，以確保請求並非來自不適當的跨來源呼叫、導覽請求或非預期的資源載入（例如圖片來源）。
3.5.4 驗證不同的應用程式託管在不同的主機名稱上，以利用同源策略提供的限制，包括由一個來源載入的文件或腳本如何與另一個來源的資源互動，以及基於主機名稱的 Cookie 限制。
3.6.1 驗證用戶端資產（例如 JavaScript 程式庫、CSS 或網頁字型）僅在資源為靜態且具有版本控制，並使用子資源完整性 (SRI) 來驗證資產完整性的情況下，才託管於外部（例如內容傳遞網路）。如果無法做到這一點，則應針對每個資源提供有文件記錄的安全決策來加以說明。
3.7.1 驗證應用程式僅使用仍受支援且被認為安全的用戶端技術。不符合此要求的技術範例包括 NSAPI 外掛程式、Flash、Shockwave、ActiveX、Silverlight、NACL 或用戶端 Java Applet。
3.7.3 驗證當使用者被重新導向至應用程式控制範圍以外的 URL 時，應用程式會顯示通知，並提供取消導覽的選項。
4.1.1 驗證每個包含訊息主體的 HTTP 回應都包含與回應實際內容相符的 Content-Type 標頭欄位，包括用於指定安全字元編碼（例如 UTF-8、ISO-8859-1）的 charset 參數，並符合 IANA 媒體類型，例如 text/*、*/*+xml 和 */xml。
4.1.4 驗證僅允許使用應用程式或其 API 明確支援的 HTTP 方法（包括預檢請求期間的 OPTIONS），且未使用的方法已被封鎖。
4.1.5 驗證對於高度敏感或經過多個系統的請求或交易，使用逐訊息數位簽章在傳輸保護之上提供額外的保證。
4.3.1 驗證使用查詢允許清單、深度限制、數量限制或查詢成本分析，以防止因昂貴的巢狀查詢而導致的 GraphQL 或資料層表達式阻斷服務 (DoS) 攻擊。
5.2.1 驗證應用程式僅接受其能在不造成效能下降或阻斷服務攻擊的情況下處理的大小之檔案。
5.2.4 驗證已強制執行檔案大小配額和每位使用者的最大檔案數量，以確保單一使用者無法以過多檔案或過大檔案填滿儲存空間。
5.3.1 驗證由不受信任的輸入上傳或產生並儲存在公開資料夾中的檔案，在透過 HTTP 請求直接存取時不會作為伺服器端程式碼執行。
5.3.2 驗證當應用程式為檔案操作建立檔案路徑時，使用內部產生或受信任的資料來取代使用者提交的檔案名稱；如果必須使用使用者提交的檔案名稱或檔案中繼資料，則必須套用嚴格的驗證和清理。這是為了防範路徑遍歷、本機或遠端檔案包含 (LFI、RFI) 以及伺服器端請求偽造 (SSRF) 攻擊。
5.4.1 驗證應用程式會驗證或忽略使用者提交的檔案名稱（包括 JSON、JSONP 或 URL 參數中的檔案名稱），並在回應的 Content-Disposition 標頭欄位中指定檔案名稱。
6.1.3 驗證：如果應用程式包含多個驗證途徑，則這些途徑皆已連同必須在各途徑中一致執行的安全控制措施與驗證強度一併記錄。
6.2.1 驗證使用者設定的密碼長度至少為 8 個字元，但強烈建議最少為 15 個字元。
6.2.9 驗證允許使用至少 64 個字元的密碼。
6.3.1 驗證已根據應用程式的安全文件實作防止憑證填充和密碼暴力破解等攻擊的控制措施。
6.3.2 驗證預設使用者帳戶（例如 'root'、'admin' 或 'sa'）不存在於應用程式中，或已被停用。
6.3.3 驗證必須使用多因素驗證機制或單因素驗證機制的組合才能存取應用程式。對於 L3，其中一個因素必須是基於硬體的驗證機制；該機制必須透過要求使用者主動執行操作（例如按下 FIDO 硬體金鑰或行動電話上的按鈕）來驗證其驗證意圖，並在抵禦網路釣魚攻擊方面提供防遭入侵與防冒充能力。放寬此要求中的任何考量事項，都需要完整記錄的理由和一套全面的緩解控制措施。
6.3.6 驗證電子郵件未被用作單因素或多因素驗證機制。
6.4.1 驗證系統產生的初始密碼或啟用碼是以安全的隨機方式產生、遵循現有的密碼政策，並在短時間內或首次使用後過期。這些初始祕密資料不得允許成為長期密碼。
6.4.2 驗證不存在密碼提示或基於知識的驗證（即所謂的 '安全問題'）。
6.5.1 驗證查閱密鑰、帶外驗證請求或代碼以及基於時間的一次性密碼 (TOTP) 僅能成功使用一次。
6.5.2 驗證當儲存在應用程式後端時，熵值低於 112 位元（19 個隨機英數字元或 34 個隨機數字）的查閱密鑰，使用包含 32 位元隨機鹽值的核准密碼儲存雜湊演算法進行雜湊處理。如果密鑰具有 112 位元或更高的熵值，則可以使用標準雜湊函式。
6.5.3 驗證查閱密鑰、帶外驗證代碼及基於時間的一次性密碼種子，均使用密碼學安全偽隨機數產生器 (CSPRNG) 產生，以避免可預測的值。
7.2.2 驗證應用程式使用自包含權杖或參考權杖進行工作階段管理，且這些權杖是動態產生的，也就是說，不使用靜態 API 祕密與金鑰。
7.2.3 驗證：如果使用參考權杖來表示使用者工作階段，這些權杖必須是唯一的，且使用密碼學安全偽隨機數產生器 (CSPRNG) 產生，並具有至少 128 位元的熵值。
7.2.4 驗證應用程式在使用者驗證（包括重新驗證）時產生新的工作階段權杖，並終止目前的工作階段權杖。
7.3.2 驗證存在絕對的工作階段存續時間上限，以便根據風險分析和已記錄的安全決策強制執行重新驗證。
7.4.1 驗證當觸發工作階段終止（例如登出或到期）時，應用程式不允許進一步使用該工作階段。對於參考權杖或具狀態的工作階段，這意味著在應用程式後端使工作階段資料失效。使用自包含權杖的應用程式將需要一種解決方案，例如維護已終止權杖的清單、不允許使用在每位使用者各自設定的日期與時間之前產生的權杖，或輪換每位使用者的簽署金鑰。
7.4.3 驗證應用程式在成功變更或移除任何驗證因素（包括透過重設或復原進行的密碼變更，以及（若有）MFA 設定更新）後，提供終止所有其他作用中工作階段的選項。
7.5.1 驗證應用程式在允許修改可能影響驗證的敏感帳戶屬性（例如電子郵件地址、電話號碼、MFA 組態或其他用於帳戶復原的資訊）之前，要求完整的重新驗證。
7.5.2 驗證使用者能夠檢視並（在至少使用一個因素重新驗證後）終止任何或所有目前作用中的工作階段。
8.1.1 驗證授權文件定義了根據消費者權限和資源屬性來限制功能層級和資料特定存取的規則。
8.2.1 驗證應用程式確保功能層級存取僅限於具有明確權限的消費者。
8.2.2 驗證應用程式確保資料特定存取僅限於對特定資料項目具有明確權限的消費者，以降低不安全的直接物件參考 (IDOR) 和物件層級授權失效 (BOLA) 風險。
8.3.1 驗證應用程式在受信任的服務層強制執行授權規則，且不依賴不受信任的消費者可能操控的控制措施，例如用戶端 JavaScript。
8.4.2 驗證對管理介面的存取納入多層安全措施，包括持續的消費者身分驗證、裝置安全態勢評估和情境風險分析，確保網路位置或受信任的端點不是授權的唯一因素，即使它們可能降低未經授權存取的可能性。
9.1.1 驗證自包含權杖在接受其內容之前，使用其數位簽章或 MAC 進行驗證，以防止竄改。
10.4.9 驗證重新整理權杖和參考存取權杖可由授權使用者透過授權伺服器使用者介面撤銷，以降低惡意用戶端或被竊取權杖的風險。
11.1.2 驗證已執行密碼學盤點，並持續維護和定期更新，且包含應用程式使用的所有密碼學金鑰、演算法和憑證。還必須記錄金鑰在系統中可以和不可以使用的位置，以及可以和不可以使用金鑰保護的資料類型。
11.2.1 驗證密碼學作業使用經業界驗證的實作（包括程式庫和硬體加速實作）。
11.2.2 驗證應用程式的設計具備密碼學敏捷性，使得亂數、驗證式加密、MAC 或雜湊演算法、金鑰長度、輪數、加密演算法和模式可以隨時重新組態、升級或替換，以防範密碼學機制遭破解。同樣地，也必須能夠替換金鑰和密碼並重新加密資料。這將允許在經核准的後量子密碼學 (PQC) 方案或標準的高保證實作廣泛可用後，無縫升級至後量子密碼學 (PQC)。
11.2.4 驗證所有密碼學作業都是常數時間的，在比較、計算或回傳中沒有「短路」作業，以避免洩漏資訊。
11.2.5 驗證所有密碼學模組都能安全地失敗，且錯誤處理方式不會導致漏洞，例如填充預言機攻擊。
11.3.1 驗證未使用不安全的區塊模式（例如 ECB）和弱填充方案（例如 PKCS#1 v1.5）。
11.3.3 驗證加密資料受到保護，以防止未經授權的修改，最好使用經核准的驗證式加密方法，或結合經核准的加密方法與經核准的 MAC 演算法。
11.3.4 驗證隨機數（nonce）、初始化向量及其他一次性使用的數值不會被重複用於多個加密金鑰與資料元素的配對。生成方法必須適合所使用的演算法。
11.4.2 驗證密碼是使用經核准的、計算密集型的金鑰衍生函式（亦稱為「密碼雜湊函式」）進行儲存，且參數設定是根據當前指引進行配置。設定應在安全性與效能之間取得平衡，使暴力破解攻擊在所需的安全等級下足夠困難。
11.5.1 驗證所有預期應無法被猜測的隨機數和字串，必須使用密碼學安全的偽隨機數生成器（CSPRNG）生成，且至少具有 128 位元的熵。請注意，UUID 不符合此條件。
11.5.2 驗證所使用的隨機數生成機制即使在高負載需求下也能安全運作。
12.1.1 驗證僅啟用最新推薦版本的 TLS 協定，例如 TLS 1.2 和 TLS 1.3。最新版本的 TLS 協定必須作為首選選項。
12.2.1 驗證 TLS 用於用戶端與面向外部的基於 HTTP 的服務之間的所有連線，且不會回退至不安全或未加密的通訊。
12.3.1 驗證所有進出應用程式的入站和出站連線均使用加密協定（如 TLS），包括監控系統、管理工具、遠端存取和 SSH、中介軟體、資料庫、大型主機、合作夥伴系統或外部 API。伺服器不得回退至不安全或未加密的協定。
12.3.4 驗證內部服務之間的 TLS 連線使用受信任的憑證。當使用內部生成或自簽憑證時，消費端服務必須配置為僅信任特定的內部 CA 和特定的自簽憑證。
12.3.5 驗證系統內部服務之間的通訊（服務間通訊）使用強認證以確保每個端點均經過驗證。必須採用強認證方法（如 TLS 用戶端認證）來確保身分識別，使用公開金鑰基礎架構及能抵禦重放攻擊的機制。對於微服務架構，建議使用服務網格（service mesh）來簡化憑證管理並增強安全性。
13.2.1 驗證不支援應用程式標準使用者工作階段機制的後端應用程式元件之間的通訊（包括 API、中介軟體和資料層）均經過認證。認證必須使用個別服務帳戶、短期權杖或基於憑證的認證，而非固定不變的憑據，例如密碼、API 金鑰或具有特權存取的共用帳戶。
13.2.2 驗證後端應用程式元件之間的通訊（包括本機或作業系統服務、API、中介軟體和資料層）使用被指派最低必要權限的帳戶執行。
13.2.5 驗證網頁伺服器或應用程式伺服器已配置資源或系統的允許清單，限定伺服器可向其發送請求或從中載入資料或檔案的對象。
13.3.1 驗證使用機密管理解決方案（如金鑰保管庫）來安全地建立、儲存、控制存取及銷毀後端機密資訊。這些機密資訊可能包括密碼、金鑰材料、與資料庫和第三方系統的整合資訊、基於時間的權杖的金鑰和種子、其他內部機密資訊以及 API 金鑰。機密資訊不得包含在應用程式原始碼中或納入建置產出物中。對於 L3 級別的應用程式，必須使用硬體支援的解決方案，例如 HSM。
13.3.3 驗證所有密碼學運算均在隔離的安全模組（如保管庫或硬體安全模組）中執行，以安全地管理和保護金鑰材料，防止其暴露於安全模組之外。
13.4.2 驗證在生產環境中所有元件的偵錯模式均已停用，以防止偵錯功能暴露和資訊洩漏。
13.4.3 驗證網頁伺服器不會向用戶端公開目錄列表，除非明確有此意圖。
13.4.5 驗證文件（例如內部 API 的文件）和監控端點不會被公開，除非明確有此意圖。
13.4.6 驗證應用程式不會公開後端元件的詳細版本資訊。
13.4.7 驗證網頁層已配置為僅提供具有特定副檔名的檔案，以防止意外的資訊、配置和原始碼洩漏。
14.1.1 驗證應用程式建立和處理的所有敏感資料均已被識別並分類至相應的保護等級。這包括僅經過編碼因而容易解碼的資料，例如 Base64 字串或 JWT 內的明文酬載。保護等級需要考慮應用程式必須遵守的任何資料保護和隱私法規及標準。
14.1.2 驗證所有敏感資料保護等級均有一套已記錄的保護要求。這必須包括（但不限於）與一般加密、完整性驗證、保留期限、資料記錄方式、日誌中敏感資料的存取控制、資料庫層級加密、隱私及應使用的隱私增強技術以及其他機密性要求相關的要求。
14.2.1 驗證敏感資料僅透過 HTTP 訊息主體或標頭欄位傳送至伺服器，且 URL 和查詢字串不包含敏感資訊，例如 API 金鑰或工作階段權杖。
14.2.2 驗證應用程式防止敏感資料被快取在伺服器元件中（例如負載平衡器和應用程式快取），或確保資料在使用後被安全清除。
14.3.3 驗證儲存在瀏覽器儲存空間中的資料（例如 localStorage、sessionStorage、IndexedDB 或 Cookie）不包含敏感資料，但工作階段權杖除外。
15.1.2 驗證是否維護了所有使用中第三方程式庫的清單目錄（例如軟體物料清單 (SBOM)），包括驗證元件是否來自預先定義的、受信任的且持續維護的儲存庫。
15.2.4 驗證第三方元件及其所有傳遞性相依項目是否來自預期的儲存庫（無論是內部擁有的還是外部來源），且不存在相依性混淆攻擊的風險。
15.3.3 驗證應用程式是否具有防範大量指派攻擊的對策，方法是限制每個控制器和動作的允許欄位，例如，當某個欄位值不應作為該動作的一部分時，無法插入或更新該欄位值。
15.3.7 驗證應用程式是否具有防禦 HTTP 參數污染攻擊的措施，特別是當應用程式框架未區分請求參數的來源（查詢字串、主體參數、Cookie 或標頭欄位）時。
15.4.1 驗證多執行緒程式碼中的共用物件（例如快取、檔案或由多個執行緒存取的記憶體內物件）是否透過使用執行緒安全類型和同步機制（如鎖定或號誌）來安全存取，以避免競爭條件和資料損毀。
15.4.2 驗證對資源狀態的檢查（例如其存在與否或權限）以及依賴這些檢查的動作，是否作為單一原子操作執行，以防止檢查時到使用時 (TOCTOU) 的競爭條件。例如，在開啟檔案之前檢查檔案是否存在，或在授予存取權限之前驗證使用者的存取權。
16.2.1 驗證每個日誌項目是否包含必要的中繼資料（例如時間、地點、人員、內容），以便在事件發生時能夠對時間軸進行詳細調查。
16.2.5 驗證在記錄敏感資料時，應用程式是否會依據資料的保護層級強制執行記錄規則。例如，可能不允許記錄某些資料，例如認證資訊或付款詳細資料。其他資料（例如工作階段權杖）則可能只能在經過完整或部分雜湊或遮罩後才能記錄。
16.3.3 驗證應用程式是否記錄文件中定義的安全事件，並記錄嘗試繞過安全控制的行為，例如繞過輸入驗證、業務邏輯和反自動化控制。
16.4.1 驗證所有記錄元件是否適當地編碼資料，以防止日誌注入。
16.4.2 驗證日誌是否受到保護，防止未經授權的存取且無法被修改。
16.5.1 驗證當發生非預期或安全敏感的錯誤時，是否向取用者傳回一般性訊息，確保不會暴露堆疊追蹤、查詢、密鑰和權杖等敏感的內部系統資料。
16.5.3 驗證應用程式是否會以可控且安全的方式失效，包括在發生例外狀況時，並防止故障開放情況，例如儘管驗證邏輯發生錯誤仍繼續處理交易。
16.5.4 驗證是否定義了「最後防線」錯誤處理常式，以捕捉所有未處理的例外狀況。這既是為了避免遺失必須記錄到日誌檔案的錯誤詳細資料，也是為了確保錯誤不會導致整個應用程式處理程序當機，從而造成可用性喪失。