tree: 2e0da3493a2c239cb3d15e43adb2e629375ffc09 [path history] [tgz]
  1. resources/
  2. img-html-correctly-labeled.sub-expected.html
  3. img-html-correctly-labeled.sub.html
  4. img-png-mislabeled-as-html-nosniff.tentative.sub-expected.html
  5. img-png-mislabeled-as-html-nosniff.tentative.sub.html
  6. img-png-mislabeled-as-html.sub-expected.html
  7. img-png-mislabeled-as-html.sub.html
  8. README.md
  9. script-html-correctly-labeled.tentative.sub.html
  10. script-html-via-cross-origin-blob-url.sub.html
  11. script-js-mislabeled-as-html-nosniff.sub.html
  12. script-js-mislabeled-as-html.sub.html
  13. style-css-mislabeled-as-html-nosniff.sub.html
  14. style-css-mislabeled-as-html.sub.html
  15. style-css-with-json-parser-breaker.sub.html
  16. style-html-correctly-labeled.sub.html
fetch/corb/README.md

Tests related to Cross-Origin Resource Blocking (CORB).

Summary

This directory contains tests related to the Cross-Origin Resource Blocking (CORB) algorithm.

The tests in this directory interact with various, random features, but the tests have been grouped together into the fetch/corb directory, because all of these tests verify behavior that is important to the CORB algorithm.

Disclaimer: CORB is not standardized yet

Note that CORB is currently in very early stages of standardization path. At the same time, some tests in this directory (e.g. css-with-json-parser-breaker) cover behavior spec-ed outside of CORB (making sure that CORB doesn‘t change the existing web behavior) and therefore are valuable independently from CORB’s standardization efforts.

Tests that cover behavior that is changed by CORB have to be marked as tentative (using .tentative substring in their filename) until CORB is included in the official Fetch spec. Such tests may fail unless CORB is enabled. In practice this means that:

  • Such tests will fail in default Chromium and have to be listed in third_party/WebKit/LayoutTests/TestExpectations and associated with https://crbug.com/802835.
  • Such tests will pass in Chromium when either
    1. CORB is explicitly, manually enabled by passing extra cmdline flags to run-webkit-tests: --additional-driver-flag=--enable-features=CrossSiteDocumentBlockingAlways and --additional-expectations=third_party/WebKit/LayoutTests/FlagExpectations/site-per-process.
    2. CORB is implicitly enabled via Site Isolation (e.g. in site_per_process_webkit_layout_tests step on the test bots). The expectations that the tests pass in this mode is controlled by the third_party/WebKit/LayoutTests/FlagExpectations/site-per-process file.
  • Such tests may fail in other browsers.

Limitations of WPT test coverage

CORB is a defense-in-depth and in general should not cause changes in behavior that can be observed by web features or by end users. This makes CORB difficult or even impossible to test via WPT.

WPT tests can cover the following:

  • Helping verify CORB has no observable impact in specific scenarios. Examples:
    • image rendering of (an empty response of) a html document blocked by CORB should be indistinguishable from rendering such html document without CORB - img-html-correctly-labeled.sub.html
    • CORB shouldn‘t block responses that don’t sniff as a CORB-protected document type - img-png-mislabeled-as-html.sub.html
  • Helping document cases where CORB causes observable changes in behavior. Examples:
    • blocking of nosniff images labeled as non-image, CORB-protected Content-Type - img-png-mislabeled-as-html-nosniff.tentative.sub.html
    • blocking of CORB-protected documents can prevent triggering syntax errors in scripts - script-html-via-cross-origin-blob-url.tentative.sub.html

Examples of aspects that WPT tests cannot cover (these aspects have to be covered in other, browser-specific tests):

  • Verifying that CORB doesn't affect things that are only indirectly observable by the web (like prefetch.
  • Verifying that CORB strips non-safe-listed headers of blocked responses.
  • Verifying that CORB blocks responses before they reach the process hosting a cross-origin execution context.