什么是 CORS？浏览器跨源访问解释
无抓取的通用抓取 API 检索允许的公共网页内容，并在 CORS 必须在实际响应中遵守时渲染 JavaScript。
简而言之
- CORS 有一个精确的协议角色。 跨源资源共享，或 CORS，是一种 HTTP 头部机制，允许服务器告诉浏览器哪些其他源可以通过脚本驱动请求读取响应。
- CORS 必须在正确的层级读取。 传输、表示、浏览器政策和应用程序授权仍然是独立的问题。
- 中介可以改变应用程序观察到的内容。 网关、缓存、浏览器默认设置和客户端库可以在源字节和解析数据之间增加处理。
- 验证需要内容证据。 单独的状态或字段并不能证明预期的公共表示到达。
- 安全性依赖于范围和验证。 协议语法从不授予访问资源或信任调用者提供的值的权限。
什么是 CORS？
跨源资源共享，或 CORS，是一种 HTTP 头部机制，允许服务器告诉浏览器哪些其他源可以通过脚本驱动请求读取响应。源由方案、主机和端口定义。CORS 放宽了浏览器的相同源策略以接受批准的响应；它不能验证用户、授权业务行为，或阻止非浏览器客户端发送 HTTP 请求。
有用的定义包括机制及其边界。CORS 影响交换的特定部分，而相邻的责任仍然与 HTTP、浏览器、所选传输、应用程序或服务器的数据模型相关。保持这些层级分开使错误报告可重现，并防止配置更改被误认为是访问控制决策。
对于 API 开发者，第一个问题是由谁创建值或行为。下一个问题是由谁解释它。最后一个问题是，什么可观察结果证明解释有效。这三个答案将术语转化为可测试的接口合同。
浏览器如何做出 CORS 决策
页面脚本调用 fetch 或 XMLHttpRequest 访问与页面源不同的 URL。浏览器添加一个 Origin 字段，用于标识调用者的源。对于某些请求，它直接发送实际请求；对其他请求，它首先发送一个 OPTIONS 预检，描述预期的方法和非安全列表字段。
服务器评估源并返回访问控制响应字段。Access-Control-Allow-Origin 指定允许的源，或者在符合条件的非凭证情况下使用通配符。其他字段可以允许方法、请求字段、凭证或页面脚本可能读取的选定响应字段。
浏览器将响应与请求上下文进行比较。如果策略不匹配，脚本无法读取受保护的响应，即使服务器可能已经处理了 HTTP 请求。这一区别解释了为什么控制台显示 CORS 错误，而服务器日志却显示有请求到达。
有凭证的请求有更严格的规则。通配符源不能与浏览器凭证一起使用，服务器必须明确允许凭证。Cookie SameSite 规则和应用程序授权仍然独立适用。
定义权限的 CORS 字段
以下术语区分通常合并为一个标签的组件。将它们视为参与者之间的接口，而不是网络跟踪中的装饰。
源
标识请求页面的方案、主机和端口；浏览器在相关的跨源请求中附加它。
Access-Control-Allow-Origin
指定可以读取该响应的脚本的源，或者在凭证规则允许的情况下使用通配符。
Access-Control-Allow-Methods
列出为预检请求上下文批准的方法。
Access-Control-Allow-Headers
列出服务器允许的非安全列表请求字段名称。
Access-Control-Allow-Credentials
在明确的源规则也通过时，允许浏览器凭证用于实际的跨源交换。
Access-Control-Expose-Headers
使选定的响应字段可供页面脚本读取，超出安全列表响应字段的范围。
为什么 CORS 在网络数据收集中重要
CORS 可以改变到达的字节，如何解释这些字节，或者浏览器代码是否可以观察到结果。收集工作流程应该在更改工具之前定位该影响。记录请求的 URL、最终 URL、响应状态、表示类型、相关协议字段以及一个预期的内容标记。该紧凑的记录区分出正确的页面与访问消息、同意屏幕、重定向目标、空的应用程序外壳或不兼容的编码。
当所需数据存在于开放的服务器渲染响应中时，直接 HTTP 是最简单的获取路径。当批准的内容依赖于 JavaScript 执行、浏览器管理的状态、导航或浏览器安全政策时，浏览器变得相关。这两条路径不应被强迫看起来完全相同：浏览器根据平台规则管理 cookies、压缩、重定向、CORS 和存储，而直接客户端则暴露一组不同的默认值。
会话连贯性在一个响应为下一个请求建立状态时显得重要。保持一个授权序列在一个有限的客户端上下文中，保留必要的区域设置和网络源，避免混合不相关工作的状态。代理更改网络源；它不复制头部、解码表示、执行脚本或授予对受限内容的访问。
解析仅在表示验证后开始。在提取字段之前，确认最终的主机、可用的规范身份、媒体类型、解码状态和所需的业务标识符。这个顺序防止解析器将错误文档变成看似技术上成功的空记录。
中介值得明确关注。内容分发网络可以选择编码变体，网关可以响应OPTIONS，缓存可以重用协商响应，而应用服务器可以设置Cookies或授权字段。仅比较应用代码与最终页面输出跳过了可能做出决定的层。
无刮痕的通用抓取API在团队需要管理允许的公共内容检索时是相关的，包括JavaScript渲染的页面。获取合同仍然应定义目标、允许的字段、预期的表示、接受标识符和停止条件。产品能力不能替代源条款、隐私审查或应用级验证。
与真实产品匹配的CORS配置
当CORS改变具体产品行为、兼容性要求或诊断决策时，CORS在架构中获得了一席之地。这些使用案例首先描述了工作，然后是协议特性。
公共读取API
当数据确实是公共的时，服务可以允许来自批准来源或所有来源的非凭证读取。
单页应用程序
API可以允许生产前端来源和选定的开发来源。
凭证账户API
明确的来源允许列表与凭证支持和服务器端授权配对。
暴露的响应元数据
服务器可以暴露如请求ID等有界字段，而无需暴露每个响应字段。
多租户前端
策略可以解析已注册的租户来源并拒绝反射的不可信值。
单独上传服务
预检可以批准专用上传来源的所需方法和内容字段。
CORS、同源策略、CSRF和身份验证
CORS属于HTTP的一个层，不应与相邻层混淆。一个健全的实现识别哪个组件选择了值，哪个组件可以更改它，以及什么证据证明最终表示是正确的。
| 维度 | CORS | 相关概念或替代方案 |
|---|---|---|
| 同源策略 | 浏览器安全基线 | 限制跨来源的脚本访问 |
| CORS | 服务器自愿读取权限 | 放宽选定的浏览器限制 |
| CSRF防御 | 保护状态更改操作 | 验证请求上下文和意图 |
| 身份验证 | 建立调用者身份 | 使用会话或凭证机制 |
| 授权 | 检查允许的操作 | 适用业务和资源规则 |
只有在保留层边界的情况下，比较才有用。两个机制可以在一个请求中共存，替换一个不会自动替换另一个。以输入、可观察输出、失败状态和所有权来记录所选择的行为。
CORS配置错误和虚假修复
- 反射每个Origin。 回声未验证的输入可以授予攻击者的来源浏览器读取访问权限。
- 使用带有凭证的通配符。 凭证浏览器请求需要明确的允许来源，而不是通配符权限。
- 将CORS视为身份验证。 CORS管理浏览器响应访问；服务器仍然必须对每个操作进行身份验证和授权。
- 仅在成功响应中添加标头。 错误和预检响应也需要浏览器暴露有用诊断所需的政策字段。
- 使用无跨域解决访问问题。 结果的不透明响应不是正常可读的API响应，并且不授予缺失的服务器权限。
- 忘记缓存变体。 动态源响应应考虑缓存行为中的来源，以便一个租户的权限不会提供给另一个租户。
在移除关于库或浏览器自动操作的假设后，大多数故障更容易诊断。捕获最小的痕迹，遮蔽秘密，并一次改变一个受控变量。目标是对返回表示的稳定解释，而不是一系列不相关的标头调整。
从页面到原点的CORS诊断
此序列作为启动前的设计审查和行为更改后的生产诊断。它将协议证据与应用程序结果保持连接。
- 将页面来源和目标来源记录为方案、主机和端口。
- 检查浏览器网络面板以确定失败的交换是预检还是实际请求。
- 检查响应中的Origin请求字段和确切的Access-Control-Allow-Origin值。
- 对于预检，将请求的方法和字段名称与服务器的允许列表进行比较。
- 针对凭据，分别验证显式的来源权限、凭据权限、cookie规则和应用程序授权。
- 检查重定向和网关响应，因为不同的层可能会省略所需字段。
- 在真实的浏览器上下文中进行验证；命令行的成功并不能证明浏览器政策通过。
通过保存一个小的接受样本和一个被拒绝的样本，并使用相同的遮蔽规则来完成审查。以后更改可以与已知页面身份、预期字段和解码内容进行比较，而不仅仅是记忆或截图。
CORS的安全性和可观测性
CORS参与一个可以跨越浏览器、网关、缓存和源服务器的请求路径。每个跃点应仅接受它理解的值，保留必须生存的字段，避免将凭据或个人数据复制到日志中。协议语法不是授权。
操作记录应捕获请求的URL、最终URL、状态、表示类型、相关字段名称和一个有限的内容标记。完整的主体和凭据值在常规诊断中很少需要，并且可能会造成不必要的保留风险。
浏览器行为和直接HTTP行为是不同的测试表面。CORS、cookie存储、自动解压缩和重定向处理可能会在应用程序代码看到结果之前由浏览器或库执行。在比较捕获时记录客户端及其默认值。
定义CORS的标准
提取标准CORS协议 定义当前浏览器CORS处理。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍然需要在所选客户端和部署中进行观察。
MDN的CORS指南 解释简单和预检交换。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍然需要在所选客户端和部署中进行观察。
网页来源规范 定义由网络安全使用的来源概念。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍然需要在所选客户端和部署中进行观察。
MDN的同源策略指南 描述了CORS可以放宽的浏览器边界。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍然需要在所选客户端和部署中进行观察。
正确的CORS思维模型
CORS是由服务器字段控制的浏览器强制响应读取权限；它补充身份验证、授权、cookie政策和请求伪造防御，而不是替代它们。
将该规则放入验收测试中。说明哪个参与者发送信号，哪个参与者解释信号，哪些中介可以更改路径，以及哪个内容标记证明成功。这使得CORS成为一个可观测系统的一部分，而不是在失败后附加的标签。
准备验证公共网络响应吗？
使用Scrapeless Universal Scraping API检索批准的公共内容，并检查本指南中描述的表示合同。
今天注册并获取 $5的免费积分 — 无信用卡要求.
领取您的$5信用→常见问题
CORS是否阻止请求到达服务器？
不一定。浏览器可以发送实际请求，然后阻止页面脚本读取响应。预检失败会阻止相关的实际请求发送。
CORS可以保护API免受命令行客户端的攻击吗？
不可以。CORS由网络浏览器强制执行。直接HTTP客户端可以发送请求，因此API必须自行强制实施身份验证、授权、验证和速率策略。
Access-Control-Allow-Origin可以设置为多个来源吗？
响应字段仅携带一个允许的来源值或一个合格的通配符，而不是用逗号分隔的允许列表。支持多个来源的服务器评估请求的Origin并返回匹配的批准值。
为什么请求在curl中成功，但在浏览器中失败？
命令行客户端不强制执行浏览器的同源策略。浏览器检查CORS字段，并在将响应暴露给脚本之前可能会发送预检。
启用CORS是否能防止CSRF？
不能。CORS控制浏览器脚本是否可以读取响应，而CSRF涉及使用用户权限发出的不必要的状态更改请求。使用专门的请求伪造防御和服务器授权。