web resource
Composability is a very powerful capability of the Web, you can easily load resources from different sources to enhance the functionality of a Web page, such as: font
、image
、video
and so on.
These services are very powerful and convenient, but such a strategy also increases the risk of information leakage, and attackers can use certain means to leak your user information.
Browsers also do a good job of blocking these attacks. We are already familiar with the same-origin policy, which is used to restrict resource access for sites of different origins. For details, you can poke the browser's same-origin policy, and I won't introduce it too much here.
But there are some exceptions to the same-origin policy, any website can load the following resources without restriction:
- Embed cross domain
iframe
image、script
and other resources- Open a cross-domain popup using the DOM
For these resources, the browser can separate the cross-domain resources of each site Context Group
under different , Context Group
and the resources under different s cannot access each other.
A browser Context Group
is a group of tabs, windows or iframes that share the same context. For example, if a website ( https://a.example
) opens a popup ( https://b.example
), the opener window and the popup share the same browsing context, and they can access DOM API
each other , eg window.opener
.
Spectre Vulnerability
For a long time, these security policies have protected the private data of the website until the Spectre
breach .
Spectre
It is CPU
a vulnerability discovered in . By exploiting Spectre
it, an attacker can read any resources Context Group
under .
Especially when using something that needs to interact API
with :
SharedArrayBuffer (required for WebAssembly Threads)
performance.measureMemory()
JS Self-Profiling API
For this reason, the browser once disabled SharedArrayBuffer
high -risk such as API
.
Cross-domain isolation
In order to be able to use these powerful functions and ensure our website resources are more secure, we need to create a cross-domain isolation environment for browsers.
A lot of terminology will be mentioned below, let's list all cross-domain related terms first to prevent confusion later:
COEP: Cross Origin Embedder Policy
: Cross-Origin Embedder PolicyCOOP: Cross Origin Opener Policy
: Cross-Origin Opener PolicyCORP: Cross Origin Resource Policy
: Cross-Origin Resource PolicyCORS: Cross Origin Resource Sharing
: Cross-Origin Resource SharingCORB: Cross Origin Read Blocking
: cross-origin read blocking
We COOP、COEP
can create an isolated environment with .
Cross-Origin-Embedder-Policy: require-corpCross-Origin-Opener-Policy: same-origin
Let's take a look at Hedaer
the and how to configure them.
COOP: Cross Origin Resource Policy
COOP: Cross-Origin Opener Policy, corresponding HTTP Header
to Cross-Origin-Opener-Policy
.
By COOP
setting to Cross-Origin-Opener-Policy: same-origin
, other windows opened from this website from different sources will be isolated in different browsers Context Group
, thus creating an isolated environment for resources.
For example, if COOP
a site with opens a new cross-domain popup page, its window.opener
property will be null
.
Besides same-origin
, COOP
there are two other different values:
Cross-Origin-Opener-Policy: same-origin-allow-popups
same-origin-allow-popups
Top-level pages with will keep references to popups that are either left unset or opted out of isolation COOP
by COOP
setting to .unsafe-none
Cross-Origin-Opener-Policy: unsafe-none
unsafe-none
is the default setting, allowing current page and popup page sharing Context Group
.
CORP, CORS
To enable cross-origin isolation, you also first need to make sure that all cross-origin resources are explicitly allowed to load. There are two implementations of this, one is CORP
and the other is CORS
.
CORS
(Cross-domain resource sharing) It is often used when we solve cross-domain problems on a daily basis. We are already very familiar with this. Let's take a look CORP
:
Cross-Origin-Resource-Policy: same-site
Resources marked same-site
with can only be loaded from the same site.
Cross-Origin-Resource-Policy: same-origin
Resources marked same-origin
with can only be loaded from the same origin.
Cross-Origin-Resource-Policy: cross-origin
cross-origin
Tagged resources can be loaded by any website.
Note that if it is some general CDN
resources , such as image、font、video
, etc., it must be set to cross-origin
, otherwise, the resources may not be loaded normally.
For cross-origin resources that you can't control, you can manually add the
crossorigin
attribute .
COEP: Cross Origin Embedder Policy
COOP: Cross-Origin Embedding Program Policy, corresponding to HTTP Header
is Cross-Origin-Embedder -Policy
.
Enable Cross-Origin-Embedder-Policy: require-corp
, you can have your site load only cross-origin resources that are explicitly marked as shareable, which is the configuration we just mentioned above, or same-origin resources.
For example, the image resource above Cross-Origin-Resource-Policy
will .
COEP
Before fully enabling , you can Cross-Origin-Embedder-Policy-Report-Only
check if the policy is working properly by using . If there are any non-compliant resources, they will not be prohibited from loading, but will be reported to your server log.
Test whether cross-domain isolation is normal
After COOP、COEP
your configuration is complete, your site should now be in a cross-domain isolation state. You can use self.crossOriginIsolated
to determine whether the isolation state is normal.
if(self.crossOriginIsolated){ // 跨域隔离成功}
Well, you can now happily use haredArrayBuffer
, performance.measureMemory
or JS Self-Profiling API
these powerful APIs~