Enable and debug cross-origin isolated
Dec 15, 2020 23:18 · 1390 words · 7 minute read
(upbeat music) - Hi, my name is Camille, and I’m a Software Engineer on the Chrome Open Web Platform Security team. And today, I’m going to walk you through enabling crossOriginIsolated on your website. By enabling crossOriginIsolated on your website, you will get access to powerful web APIs like SharedArrayBuffers on Android, or performance.memory. You will also protect your application against cross-origin attacks. So crossOriginIsolated is a new security feature that provides increased isolation from other origins and that is stricter than same-site isolation on the cross-origin policy.
00:41 - Let’s get started with what crossOriginIsolated is and how you enable it on a website. So crossOriginIsolated is a result of sending two HTTP headers on your top-level document. These headers are the Cross-Origin-Opener-Policy, COOP, and Cross-Origin-Embedder-Policy, COEP. To enable CrossOriginIsolated, you need to send a Cross-Origin-Opener-Policy header, with the value of same-origin, with your top level document. You also need to send a Cross-Origin-Embedder-Policy header, with the value of require-corp, with each of the frames in your page.
01:13 - So what do those headers do? COOP, isolates your page from other cross-origin pages. So for example, any cross-origin pop up you open, will not be able to directly interact with your document or send it messages. You will see the pop up window is closed, and similarly the pop up, will see it’s open or closed. This protects against data leak attacks like Spectre because the browser can put your page in a secure environment with only pages that share the same top-level origin. COEP ensures that every service which you load on your page is same origin with you, or it agrees to be loaded same origin.
01:48 - Some resources agree to be loaded same origin by either having a CORS header, or having a CORP header with value cross-origin. Without this, the service source will be blocked. So when you set COOP to same origin, and COEP to require CORP, your page becomes CrossOriginIsolated. You can correct this by checking the result of self.CrossOriginIsolated. So starting in Chrome 88, this will allow you to use SharedArrayBuffers on Android as shown in this example.
02:16 - So this is a brief overview of what COOP, COEP and CrossOriginIsolated do, and if you want to know more, you should follow these links on the slide. As you have noticed, COOP and COEP impact how a web page works. So, if you’ve just set the headers on the page, it’s likely that your page will not work as it used to. To help you debug the issues coming from deploying COOP and COEP, we have new DevTools functionalities that are coming in Chrome 88. So let’s have a look at those. First, you may want to check the CrossOriginIsolated stages off your page.
02:50 - In the application panel of DevTools, you can check the security and isolation status of your top-level frame. And there, you can see that the page is CrossOriginIsolated. You can also check the COOP and COEP stages of the page. Here, both are enabled, so my page is CrossOriginIsolated. Note that because I have both, my COOP status is not same origin, but same origin plus COEP. Let’s look at COEP support in more details. So first let me open the cross-origin pop up. I can see the pop up I have created in DevTools. And if I click on it, I see it doesn’t have access to its opener. This is because the opener is our main page with COOP and it is cross origin with the pop up.
03:29 - So due to COOP, the main page and the pop up it open don’t have access to each other, okay? So let’s try opening the same-origin pop up then. And DevTools is telling me that I still don’t have access to it. This is because I haven’t set the COOP and COEP headers on the pop up. So, let me do that right now, and up in the new pop-up was the right headers. And as you can see, this pop up has access to its opener. And its icon is also different from the other pop ups who could not access the COEP page. Now, let’s look at support for COEP. If I look at the Issue tab, I can see that four service resource loads were blocked. As explained in the Issue tab, those resources to not have a CORP header, so they won’t be loaded by a cross-origin COEP page. And I can click on the specific resources to get more details about the network load. So beyond support in DevTools, we have also been working at reporting API for COOP and COEP.
04:28 - With reporting, you can get production reports on what needs to be changed to support COOP and COEP. If you’re familiar with CSP reporting, this should be fairly similar as we are using the same underlying reporting API. To enable reporting, just provide an endpoint in your Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy reports. This is where the reports will be sent. Note that for COOP, the reporting API is still in an origin trial so you really need to either subscribed to the origin trial or enable the reporting API through Chrome plugs. We also provide a report on the mode for COOP and COEP.
05:04 - So when you enable reports only, the browser won’t enforce the policies. Instead, it will send you reports when it detects that something would break if it had enforced the policies you specified. To enable report-only mode for either COOP or COEP, you need to use different headers with your documents. So these are the Cross-Origin-Opener-Policy report-only header, and Cross-Origin-Embedder-Policy report-only header. In those headers, you will also specify the value of the policy you want reports for and an endpoint to send those reports to.
05:36 - In reports only mode, you also get reporting-observing notifications. Okay, so let’s have a look at the additional support in DevTools for reporting mode. So here, I have a page with report-only COOP and COEP, and it’s the same page as the previous demo. I have just changed the headers it sends. So, on the Application tab, I can see report-only values for COOP and COEP and I can also see the associated reporting endpoints. And as you can see, we don’t have anything in the Issue tabs since we’re in report-only mode.
06:06 - This means that COEP is not enforced and we don’t block the sub-resource loads. Okay, now let me open a cross-origin pop up. It can still access the page because COOP is not enforced. So overall, what I have shown you is the seat of support for COOP and COEP in DevTools in Chrome 88. We do have more support plan to help you debug COOP and COEP more efficiently, and it’s gonna show up in later releases. Okay, so let’s summarize what you need to do to enable crossOriginlsolated on your site. So, with crossOriginlsolated, you will be able to use powerful APIs like SharedArrayBuffers on Android siting in Chrome 88, and your site will also be more secure against attacks like Spectre that tries to leak your user data. To make your website crossOriginlsolated, you need to enable COOP and COEP. To help you make the transition, enable COOP and COEP in report-only mode first. This will give you reports from production that will help you pin down the changes you need to make before deployment.
07:06 - Product with local debugging using DevTool application and issue panel to ensure that your webpage most support COOP and COEP. In terms of actually enabling COOP and COEP, this is all about setting the right headers. First, ensuring cross-origin subresources can load with CORS or have a COEP cross-origin header. This includes your cross-origin iframes as well. Then ensure all the documents in your app set to COEP require-corp header. So that means top-level documents and child documents, including cross-origin iframes. And so, finally, you need a COOP same-origin header on your top-level documents. And, with this, your page should be crossOriginIsolated and have access to powerful APIs as well as extra isolation that protects them against cross-origin data leak attacks. So, thank you all for watching and see you next time. (upbeat music) .