一、chrome report-api
The Reporting API defines a new HTTP header, Report-To, that gives web developers a way to specify server endpoints for the browser to send warnings and errors to. Browser-generated warnings like CSP violations, Feature Policy violations, deprecations, browser interventions, and network errors are some of the things that can be collected using the Reporting API.
Browser-generated warnings in the DevTools console.
Introduction
Some errors only occur in production (aka The Wild). You never see them locally or during development because real users, real networks, and real devices change the game. Not to mention all the cross browser issues that get thrown into the mix.
As an example, say your new site relies on document.write() to load critical scripts. New users from different parts of the world will eventually find your site, but they're probably on much slower connections than you tested with. Unbeknownst to you, your site starts breaking for them because of Chrome's browser intervention for blocking document.write() on 2G networks. Yikes! Without the Reporting API there's no way to know this is happening to your precious users.
The Reporting API helps catch potential (even future) errors across your site. Setting it up gives you "peace of mind" that nothing terrible is happening when real users visit your site. If/when they do experience unforeseen errors, you'll be in the know. 👍
The Report-To Header
Right now, the API needs to be enabled using a runtime command line flag: --enable-features=Reporting.
The Reporting API introduces a new HTTP response header, Report-To. Its value is an object which describes an endpoint group for the browser to report errors to:
Report-To: {
"max_age": 10886400,
"endpoints": [{
"url": "https://analytics.provider.com/browser-errors"
}]
}
Note: If your endpoint URL lives on a different origin than your site, the endpoint should support CORs preflight requests. (e.g. Access-Control-Allow-Origin: *; Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS; Access-Control-Allow-Headers: Content-Type, Authorization, Content-Length, X-Requested-With
In the example, sending this response header with your main page configures the browser to report browser-generated warnings to the endpoint https://analytics.provider.com/browser-errors for max_age seconds. It's important to note that all subsequent HTTP requests made by the page (for images, scripts, etc.) are ignored. Configuration is setup during the response of the main page.
Configuring multiple endpoints
A single response can configure several endpoints at once by sending multiple Report-To headers:
Report-To: {
"group": "default",
"max_age": 10886400,
"endpoints": [{
"url": "https://example.com/browser-reports"
}]
}
Report-To: {
"group": "csp-endpoint",
"max_age": 10886400,
"endpoints": [{
"url": "https://example.com/csp-reports"
}]
}
or by combining them into a single HTTP header:
Report-To: {
"group": "csp-endpoint",
"max_age": 10886400,
"endpoints": [{
"url": "https://example.com/csp-reports"
}]
},
{
"group": "network-endpoint",
"max_age": 10886400,
"endpoints": [{
"url": "https://example.com/network-errors"
}]
},
{
"max_age": 10886400,
"endpoints": [{
"url": "https://example.com/browser-errors"
}]
}
Once you've sent the Report-To header, the browser caches the endpoints according to their max_age values, and sends all of those nasty console warnings/errors to your URLs. Boom!
<figcaption style="box-sizing: inherit; font-style: italic;">DevTools warnings and errors that can be sent using the Reporting API.</figcaption>
Explanation of header fields
Each endpoint configuration contains a group name, max_age, and endpoints array. You can also choose whether to consider subdomains when reporting errors by using the include_subdomains field.
| Field | Type | Description |
|---|---|---|
group |
string | Optional. If a group name is not specified, the endpoint is given a name of "default". |
max_<wbr style="box-sizing: inherit;">age |
number | Required. A non-negative integer that defines the lifetime of the endpoint in seconds. A value of "0" will cause the endpoint group to be removed from the user agent’s reporting cache. |
endpoints |
Array<Object> | Required. An array of JSON objects that specify the actual URL of your report collector. |
include_<wbr style="box-sizing: inherit;">subdomains |
boolean | Optional. A boolean that enables the endpoint group for all subdomains of the current origin's host. If omitted or anything other than "true", the subdomains are not reported to the endpoint. |
The group name is a unique name used to associate a string with an endpoint. Use this name in other places that integrate with the Reporting API to refer to a specific endpoint group.
The max-age field is also required and specifies how long the browser should use the endpoint and report errors to it.
The endpoints field is an array to provide failover and load balancing features. See the section on Failover and load balancing. It's important to note that the browser will select only one endpoint, even if the group lists several collectors in endpoints. If you want to send a report to several servers at once, your backend will need to forward the reports.
How the browser sends a report
Reports are delivered out-of-band from your app, meaning the browser controls when reports are sent to your server(s). The browser attempts to deliver queued reports as soon as they're ready (in order to provide timely feedback to the developer) but it can also delay delivery if it's busy processing higher priority work or the user is on a slow and/or congested network at the time. The browser may also prioritize sending reports about a particular origin first, if the user is a frequent visitor.
The browser periodically batches reports and sends them to the reporting endpoints that you configure. To send reports, the browser issues a POST request with Content-Type: application/reports+json and a body containing the array of warnings/errors which were captured.
Example - browser issues a POST request to your CSP errors endpoint:
POST /csp-reports HTTP/1.1 Host: example.comContent-Type: application/reports+json[{ "type": "csp", "age": 10, "url": "https://example.com/vulnerable-page/", "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0", "body": { "blocked": "https://evil.com/evil.js", "directive": "script-src", "policy": "script-src 'self'; object-src 'none'", "status": 200, "referrer": "https://evil.com/" }}, } ...}]
Report types discusses how to set up CSP reporting.
The Reporting API was designed to be out of band from your web app. The browser captures, queues and batches, then sends reports automatically at the most opportune time. Reports are sent internally by the browser, so there's little to no performance concern (e.g. network contention with your app) when using the Reporting API. There's also no way to control when the browser sends queued reports.
Debugging report configurations
If you don't see reports showing up on your server, head over to chrome://net-internals/#reporting. That page is useful for verifying things are configured correctly and reports are being sent out properly.
[图片上传中...(image-96bc93-1606110183912-0)]
Reporting section in chrome://net-internals/#reporting
Report types
The Reporting API can be used for more than just browser intervention and deprecation messages. In fact, it can be configured to send many other types of interesting warnings/issues that happen throughout your site:
- CSP violations
- Deprecations
- Browser interventions
- Feature Policy violations (in development)
- Network Error Logging (NEL)
- Crash reports
CSP reports
A long time ago, the web elders realized that sending client-side CSP violations to a backend would be pretty handy. If your site breaks because of some new powerful feature (i.e. CSP), you probably want to be notified! Thus, we've had a reporting mechanism for CSP from day one.
When a site violates a CSP rule, it can (optionally) tell the browser to send the error to a server. This is done by adding the report-uri directive in the CSP header:
Content-Security-Policy: ...; report-uri https://example.com/csp-reportsContent-Security-Policy-Report-Only: ...; report-uri https://example.com/csp-reports
The Reporting API integrates with CSP reports by adding a new report-to directive. Unlike report-uri which takes a URL, report-to takes an endpoint group name. It still has a URL, but that gets moved inside endpoints in the configuration object:
New
Content-Security-Policy-Report-Only: ...; report-to csp-endpointReport-To: { ... }, { "group": "csp-endpoint", "max_age": 10886400, "endpoints": [{ "url": "https://example.com/csp-reports" }] }
For backwards compatibility, continue to use report-uri along with report-to. In other words: Content-Security-Policy: ...; report-uri https://example.com/csp-reports; report-to groupname. Browsers that support report-to will use it instead of report-uri.
Network errors
The Network Error Logging (NEL) spec defines a mechanism for collecting client-side network errors from an origin. It uses the new NEL HTTP response header to setup to tell the browser collect network errors, then integrates with the Reporting API to report the errors to a server.
To use NEL, first setup the Report-To header with a collector that uses a named group:
Report-To: { ... }, { "group": "network-errors", "max_age": 2592000, "endpoints": [{ "url": "https://analytics.provider.com/networkerrors" }] }
Next, send the NEL response header to start collecting errors. Since NEL is opt-in for an origin, you only need to send the header once. Both NEL and Report-To will apply to future requests to the same origin and will continue to collect errors according to the max_age value that was used to set up the collector.
The header value should be a JSON object that contains a max_age and report_to field. Use the latter to reference the group name of your network errors collector:
GET /index.html HTTP/1.1NEL: {"report_to": "network-errors", "max_age": 2592000}
The Report-To header uses a hyphen. Here, report_to uses an underscore.
Sub-resources
NEL works across navigations and subresources fetches. But for subresources, there's an important point to highlight: the containing page has no visibility into the NEL reports about cross-origin requests that it makes. This means that if example.com loads foobar.com/cat.gif and that resource fails to load, foobar.com's NEL collector is notified, not example.com's. The rule of thumb is that NEL is reproducing server-side logs, just generated on the client. Since example.com has no visibility into foobar.com's server logs, it also has no visibility into its NEL reports.
Feature Policy violations
Currently, Feature Policy violations are not captured with the Reporting API. However, the plan is to integrate Feature Policy into the Reporting API.
Crash reports
Browser crash reports are also still in development but will eventually be capturable via the Reporting API.
Failover and load balancing
Most of the time you'll be configuring one URL collector per group. However, since reporting can generate a good deal of traffic, the spec includes failover and load-balancing features inspired by the DNS SRV record.
The browser will do its best to deliver a report to at most one endpoint in a group. Endpoints can be assigned a weight to distribute load, with each endpoint receiving a specified fraction of reporting traffic. Endpoints can also be assigned a priority to set up fallback collectors.
Example - creating a fallback collector at https://backup.com/reports.
Report-To: {
"group": "endpoint-1",
"max_age": 10886400,
"endpoints": [
{
"url": "https://example.com/reports",
"priority": 1
},
{
"url": "https://backup.com/reports",
"priority": 2
}
]
}
Fallback collectors are only tried when uploads to primary collectors fail.
Example server
HTTP examples are great. Actual code is even better.
To see all this stuff in context, below is an example Node server that uses Express and brings together all the pieces discussed in this article. It shows how to configure reporting for several different report types and create separate handlers to capture the results.
const express = require('express');
const app = express();
app.use(express.json({
type: ['application/json', 'application/csp-report','application/reports+json']
}));
app.use(express.urlencoded());
app.get('/', (request, response) => {
// Note: report-to replaces report-uri, but it is not supported yet.
response.set('Content-Security-Policy-Report-Only', `default-src 'self'; report-to csp-endpoint`);
// Note: report_to and not report-to for NEL.
response.set('NEL', `{"report_to": "network-errors", "max_age": 2592000}`);
// The Report-To header tells the browser where to send
// CSP violations, browser interventions, deprecations, and network errors.
// The default group (first example below) captures interventions and
// deprecation reports. Other groups are referenced by their "group" name.
response.set('Report-To', `
{
"max_age": 2592000,
"endpoints": [
{ "url": "https://reporting-observer-api-demo.glitch.me/reports" }
],
},
{
"group": "csp-endpoint",
"max_age": 2592000,
"endpoints": [
{
"url": "https://reporting-observer-api-demo.glitch.me/csp-reports"
}
]
},
{
"group": "network-errors",
"max_age": 2592000,
"endpoints": [
{
"url": "https://reporting-observer-api-demo.glitch.me/network-reports"
}
]
}`);
response.sendFile('./index.html');
});
function echoReports(request, response) {
// Record report in server logs or otherwise process results.
for (const report of request.body) {
console.log(report.body);
}
response.send(request.body);
}
app.post('/csp-reports', (request, response) => {
console.log(`${request.body.length} CSP violation reports:`);
echoReports(request, response);
});
app.post('/network-reports', (request, response) => {
console.log(`${request.body.length} Network error reports:`);
echoReports(request, response);
});
app.post('/reports', (request, response) => {
console.log(`${request.body.length} deprecation/intervention reports:`);
echoReports(request, response);
});
const listener = app.listen(process.env.PORT, () => {
console.log(`Your app is listening on port ${listener.address().port}`);
});
What about ReportingObserver?
Although both are part of the same Reporting API spec, ReportingObserver and the Report-To header have overlap with each other but enable slightly different uses cases.
ReportingObserver is a JavaScript API that can observe simple client-side warnings like deprecation and intervention. Reports are not automatically sent to a server (unless you choose to do so in the callback):
const observer = new ReportingObserver((reports, observer) => { for (const report of reports) { // Send report somewhere. }}, {buffered: true});observer.observe();
More sensitive types of errors like CSP violations and network errors cannot be observed by a ReportingObserver. Enter Report-To.
The Report-To header is more powerful in that it can capture more types of error reports (network, CSP, browser crashes) in addition to the ones supported in ReportingObserver. Use it when you want to automatically report errors to a server or capture errors that are otherwise impossible to see in JavaScript (network errors).
Conclusion
Although the Reporting API is a ways out from shipping in all browsers, it's a promising tool for diagnosing issues across your site.
Warnings that get logged to the DevTools console are super helpful but have limited value to you as the site author. That's because they're local to the user's browser! The Reporting API changes this. Use it to configure, detect, and report errors to a server even when your own code cannot. Propagate browser warnings to a backend, catch issues across your site before they grow out of control, and prevent future bugs before they happen (e.g. know about deprecated APIs ahead of their removal).
二、Making your website "cross-origin isolated" using COOP and COEP
Some web APIs increase the risk of side-channel attacks like Spectre. To mitigate that risk, browsers offer an opt-in-based isolated environment called cross-origin isolated. With a cross-origin isolated state, the webpage will be able to use privileged features including:
-
SharedArrayBuffer(required for WebAssembly Threads. This is available from Android Chrome 88. Desktop version is currently enabled by default with the help of Site Isolation, but will require the cross-origin isolated state and will be disabled by default.) -
performance.measureMemory()(Ends its origin trial and is planned to be enabled by default in Chrome 88) - JS Self-Profiling API (Not available yet in Chrome)
The cross-origin isolated state also prevents modifications of document.domain. (Being able to alter document.domain allows communication between same-site documents and has been considered a loophole in the same-origin policy.)
To opt in to a cross-origin isolated state, you need to send the following HTTP headers on the main document:
Cross-Origin-Embedder-Policy: require-corpCross-Origin-Opener-Policy: same-origin
These headers instruct the browser to block loading of resources or iframes which haven't opted into being loaded by cross-origin documents, and prevent cross-origin windows from directly interacting with your document. This also means those resources being loaded cross-origin require opt-ins.
You can determine whether a web page is in a cross-origin isolated state by examining self.crossOriginIsolated.
This article shows how to use these new headers. In a follow-up article I will provide more background and context.
This article is aimed at those who would like to get their websites ready for using SharedArrayBuffer, WebAssembly Threads, performance.measureMemory() or the JS Self-Profiling API in a more robust manner across browser platforms.
Key Term: This article uses many similar-sounding terminologies. To make things clearer, let's define them first:
- COEP: Cross Origin Embedder Policy
- COOP: Cross Origin Opener Policy
- CORP: Cross Origin Resource Policy
- CORS: Cross Origin Resource Sharing
- CORB: Cross Origin Read Blocking
Deploy COOP and COEP to make your website cross-origin isolated #
Integrate COOP and COEP #
1. Set the Cross-Origin-Opener-Policy: same-origin header on the top-level document #
By enabling COOP on a top-level document, windows with the same origin, and windows opened from the document, will have a separate browsing context group unless they are in the same origin with the same COOP setting. Thus, isolation is enforced for opened windows.
A browsing context group is a group of tabs, windows or iframes which share the same context. For example, if a website (https://a.example) opens a popup window (https://b.example), the opener window and the popup window share the same browsing context and they have access to each other via DOM APIs such as window.opener.
[图片上传失败...(image-dc3631-1606110132636)]
As of Chrome 83, dedicated DevTools support is not yet available for COOP. However, you can examine window.opener === null from the opened window, or openedWindow.closed === true from the opener window to determine if they are in separate browsing context groups.
Try it! See the impact of different COOP params.
2. Ensure resources have CORP or CORS enabled #
Make sure that all resources in the page are loaded with CORP or CORS HTTP headers. This step is required for step four, enabling COEP.
Here is what you need to do depending on the nature of the resource:
- If the resource is expected to be loaded only from the same origin, set the
Cross-Origin-Resource-Policy: same-originheader. - If the resource is expected to be loaded only from the same site but cross origin, set the
Cross-Origin-Resource-Policy: same-siteheader. - If the resource is loaded from cross origin(s) under your control, set the
Cross-Origin-Resource-Policy: cross-originheader if possible. - For cross origin resources that you have no control over:
- Use the
crossoriginattribute in the loading HTML tag if the resource is served with CORS. - Ask the owner of the resource to support either CORS or CORP.
- Use the
- For iframes, use CORP and COEP headers as follows:
Cross-Origin-Resource-Policy: same-originandCross-Origin-Embedder-Policy: require-corp.
Key Term: It's important that you understand the difference between "same-site" and "same-origin". Learn about the difference at Understanding same-site and same-origin.
3. Use the COEP Report-Only HTTP header to assess embedded resources #
Before fully enabling COEP, you can do a dry run by using the Cross-Origin-Embedder-Policy-Report-Only header to examine whether the policy actually works. You will receive reports without blocking embedded content. Recursively apply this to all documents. For information on the Report-Only HTTP header, see Observe issues using the Reporting API.
4. Enable COEP #
Once you've confirmed that everything works, and that all resources can be successfully loaded, apply the Cross-Origin-Embedder-Policy: require-corp HTTP header to all documents including those that are embedded via iframes.
Try it! See the impact of different COEP / CORP parameters.
Squoosh (an image optimization PWA) now uses COOP / COEP to gain access to Wasm Threads (and Shared Array Buffer) as well on Android Chrome.
Determine whether isolation succeeded with self.crossOriginIsolated #
The self.crossOriginIsolated property returns true when the web page is in a cross-origin isolated state and all resources and windows are isolated within the same browsing context group. You can use this API to determine whether you have successfully isolated the browsing context group and gained access to powerful features like performance.measureMemory().
Caution: The self.crossOriginIsolated property is available in Chrome from version 87.
Debug issues using Chrome DevTools #
For resources that are rendered on the screen such as images, it's fairly easy to detect COEP issues because the request will be blocked and the page will indicate a missing image. However, for resources that don't necessarily have a visual impact, such as scripts or styles, COEP issues might go unnoticed. For those, use the DevTools Network panel. If there's an issue with COEP, you should see (blocked:NotSameOriginAfterDefaultedToSameOriginByCoep) in the Status column.
[图片上传失败...(image-7a25f2-1606110132635)]
You can then click the entry to see more details.
[图片上传失败...(image-5fda03-1606110132635)]
While COEP debugging is already available, COOP debugging in Chrome DevTools is still being worked on.
Observe issues using the Reporting API #
The Reporting API is another mechanism through which you can detect various issues. You can configure the Reporting API to instruct your users' browser to send a report whenever COEP blocks the loading of a resource or COOP isolates a popup window. Chrome has supported the Report-To header since version 69 for a variety of uses including COEP and COOP.
The Reporting API is undergoing transition to a new version. Chrome is planning to release it soon, but will leave the older API in place for some time. Firefox is also considering the new API. You may want to use both APIs during the transition.
Enable the Reporting API #
You can try the COOP Reporting API in Chrome 86 and later by doing one of the following:
- Enabling Chrome flags
- Registering for an origin trial
Enable via Chrome flags #
- Go to
chrome://flags - Enable Cross Origin Opener Policy reporting (
chrome://flags/#cross-origin-opener-policy-reporting) - Enable Cross Origin Opener Policy access reporting (
chrome://flags/#cross-origin-opener-policy-access-reporting)
Register for an origin trial #
Origin trials allow you to try new features and give feedback on their usability, practicality, and effectiveness to the web standards community. For more information, see the Origin Trials Guide for Web Developers. To sign up for this or another origin trial, visit the registration page.
- Request a token for your origin.
- Add the token to your pages. There are two ways to do that:
- Add an
origin-trial<meta>tag to the head of each page. For example, this may look something like:
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> - If you can configure your server, you can also add the token using an
Origin-TrialHTTP header. The resulting response header should look something like:
Origin-Trial: TOKEN_GOES_HERE
- Add an
Caution: To use COOP Reporting API, the token must be served as an HTTP header instead of a <meta> tag.
Report-To #
To specify where the browser should send reports, append the Report-To HTTP header to any document that is served with a COEP or COOP HTTP header. The Report-To header also supports a few extra parameters to configure the reports. For example:
Report-To: { group: 'coep_report', max_age: 86400, endpoints: [{ url: 'https://first-party-test.glitch.me/report'}]},{ group: 'coop_report', max_age: 86400, endpoints: [{ url: 'https://first-party-test.glitch.me/report'}]}
The parameters object has three properties:
group #
The group property names your various reporting endpoints. Use these names to direct a subset of your reports. For instance, in the Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy directives you can specify the relevant endpoint by providing the group name to report-to=. For example:
Cross-Origin-Embedder-Policy: require-corp; report-to="coep_report"Cross-Origin-Opener-Policy: same-origin; report-to="coop_report"
When the browser encounters this, it will cross reference the report-to value with the group property on the Report-To header to look up the endpoint. This example cross references coep_report and coop_report to find the endpoint https://first-party-test.glitch.me/report.
If you prefer to receive reports without blocking any embedded content or without isolating a popup window, append -Report-Only to respective headers: i.e. Cross-Origin-Embedder-Policy-Report-Only and Cross-Origin-Opener-Policy-Report-Only. For example:
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep_report"Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop_report"
By doing this, when the browser detects cross origin resources that don't have CORP or CORS, it sends a report using the Reporting API without actually blocking those resources because of COEP.
Similarly, when the browser opens a cross-origin popup window, it sends a report without actually isolating the window because of COOP. It also reports when different browsing context groups try to access each other, but only in "report-only" mode.
max_age #
The max_age property specifies the time in seconds after which unsent reports are to be dropped. The browser doesn't send the reports right away. Instead, it transmits them out-of-band whenever there aren't any other higher priority tasks. The max_age prevents the browser from sending reports that are too stale to be useful. For example, max_age: 86400 means that reports older than twenty-four hours will not be sent.
endpoints #
The endpoints property specifies the URLs of one or more reporting endpoints. The endpoint must accept CORS if it's hosted on a different origin. The browser will send reports with a Content-Type of application/reports+json.
An example COEP report payload when cross-origin resource is blocked looks like this:
[{ "age": 25101, "body": { "blocked-url": "https://third-party-test.glitch.me/check.svg?", "blockedURL": "https://third-party-test.glitch.me/check.svg?", "destination": "image", "disposition": "enforce", "type": "corp" }, "type": "coep", "url": "https://first-party-test.glitch.me/?coep=require-corp&coop=same-origin&", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4249.0 Safari/537.36"}]
Caution: blocked-url is there for backward compatibility only and will be removed eventually.
An example COOP report payload when a popup window is opened isolated looks like this:
[{ "age": 7, "body": { "disposition": "enforce", "effectivePolicy": "same-origin", "nextResponseURL": "https://third-party-test.glitch.me/popup?report-only&coop=same-origin&", "type": "navigation-from-response" }, "type": "coop", "url": "https://first-party-test.glitch.me/coop?coop=same-origin&", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"}]
When different browsing context groups try to access each other (only on "report-only" mode), COOP also sends a report. For example, a report when postMessage() is attempted would look like this:
[{ "age": 51785, "body": { "columnNumber": 18, "disposition": "reporting", "effectivePolicy": "same-origin", "lineNumber": 83, "property": "postMessage", "sourceFile": "https://first-party-test.glitch.me/popup.js", "type": "access-from-coop-page-to-openee" }, "type": "coop", "url": "https://first-party-test.glitch.me/coop?report-only&coop=same-origin&", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"},{ "age": 51785, "body": { "disposition": "reporting", "effectivePolicy": "same-origin", "property": "postMessage", "type": "access-to-coop-page-from-openee" }, "type": "coop", "url": "https://first-party-test.glitch.me/coop?report-only&coop=same-origin&", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"}]
Conclusion #
Use a combination of COOP and COEP HTTP headers to opt a web page into a special cross-origin isolated state. You will be able to examine self.crossOriginIsolated to determine whether a web page is in a cross-origin isolated state.
In upcoming releases of Chrome, this cross-origin isolated state will prevent altering document.domain and will give access to powerful features such as:
We'll keep this post updated as new features are made available to this cross-origin isolated state, and further improvements are made to DevTools around COOP and COEP.
