CORP与CORS的核心区别是什么？相关认知误区有哪些

你的认知存在两处关键错误：

1. 两个机制的默认规则、拦截逻辑完全不同，并非统一的“服务端声明不允许就拦截跨源交付”：CORS的默认拦截逻辑是浏览器默认禁止跨源脚本读取跨源响应内容，哪怕服务端不返回任何CORS相关头，跨源请求往往已经正常发送、服务端也完成了响应，只是浏览器会拦截前端脚本对响应内容的读取权限；而CORP是默认放行所有跨源资源加载，只有服务端显式返回限制头时，浏览器才会直接阻断跨源资源的加载流程。
2. 两个机制的拦截粒度不同：CORS不会拦截浏览器自身对跨源资源的基础加载使用（比如通过img、script标签加载的资源默认可以正常渲染、执行），仅管控脚本对响应内容的读取权限；而CORP的拦截是更底层的，只要不符合规则，浏览器根本不会把资源交给当前页面的上下文使用，不存在“能渲染但不能读”的情况。

• 管控目标不同
  CORS是同源策略的「授权放行机制」：它解决的是“跨源请求的响应能不能被发起请求的前端脚本读取”的问题，本质是给服务端开放跨源权限的通道——默认跨源脚本读不到响应，服务端如果明确允许某个源跨源访问，就可以通过CORS头放行，让合法的跨源接口调用能正常拿到结果。
  CORP是资源加载的「限制阻断机制」：它解决的是“当前资源能不能被跨源页面加载进自己的上下文”的问题，本质是给资源加加载权限锁——默认所有源都能加载该资源，服务端如果不希望资源被跨源嵌入，就可以通过CORP头阻断不符合规则的加载请求。
• 拦截阶段不同
  CORS的拦截发生在响应返回之后：对于简单请求，浏览器会直接发送真实请求，拿到响应后检查CORS头，如果不符合规则就扣下响应，不让前端脚本读取，但请求本身已经到达服务端，服务端侧的逻辑（比如数据修改、状态更新）已经执行完成；对于复杂请求，浏览器会先发OPTIONS预检请求，确认服务端允许跨源后再发送真实请求。
  CORP的拦截发生在资源加载阶段：只要跨源加载的请求不符合CORP规则，浏览器直接拒绝加载该资源，不会让资源内容进入当前页面的进程，不管你是用标签嵌入还是用API请求。
• 依赖的响应头与配置逻辑不同
  CORS的核心响应头包括Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Credentials等，配置时需要明确指定放行的源、允许的请求方法、是否允许携带凭证等，默认无任何CORS头时等价于“禁止所有跨源脚本读取响应”。
  CORP仅依赖Cross-Origin-Resource-Policy这一个响应头，可选值为same-origin（仅允许同域加载）、same-site（仅允许同站加载）、cross-origin（允许任意跨源加载），默认无该头时等价于“允许任意源加载资源”。
• 防护的风险场景不同
  CORS主要用于防止跨站数据窃取：比如用户登录了邮箱站点，恶意站点通过JS发起跨源请求读取用户的邮件内容，CORS会拦截JS对该响应的读取，避免敏感数据泄露。
  CORP主要用于防护跨源侧信道攻击（比如基于CPU缓存的Spectre类攻击），是实现跨源隔离的必要配置之一，同时也可以避免站点的私有资源（比如用户隐私图片、内部文档）被第三方站点恶意嵌入展示。

举个直观的例子：你在A站通过<img>标签引用B站的图片，如果B站没配CORS头，图片可以在A站正常显示，只是你如果用Canvas API读取图片像素数据会被CORS拦截；如果B站给图片返回了Cross-Origin-Resource-Policy: same-origin头，A站的<img>标签根本加载不出这张图，直接报资源加载错误。

内容的提问来源于stack exchange，提问作者u936293