OWASP应用程序安全验证标准报告

应用程序安全验证标准（ASVS）是一份应用程序安全需求或测试的清单，可以被架构师、开发者、测试人员、安全专业人员、工具供应商和消费者用来定义、构建、测试和验证安全的应用程序。

应用程序安全验证标准（ASVS）的目标

  • 帮助组织开发和维护安全的应用程序。
  • 为了让安全服务供应商、安全工具供应商和消费者能够对齐他们的需求和提供。

AppScan 和ASVS标准

这份AppScan合规报告使用了ASVS第3级。ASVS等级3适用于最关键的应用程序，即执行高价值交易的应用程序，包含敏感医疗数据的应用程序，或者任何需要最高信任级别的应用程序。

应用程序安全验证标准是由OWASP开发和维护的。此标准根据创作共用署名-相同方式共享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 验证如果应用程序与其他可能会泄露会话cookie的应用程序一起在一个域名下发布，那么在基于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，headers，或环境变量）没有区别对待。
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 验证应用程序是否通过验证或清理不受信任的数据或HTTP文件元数据（如文件名和URL输入字段）来防止SSRF攻击，并使用协议、域、路径和端口的允许列表。
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库、节点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的URL不会暴露敏感信息，如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 - 验证在生产中禁用了Web或应用服务器和应用框架的调试模式，以消除调试功能、开发者控制台和无意的安全信息泄露。
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）响应头，以帮助减轻XSS攻击（如HTML、DOM、JSON和JavaScript注入漏洞）的影响。
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 验证Web应用程序的内容默认不能嵌入到第三方网站中，并且只有在使用适当的Content-Security-Policy：frame-ancestors和X-Frame-Options响应头时，才允许嵌入确切的资源。
14.5.1 验证应用服务器只接受应用/ API使用的HTTP方法，包括预检OPTIONS，并对任何不适用于应用上下文的请求进行记录/警报。
14.5.2 验证提供的Origin头部是否未用于身份验证或访问控制决策，因为攻击者可以轻易地更改Origin头部。
14.5.3 验证跨源资源共享（CORS）Access-Control-Allow-Origin头是否使用严格的允许列表来匹配受信任的域和子域，并且不支持'null'起源。
14.5.4 验证应用程序是否对受信任的代理或SSO设备添加的HTTP头，如承载令牌，进行了身份验证。