什么是CORS？

Scrapeless Agent Browser 运行浏览器会话，可以观察网站在浏览器跨源规则下的行为。

跨源资源共享（CORS）是一种HTTP头机制，允许服务器声明浏览器何时可以将响应暴露给在另一个源上运行的脚本。源是方案、主机和端口的组合。CORS 重要是因为从一个源加载的页面通常希望调用另一个源上的API；除非响应满足CORS规则，否则浏览器限制该读取。

CORS错误很容易被误读为网络中断或API身份验证问题。请求可能已经到达服务器，服务器可能已经返回数据，但浏览器拒绝将该数据提供给页面脚本。单独诊断浏览器决策和API的业务决策。

CORS适用的起源边界

只有当两个URL的方案、主机和端口匹配时，它们才共享一个源。将http更改为https、移动到子域或使用另一个端口会创建不同的源。页面可以进行一些跨源请求而无需获得对响应主体的访问。 MDN CORS指南 将其描述为针对脚本所做的跨源HTTP请求对同源策略的受控放宽。

服务器通过响应头与Access-Control-Allow-Origin等字段进行通信权限。浏览器将该值与请求页面的来源进行比较。浏览器是页面脚本的执行点。命令行客户端可以发送HTTP请求而不应用浏览器CORS规则，因此成功的命令行响应并不证明网页可以读取相同的资源。

CORS不是授权系统。服务器仍然必须对呼叫者进行身份验证并检查资源权限。授予一个源读取响应的权限与决定一个用户是否可以查看私有账户记录是不同的。将这些视为单独的控制并测试两者。宽松的CORS配置不能安全地替代服务器端访问检查。

简单请求和预检请求

对于某些跨源请求，浏览器发送实际请求，然后检查响应权限。其他请求需要预检：浏览器首先发送一个OPTIONS请求，以询问所提出的方法和头是否被允许。 预检定义 识别Origin和Access-Control-Request-Method字段，在需要时包括Access-Control-Request-Headers。

带有自定义授权头或未在安全列表中的内容类型的请求可以触发预检。如果预检失败，浏览器不会发送关联的实际请求。该差异在诊断中很重要。一个没有POST的应用程序服务器日志仍可能显示OPTIONS请求，一个只检查POST路由的开发者可能会错过拒绝点。

预检批准是针对请求的方法、头、源和资源规则的范围。它并不意味着后续的业务操作将成功。实际请求仍然可能对身份验证或验证失败。相反，预检失败并不是证据表明API拒绝了用户的数据；承载数据的请求可能从未到达应用程序。

凭据改变响应规则

跨源请求可以涉及cookie或其他浏览器管理的凭据。当页面期望一个有凭证的响应时，通配符Access-Control-Allow-Origin值是不够的。服务器必须识别一个允许的源并应用相关的凭证响应规则。 MDN凭证错误指南 解释了通配符和凭证组合失败的原因。

请求的凭证模式和cookie策略是独立的输入。即使CORS头看起来正确，浏览器可能会因其SameSite、Secure或域设置而省略cookie。身份验证错误可能会在CORS检查成功后出现。在开发工具中检查请求和响应，而不是更改CORS字段以补偿从未发送的cookie。

动态允许每个请求源而不进行验证可能会将敏感响应暴露给不可信的页面。对于需要凭证的数据，维持明确的源策略，并确保响应依赖于Origin时缓存适当变化。安全审核应包括实际的认证资源，而不仅仅是返回公共文本的测试端点。

如何诊断浏览器CORS失败

从页面源和最终目标源（包括重定向）开始。一个重定向到登录主机的请求可能需要与原始API URL不同的策略。在浏览器开发工具中，检查是否存在OPTIONS交换、实际请求（如果发送）和响应头。 CORS错误目录 将常见控制台消息映射到缺失或不兼容的响应字段。

失败的fetch调用可能仅向JavaScript暴露一个通用错误，而控制台包含具体的CORS原因。记录两个表面。检查响应是否缺少Access-Control-Allow-Origin、命名不同的源、遗漏允许的方法或头，或与凭证模式冲突。在您控制的服务器上进行一次配置更改，然后再次测试相同的页面和请求。

不要添加浏览器扩展或禁用安全检查作为生产修复。这种局部更改可能隐藏集成缺陷，同时让真实用户被阻塞。如果API是第三方且不允许您的页面源，请使用受支持的服务器端集成架构或要求提供者提供文档化的浏览器访问路径。

浏览器自动化和数据收集中的CORS

一个真实的浏览器会话在浏览器安全规则下执行页面脚本。 无痕代理浏览器 提供远程控制的浏览器执行，因此可以在该环境中观察到进行跨域请求的页面。 代理浏览器介绍 描述了浏览器产品。它不会将未授权的API响应变成已授权的响应。

服务器端数据请求具有不同的CORS边界：浏览器CORS不管理后端HTTP客户端。其他控制仍然适用，包括提供者凭据、目标权限和速率策略。当你需要测试或重现页面自己的行为时，选择浏览器。当任务是直接数据交换并且提供者支持时，选择文档化的服务器API。

相关的 浏览器网络检查指南 讨论观察页面使用的请求。观察并不意味着可以在其预期上下文之外使用私有端点。当查看浏览器跟踪时，专注于任务所需的公共或明确授权的数据，并将凭据保持在共享日志之外。

实用的CORS决策检查表

识别资源的拥有者和调用它的页面的来源。决定浏览器脚本是否确实需要读取响应。如果需要，配置资源服务器仅允许预期的来源、方法、标题和凭据行为。如果不需要，则将调用保持在受控后端上，浏览器无需直接访问第三方API。

测试生产中使用的确切方法和头部。没有自定义字段的GET请求可能有效，而带有授权头的JSON POST请求会触发预检。还要测试错误路径：带有正确CORS头的成功响应不足以在身份验证失败或重定向省略它们时有效。浏览器用户需要真实的失败以便于查看和诊断。

最后，在事件记录中分离三个观察结果：网络请求是否已发出、服务器是否接受了该操作，以及浏览器是否将响应暴露给页面脚本。这些答案可能不同。保持它们分开可以防止“通过削弱不相关的服务器授权”来“解决”浏览器策略问题。

结论

CORS允许资源服务器指定哪些其他来源可以从浏览器脚本中读取其响应。其效果取决于页面来源、请求形状、预检和凭据模式。诊断浏览器中的这些部分，同时保持身份验证和服务器端权限检查完好。