HTTP 401 与 403

401 需要返回认证挑战

HTTP 401 表示一个请求针对目标资源缺少有效的认证凭据。 HTTP 认证和状态语义 要求生成 401 响应的服务器包含一个带有适用挑战的 WWW-Authenticate 响应头。历史上的原因短语 Unauthorized 并不改变其认证含义。

缺失的凭据、过期的凭据或无效的认证方案都可能导致 401，具体取决于服务。在更改值之前，先诊断文档中描述的方案。发送到错误响应头的有效 API key 即使本身正确，也会因为位置错误而无法使用。

对于你自己运营的服务，检查响应是否确实包含挑战以及有用且安全的错误描述。只含状态码而缺乏预期响应头，可能表示应用响应不符合规范，或有中间方修改了消息。在事件记录中保持这个区分是可见的。

403 表达拒绝但不证明已登录

HTTP 403 表示服务器理解了请求并拒绝满足它。权限失败是常见情况，但该状态并不能证明认证已经成功。匿名请求可以在建立用户身份之前，就被策略禁止访问。

示例包括：调用方缺少对某个项目的访问权限、请求被应用规则禁止，或网关拒绝了该请求。仅凭状态码无法区分这些情况。在选择补救措施前，先确认响应体、相关响应头以及产生该拒绝的系统。

不要假定自动附加不同的凭据就是正确做法。有些拒绝与凭据无关，不必要的凭据转发可能会将机密暴露给错误的目标。如果你拥有该服务，使用内部日志来识别被评估的规则，同时保证对外错误响应仅包含调用方被允许接收的信息。

持有者令牌错误提供更具体含义

使用持有者令牌的 API 可以给出比状态码本身更具体的错误。 持有者令牌错误定义 区分 invalid_token 和 insufficient_scope，并将它们与不同的响应行为关联起来。这些字段有助于区分完全不可用的令牌与缺少所需 scope 的令牌。

该术语体系适用于使用 bearer-token 方案的 API。不应将其套用于期望在其他响应头中接收原始 API key 的服务。将错误含义与文档中描述的认证接口相匹配，包括区分响应是 HTTP 挑战还是 JSON 应用错误包络。

对于一个假设的项目导出场景，一个令牌可能正确标识了应用本身，但不具备对导出功能的访问权限。合适的排查方向是已授予的 scope 和资源策略。用另一个具有相同权限的令牌替换它，会得到同样的访问决策。记录预期操作和 scope，并一并写入诊断信息。

跨越每个 API 边界追踪响应

分层数据工作流可以包含从客户端到提供方的请求，以及从提供方到目标方的请求。提供方的 HTTP 响应和目标方记录的状态可能是不同的信息片段。一个可能描述提供方是否接受了该任务，另一个则可能描述在目标端发生了什么。

在将正文中的数字解释为传输状态之前，先阅读提供方记录的响应封装格式。尽可能捕获外层状态、错误代码、消息和目标详细信息。在共享记录之前，请编辑（删减）凭证和个人信息。

还要识别你所控制系统中的网关和反向代理。网关可以在请求到达应用程序之前就拒绝该请求。这样一来，应用程序的日志中可能不会包含对应的请求记录，这只能说明问题出在边界处，而不能证明客户端从未发送任何内容。跨受支持的各个组件使用关联标识符来缩小问题来源。

对于服务所有者，测试资源决策

服务所有者应测试访问检查是否适用于所请求的资源和操作。 OWASP 授权建议 强调最小权限原则，并在每个请求上进行验证。有效身份并不能免除对对象级访问的评估。

使用仅具有对一个项目访问权限的用户，对另一个项目的标识符进行测试。分别测试读取和编辑。测试后台导出路由以及交互式端点。通过某一路由成功的请求，不应因为另一个暴露相同数据的路由而意外获得更广泛的权限。

选择响应细节时要谨慎。一些系统会使用“未找到”类型的响应，以避免向无访问权限的调用方暴露某个资源是否存在。为客户端记录这种行为，并为获授权的运营人员保留内部原因。不要通过向未授权的调用方暴露资源名称或策略细节来让诊断过程变得更加方便。

分别诊断无爬取端和目标端的响应

一个请求 Scrapeless Web Unlocker 在解释任何目标结果之前具有其自身的身份验证边界。目前 Scrapeless API 密钥说明 为相关的 API 表层指定凭证方法。首先根据已记录的行为和已编辑的诊断信息确认该边界。

如果平台接受该请求，请分别检查生成的目标信息。托管检索并不授予对私有目标资源的访问授权。访问被拒绝应被视为检查范围和需求的信号，而不是访问预期集合边界之外数据的许可。

The 403 响应诊断工作流程 提供相关上下文以定位该拒绝。使用当前 无爬取方案定价 用于产品规划，同时在错误分类中将计费、产品可用性、请求验证和目标授权明确区分开来。

构建可引导至特定行动的诊断记录

一个有用的诊断记录应包括请求的目标地址、方法、已编辑的凭据方案、外部状态、在存在时的质询头，以及相关的错误字段。使用可以安全共享的标识符添加正在调查的资源和操作。如果服务提供关联 ID，应保留该关联 ID。

对于 401，检查预期的认证方案、密钥加载、令牌有效性，以及在适用时检查受众或目标方。对于 403，识别产生该响应的组件，并检查资源策略或已记录的访问限制。如果该服务不遵循标准约定，则记录其实际行为及自身文档，而不是强行用教科书式解释来套用。

当证据表明存在预期的拒绝时停止。正确的结果可能是范围内的权限请求、配置更正，或移除超出范围的任务。成功的诊断是对访问决策的解释，而不一定是请求本身的成功。在运营报告中要明确区分这一点。

结论

当你将响应追溯到生成它的组件时，HTTP 401 与 403 的区别才变得可付诸行动。使用 401 质询来排查身份验证问题，使用 403 作为拒绝访问的证据，其原因仍然需要结合上下文来分析。将提供方与目标方的结果区分开来，编辑隐去凭据，并让下一步行动与该次具体访问决策精确匹配。

参考资料

• Web Unlocker 检索模型
• Scrapeless Web Unlocker
• 诊断被禁止的响应