OWASP 应用程序安全验证标准 4.0.3

请确保所有应用程序组件使用相同的编码和解析器，以避免利用不同 URI 或文件解析行为的解析攻击，这类攻击可能被用于 SSRF 和 RFI 攻击。

[已删除，重复 4.3.1]

验证 API URL 不会暴露敏感信息，例如 API 密钥、会话令牌等。

确认授权决策在 URI 层面（由控制器或路由器通过编程或声明式安全执行）和资源层面（由基于模型的权限执行）都已做出。

验证包含意外或缺失内容类型的请求是否被拒绝，并返回适当的头信息（HTTP 响应状态 406 不可接受或 415 不支持的媒体类型）。

验证启用的 RESTful HTTP 方法是否对用户或操作是有效的选择，例如防止普通用户在受保护的 API 或资源上使用 DELETE 或 PUT。

在接受输入之前，确保已启用并验证 JSON 模式验证。

验证使用 Cookie 的 RESTful 网络服务是否通过以下一种或多种方式防止跨站请求伪造 (CSRF)：双重提交 Cookie 模式、CSRF 随机数（nonce）或 Origin 请求头检查。

[已删除，重复 11.1.4]

验证 REST 服务是否明确检查传入的 Content-Type 是否为预期类型，例如 application/xml 或 application/json。

验证消息头和有效负载是否可信，并且在传输过程中未被修改。在许多情况下，要求传输使用强加密（仅限 TLS）可能就足够了，因为它同时提供机密性和完整性保护。每条消息的数字签名可以在传输保护的基础上为高安全性应用提供额外的保障，但同时也带来了额外的复杂性和风险，需要权衡其益处。

验证 XSD 模式以确保 XML 文档格式正确，然后在处理任何数据之前验证每个输入字段。

验证消息负载是否使用 WS-Security 签名，以确保客户端与服务之间的传输可靠。

请验证是否使用了查询允许列表或深度限制与数量限制相结合的方法，以防止由于昂贵的嵌套查询导致的 GraphQL 或数据层表达式拒绝服务（DoS）。对于更高级的场景，应使用查询成本分析。

请确认 GraphQL 或其他数据层的授权逻辑应在业务逻辑层实现，而不是在 GraphQL 层实现。