corp（cross-origin resource policy）是服务器通过http响应头cross-origin-resource-policy声明的资源加载策略，html中任何标签或属性（包括crossorigin）均无法设置；其值仅支持same-origin、same-site、cross-origin，用于限制跨源嵌入而非读取，拦截发生在请求发起前，与cors独立且更严格。
HTML 本身不能设置 CORP，必须靠 HTTP 响应头
CORP（Cross-Origin Resource Policy）是服务器端策略，Access-Control-Allow-Origin 是 CORS 的响应头，而 Cross-Origin-Resource-Policy 才是 CORP 的响应头。HTML 中任何 <meta> 标签、<script></script> 或属性（比如 crossorigin）都**无法声明或启用 CORP**。浏览器只在收到 HTTP 响应时检查该 header，且只作用于整个资源响应——不是页面里某张图或某个 script，而是这个 URL 返回的内容本身是否允许被其他源加载。
什么时候需要配 CORP，而不是 CORS？
CORP 和 CORS 解决的是相反方向的问题：
- CORS 是“我（服务端）允许别人跨域读我”；
- CORP 是“我不允许别人跨域加载我”，用于防御侧信道攻击（如 Spectre）、CSRF 驱动的资源泄露等。
典型适用场景包括：
- 私有 API 接口（如
/api/user/profile），不希望被第三方网站用<img src="https://yoursite.com/api/...?x-oss-process=image/resize,p_40">或<script src="..."></script>意外加载； - 敏感静态资源（如用户上传的 PDF、内部文档 HTML）托管在 CDN 上，需防止被嵌入恶意页面后读取内容；
- 你用
fetch()请求自己域名下的接口，但不希望它被<iframe src="https://evil.com"></iframe>嵌套后通过 timing attack 推断状态。
三种 CORP 值的实际效果与配置陷阱
Cross-Origin-Resource-Policy 只接受三个合法值：same-origin、same-site、cross-origin。它们不是“开关”，而是严格匹配规则：
-
same-origin：仅同协议+同域名+同端口可加载。例如https://a.com:443能加载，https://a.com:8080或http://a.com都不行； -
same-site：允许同注册域（eTLD+1）下的所有子域，如a.com下的api.a.com、admin.a.com可互加载，但b.com不行； -
cross-origin：等价于不设该 header，即完全放开——极少使用，基本只用于调试或公开开放资源。
常见错误：
- 写成
Cross-Origin-Resource-Policy: allow-from https://trusted.com→ 浏览器直接忽略，这不是 CORP 的语法； - 在 Nginx 中漏写引号导致值被截断：
add_header Cross-Origin-Resource-Policy same-origin;正确，但若写成add_header Cross-Origin-Resource-Policy same-origin no-cache;就会把值解析为same-origin后多出无效指令； - 对 HTML 页面设了
same-origin，但页面内又引用了同域下带 hash 的 JS（如app.js?v=123），只要 URL 不同，就仍算不同资源，需确保所有变体都返回一致 header。
如何验证 CORP 是否生效
不能只看 Network 面板里有没有这个 header——要观察浏览器是否真正拦截了跨源加载行为：
- 在 Chrome DevTools 的 Console 中，尝试用
<img src="https://your-api.com/private.jpg?x-oss-process=image/resize,p_40">加载一个被设为same-origin的资源，如果来自不同源，控制台会输出类似：Failed to load resource: Origin https://attacker.com is not allowed by Cross-Origin-Resource-Policy. - 用
curl -I https://yoursite.com/secret.json确认响应头中存在Cross-Origin-Resource-Policy: same-origin； - 注意：CORP 不影响
fetch()或XMLHttpRequest的 CORS 校验逻辑，它只影响“被动加载”行为（<img>、<script></script>、<link rel="stylesheet">、<iframe></iframe>、<object></object>等）； - 若同时配置了 CORS 和 CORP，两者独立判断：CORS 决定“能否读响应体”，CORP 决定“能否发起加载请求”。CORP 拦截更早，发生在请求发出前（部分浏览器甚至不发请求）。
CORP 的关键点在于：它不依赖前端代码，也不和 crossorigin 属性联动；一旦服务端响应带上该 header，浏览器就会按策略硬性执行，没有例外，也没有 fallback。配错值或漏配，可能直接导致合法子域功能异常，这点比 CORS 更“一刀切”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
