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 Application Security Verification Standard V5.0.0

有关保护 Web 应用程序安全的更多信息，请参阅 HCL AppScan: Advanced Application Security Testing

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-' 前缀，则必须使用 '__Secure-' 前缀。
3.3.2 验证每个 Cookie 的 'SameSite' 属性值是否已根据其用途进行设置，以限制其遭受用户界面诱骗攻击以及基于浏览器的请求伪造攻击（通常称为跨站请求伪造，即 CSRF）的风险。
3.3.3 验证 Cookie 名称是否带有 '__Host-' 前缀，除非它们被明确设计为与其他主机共享。
3.3.4 验证：如果 Cookie 的值不应被客户端脚本访问（例如会话令牌），则该 Cookie 必须设置 'HttpOnly' 属性，并且相同的值（例如会话令牌）只能通过 'Set-Cookie' 头字段传输给客户端。
3.4.1 验证所有响应中是否包含 Strict-Transport-Security 头字段，以强制执行 HTTP 严格传输安全 (HSTS) 策略。必须定义至少 1 年的 max-age 值，对于 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 应用程序，必须定义带有随机数或哈希值的逐响应策略。
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 安全列表中的额外 HTTP 头字段来实现。这是为了防御基于浏览器的请求伪造攻击，通常称为跨站请求伪造 (CSRF)。
3.5.2 验证如果应用程序依赖 CORS 预检机制来防止未经允许的跨域使用敏感功能，则无法通过不触发 CORS 预检请求的请求来调用该功能。这可能需要检查 'Origin' 和 'Content-Type' 请求头字段的值，或使用不属于 CORS 安全列表的额外头字段。
3.5.3 验证对敏感功能的 HTTP 请求是否使用适当的 HTTP 方法（如 POST、PUT、PATCH 或 DELETE），而不是 HTTP 规范中定义的“安全”方法（如 HEAD、OPTIONS 或 GET）。或者，可以使用对 Sec-Fetch-* 请求头字段的严格验证，以确保请求并非源自不适当的跨域调用、导航请求，或在不应发生此类情况时的资源加载（例如图像源）。
3.5.4 验证各独立应用程序托管在不同的主机名上，以利用同源策略提供的限制，包括一个来源加载的文档或脚本如何与另一个来源的资源交互，以及基于主机名的 Cookie 限制。
3.6.1 验证客户端资产（如 JavaScript 库、CSS 或 Web 字体）仅在资源为静态且有版本控制并且使用子资源完整性 (SRI) 验证资产完整性的情况下，才在外部托管（例如在内容分发网络上）。如果无法做到这一点，则应针对每个资源形成书面的安全决策以证明其合理性。
3.7.1 验证应用程序仅使用仍受支持且被认为安全的客户端技术。不满足此要求的技术示例包括 NSAPI 插件、Flash、Shockwave、ActiveX、Silverlight、NACL 或客户端 Java 小程序。
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 验证所有加密模块是否以安全方式失效，并且错误处理不会引入漏洞，例如 Padding Oracle 攻击。
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 客户端身份验证）来确保身份，使用公钥基础设施和能够抵御重放攻击的机制。对于微服务架构，请考虑使用服务网格来简化证书管理并增强安全性。
13.2.1 验证不支持应用程序标准用户会话机制的后端应用程序组件之间的通信（包括 API、中间件和数据层）是否经过身份验证。身份验证必须使用单独的服务帐户、短期令牌或基于证书的身份验证，而不能使用静态凭据，例如密码、API 密钥或具有特权访问权限的共享帐户。
13.2.2 验证后端应用程序组件之间的通信（包括本地或操作系统服务、API、中间件和数据层）是否使用分配了最低必要权限的帐户执行。
13.2.5 验证 Web 或应用程序服务器是否配置了允许列表，以限定服务器只能向其中的资源或系统发送请求，或从中加载数据或文件。
13.3.1 验证是否使用机密信息管理解决方案（如密钥保管库）来安全地创建、存储、控制对后端机密信息的访问以及销毁这些信息。这些可能包括密码、密钥材料、与数据库和第三方系统的集成、基于时间的令牌的密钥和种子、其他内部机密信息以及 API 密钥。机密信息不得包含在应用程序源代码中或包含在构建工件中。对于 L3 应用程序，这必须涉及基于硬件的解决方案，例如 HSM。
13.3.3 验证所有加密操作是否在隔离的安全模块（如保管库或硬件安全模块）中执行，以安全地管理和保护密钥材料，防止其暴露在安全模块之外。
13.4.2 验证是否在生产环境中禁用了所有组件的调试模式，以防止调试功能暴露和信息泄露。
13.4.3 验证 Web 服务器是否不向客户端公开目录列表，除非明确有此意图。
13.4.5 验证文档（例如内部 API 的文档）和监控端点是否未被公开，除非明确有此意图。
13.4.6 验证应用程序不会暴露后端组件的详细版本信息。
13.4.7 验证 Web 层是否配置为仅提供具有特定文件扩展名的文件，以防止意外的信息、配置和源代码泄露。
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 验证是否定义了“最后防线”错误处理程序，该程序将捕获所有未处理的异常。这样做既是为了避免丢失必须进入日志文件的错误详情，也是为了确保错误不会导致整个应用程序进程宕机，从而导致可用性损失。