共计 5353 个字符,预计需要花费 14 分钟才能阅读完成。
CORB 对图像的影响
CORB 对标签应该没有显著的影响<img>
,除非图像资源 1) 被谬误地标记为不正确的、非图像的、受 CORB 爱护的 Content-Type 和 2) 与响应标头一起提供X-Content-Type-Options: nosniff
。
例子:
正确标记的 HTML 文档
标签中应用的资源
<img>
:- 注释:一个 HTML 文档
Content-Type: text/html
- 没有
X-Content-Type-Options
题目
- 预期行为:无显著差别。当 1) 尝试将 html 文档出现为图像(没有 CORB)和 2) 尝试将空响应出现为图像(当 CORB 阻止响应时)时,出现的图像应该是雷同的损坏图像。
- WPT 测试:
fetch/corb/img-html-correctly-labeled.sub.html
谬误标记的图像(嗅探)
标签中应用的资源
<img>
:- 注释:图像
Content-Type: text/html
- 没有
X-Content-Type-Options
题目
- 预期行为:无差别 。CORB 将嗅探到响应主体实际上 不是 受 CORB 爱护的类型,因而将容许响应。
- WPT 测试:
fetch/corb/img-png-mislabeled-as-html.sub.html
谬误标记的图像(nosniff)
标签中应用的资源
<img>
:- 注释:图像
Content-Type: text/html
X-Content-Type-Options: nosniff
- 预期行为:可察看到的差别 。因为
nosniff
标头,CORB 将不得不依赖Content-Type
标头。因为此响应被谬误标记(注释是图像,但题目Content-Type
说它是 html 文档),CORB 将谬误地将响应分类为须要 CORB 爱护。 - WPT 测试:
fetch/corb/img-png-mislabeled-as-html-nosniff.tentative.sub.html
除了 HTML<img>
标记之外,下面的示例还实用于其余应用图像的网络性能 – 包含但不限于:
/favicon.ico
- SVG 的
<image>
, <link rel="preload" as="image" ...>
(参见 WPT 测试fetch/corb/preload-image-png-mislabeled-as-html-nosniff.tentative.sub.html
:)background-image
在样式表中- 将图像绘制到(可能被净化的)HTML 上
<canvas>
[lukasza@chromium.org] 晚期尝试阻止具备不兼容 MIME 类型的 nosniff 图像失败了。咱们认为 CORB 会更侥幸,因为它只会阻止 CORB 爱护的 MIME 类型的子集(例如,它不会
application/octet-stream
像 Firefox 谬误中援用的那样阻止)
CORB 对多媒体的影响
音频和视频资源应该会看到与图像相似的影响,只管 206 响应更有可能呈现在媒体上。
CORB 对脚本的影响
CORB 应该对标签没有显著的影响<script>
,除非将标有正确 MIME 类型的受 CORB 爱护的非 JavaScript 资源作为脚本加载 – 在这些状况下,资源通常会导致语法错误,但受 CORB 爱护响应的空主体不会导致谬误。
例子:
正确标记的 HTML 文档
标签中应用的资源
<script>
:- 注释:一个 HTML 文档
Content-Type: text/html
- 没有
X-Content-Type-Options
题目
- 预期行为:通过 GlobalEventHandlers.onerror可察看到的差别。大多数受 CORB 爱护的资源在解析为 JavaScript 时会导致语法错误。在 CORB 阻止响应后语法错误隐没,因为被阻止响应的空主体能够像 JavaScript 一样失常解析。
- WPT 测试:
fetch/corb/script-html-correctly-labeled.tentative.sub.html
[lukasza@chromium.org] 实践上,在 CORB 阻塞响应中应用非空响应可能会从新引入失落的语法错误。咱们没有走那条路,因为
- 应用非空响应将与 Fetch 标准的其余局部不统一(如不通明过滤响应)。
- 保留语法错误的存在可能须要更改 CORB 阻塞的响应主体的内容,具体取决于原始响应主体是否会导致语法错误。这会减少额定的复杂性,这对于 CORB 实现者和 Web 开发人员来说仿佛都是不可取的。
谬误标记的脚本(嗅探)
标签中应用的资源
<script>
:- 注释:适当的 JavaScript 脚本
Content-Type: text/html
- 没有
X-Content-Type-Options
题目
- 预期行为:无差别 。CORB 将嗅探到响应主体实际上 不是 受 CORB 爱护的类型,因而将容许响应。请留神,CORB 嗅探对于某些语法元素在 HTML 和 JavaScript 之间共享这一事实具备弹性(例如 comments)。
- WPT 测试:
fetch/corb/script-js-mislabeled-as-html.sub.html
谬误标记的脚本(nosniff)
标签中应用的资源
<script>
:- 注释:适当的 JavaScript 脚本
Content-Type: text/html
X-Content-Type-Options: nosniff
- 预期行为:无显著差别 。无论有没有 CORB,脚本都不会执行,因为当响应头响应的 MIME 类型(在示例中)不是 JavaScript MIME 类型
nosniff
时,响应将导致响应被阻塞(Fetch 标准要求此行为)。text/html
- WPT 测试:
fetch/corb/script-js-mislabeled-as-html-nosniff.sub.html
除了 HTML<script>
标记之外,下面的示例还实用于其余应用 JavaScript 的网络性能,包含相似脚本的指标,如 importScripts()
、navigator.serviceWorker.register()
、audioWorklet.addModule()
等。
CORB 对样式表的影响
CORB 对样式表应该没有显著的影响。
例子:
任何未标记为文本 /css 的内容
标签中应用的资源示例
<link rel="stylesheet" href="...">
:- 注释:一个 HTML 文档或一个简略无效的样式表或一个多语言 HTML/CSS 样式表
Content-Type: text/html
- 没有
X-Content-Type-Options
题目
- 预期行为:无显著差别 。即便没有 CORB,这样的款式示意例也会被回绝,因为因为 CSS 宽松的语法规定,跨源 CSS 须要正确的 Content-Type 标头(限度因浏览器而异:IE.aspx)、Firefox、Chrome、Safari(向下滚动到 CVE -2010-0051) 和歌剧)。此行为蕴含在 HTML 标准
text/css
中,其中 1) 如果嵌入样式表的文档已设置为怪癖模式并且具备雷同的起源,则仅要求采纳 Content-Type,并且 2) 仅要求运行创立 CSS 样式表的步骤如果获取的资源的 Content-Type 是text/css
. - WPT 测试:
fetch/corb/style-css-mislabeled-as-html.sub.html
,fetch/corb/style-html-correctly-labeled.sub.html
任何未标记为文本 /css 的内容(nosniff)
标签中应用的资源
<link rel="stylesheet" href="...">
:- 注释:一个简略的样式表
Content-Type: text/html
X-Content-Type-Options: nosniff
- 预期行为:无显著差别 。应用和不应用 CORB,样式表都不会加载,因为响应标头响应将导致响应在其 MIME 类型(在示例中)不是(Fetch 标准要求此行为)
nosniff
时被阻止。text/html
`text/css` - WPT 测试:
fetch/corb/style-css-mislabeled-as-html-nosniff.sub.html
带有 JSON 平安前缀的正确标记的样式表
标签中应用的资源
<link rel="stylesheet" href="...">
:- 注释:以 JSON 平安前缀结尾的样式表
Content-Type: text/css
- 没有
X-Content-Type-Options
题目
- 预期行为:没有区别,因为对于标记为 的响应,不会执行 CORB 嗅探 JSON 平安前缀
Content-Type: text/css
。 - WPT 测试:
fetch/corb/style-css-with-json-parser-breaker.sub.html
CORB 对其余网络平台性能的影响
CORB 对以下场景没有影响:
XHR 和 fetch()
- CORB 没有显著的影响,因为 XHR 和 fetch()曾经对响应利用了同源策略(例如,CORB 应该只阻止因为短少 CORS 而导致跨源 XHR 谬误的响应)。
预取
- CORB 阻止响应主体达到跨源渲染器,但 CORB 不会阻止响应主体被浏览器过程缓存(并随后传递到另一个同源渲染器过程)。
跟踪和报告
- 各种技术试图通过触发对记录用户拜访的 HTTP 服务器的 Web 申请来检查用户是否拜访了某些内容。Web 申请常常由
img
HTTP URI 的不可见元素触发,通常应用 204 或简短的 HTML 文档进行回复。除了img
标签之外,网站还能够应用style
和script
其余标签来跟踪应用状况。 - CORB 不会影响这些技术,因为它们不依赖于 HTTP 服务器返回的理论内容。这也实用于其余不关怀响应的网络性能:信标、ping、CSP 违规报告等。
- 各种技术试图通过触发对记录用户拜访的 HTTP 服务器的 Web 申请来检查用户是否拜访了某些内容。Web 申请常常由
服务人员
- Service Worker 能够拦挡跨域申请并在 Service Worker中 人为地构建响应(即不跨域和 / 或平安边界)。CORB 不会阻止此类响应。
- 当 service worker 缓存理论的跨源响应时(例如,在“no-cors”申请模式下),响应是“不通明的”,因而 CORB 能够在不扭转 service worker 的行为的状况下阻止此类响应(“不通明”响应具备不可拜访的体甚至没有 CORB)。
Blob 和文件 API
- 即便没有 CORB,获取跨源 blob URL 也会被阻止(请参阅 https://github.com/whatwg/fetch/issues/666)。
- WPT 测试:(
script-html-via-cross-origin-blob-url.sub.html
以及此处提交所涵盖的导航申请测试)。
内容脚本和插件
- CORB 不包含这些——CORB 假设适当的安全策略由内容脚本和插件的某些其余机制强制执行(例如,Adobe Flash 通过 crossdomain.xml 实现相似 CORS 的机制)。
量化 CORB 对现有网站的影响
CORB 已在可选的站点隔离模式和现场试验中启用,并且 Chromium 已被用来计算有多少合乎 CORB 条件的响应被阻止。(合乎 CORB 条件的响应不包含导航申请和下载;请参阅上文“哪些类型的申请合乎 CORB 条件?”局部。)咱们对 2018 年 2 月 Chrome Canary 的初始数据的剖析显示案例数量的下限较低对网页可见,并有可能进一步升高界线。
总体而言,所有合乎 CORB 条件的响应中有 0.961% 被阻止。 然而,其中超过一半曾经是空响应(即,实际上有一个 Content-Length: 0
响应标头),因而实际上不会导致行为扭转(即,只有非平安列表的标头会受到影响)。请留神,如果省略嗅探,简直 20% 的响应将被阻止,因而嗅探显然是必要的。
仔细观察,所有合乎 CORB 条件的响应中有 0.456% 是非空和阻塞的。 然而,这些状况中的大多数都属于下面大节中形容的不可察看的类别,例如将 HTML 响应作为跟踪像素传递给图像标签。
咱们能够关注两组可能具备显著影响的碰壁响应。
因为 nosniff 标头或范畴申请,0.115% 的合乎 CORB 条件的响应可能已被显著阻止。
这特定于状态代码不是 204 的非空响应,申请的上下文不会以其余形式疏忽谬误标记的 nosniff 内容(例如,作为脚本标签)。在这个组内:
- 其中 95.16% 是标记为图像标签申请的 HTML 的 nosniff 响应。这些被屏蔽并且可能蕴含实在图像。然而,咱们预计其中许多案例实际上蕴含 HTML,并且无论如何都不会在图像标签中出现(正如咱们在一个案例中察看到的那样)。
[creis@chromium.org] 咱们正在思考通过嗅探这些响应来进一步升高这个界线,以确认有多少可能蕴含理论图像。
- 另外 3.76% 是来自媒体上下文的文本 / 纯文本范畴申请。咱们尚未在实践中找到示例,但咱们正在思考容许对 text/plain 的范畴申请响应以防止此处中断。
- 所有合乎 CORB 条件的响应中有 0.014% 是对脚本标签的有效输出,因为 CORB 嗅探显示它们是 HTML、XML 或 JSON。同样,这特定于没有 204 状态代码的非空响应。这些案例在实践中应该具备最小的中断危险(例如,超过一半具备谬误状态代码并且可能示意断开的链接),但在技术上能够依据是否报告语法错误来察看差别。
这些受影响案例的数量非常少,表明从 Web 兼容性的角度来看,CORB 很有前途。