Laad cross-originebronnen zonder CORP-headers met behulp van COEP: credentialless

Cross-origin-bronnen die door derden worden aangeboden, bevatten vaak geen adequate CORP-headers. Als ze zonder inloggegevens kunnen worden aangevraagd, kunt u nu cross-origin-isolatie inschakelen door ze als zodanig te markeren.

Eiji Kitamura

We hebben de nieuwe Cross-Origin Embedder Policy (COEP)-waarde credentialless verzonden, waarmee de browser cross-origin-bronnen kan laden die geen gebruik maken van het Cross-Origin Resource Policy (CORP), door een verzoek te verzenden zonder inloggegevens, zoals cookies . Dit helpt ontwikkelaars om gemakkelijker cross-origin-isolatie toe te passen.

Waarom we cross-originele isolatie nodig hebben

Sommige web-API's vergroten het risico op zijkanaalaanvallen zoals Spectre . Om dat risico te beperken, bieden browsers een op opt-in gebaseerde geïsoleerde omgeving, genaamd cross-origin isolation . Met een cross-origin geïsoleerde status kan de webpagina geprivilegieerde functies gebruiken, waaronder SharedArrayBuffer , performance.measureUserAgentSpecificMemory() en zeer nauwkeurige timers met een betere resolutie , terwijl de oorsprong van anderen wordt geïsoleerd, tenzij ze zijn aangemeld.

De webpagina moet twee HTTP-headers verzenden om cross-origin-isolatie mogelijk te maken:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Met een geïsoleerde cross-origin-status moeten alle cross-origin-bronnen worden geleverd met CORS of een Cross-Origin-Resource-Policy header instellen om te worden geladen.

Uitdagingen bij het mogelijk maken van cross-origin-isolatie

Hoewel cross-origin-isolatie webpagina's een betere beveiliging biedt en de mogelijkheid biedt om krachtige functies in te schakelen, kan de implementatie ervan lastig zijn. Een van de grootste uitdagingen is de vereiste om CORS of CORP in te schakelen voor alle cross-origin-bronnen. Bronnen zonder deze headers worden niet door de browser geladen op een geïsoleerde cross-origin-pagina.

Deze cross-origin-bronnen worden meestal aangeboden door derden voor wie het misschien niet eenvoudig is om de benodigde headers toe te voegen.

Maar wat als we weten dat de bron veilig genoeg is om te worden geladen? In feite zijn de enige bronnen die gevaar lopen de bronnen waar om inloggegevens wordt gevraagd, omdat deze mogelijk gevoelige informatie bevatten die de aanvaller niet zelf kan laden. Dit betekent dat bronnen die zonder inloggegevens kunnen worden aangevraagd, openbaar beschikbaar zijn en veilig kunnen worden geladen.

credentialless om te redden

Dat is waar COEP: credentialless in beeld komt. credentialless is een nieuwe waarde voor de Cross-Origin-Embedder-Policy header. Net als require-corp kan het cross-origin-isolatie inschakelen, maar in plaats van een CORP:cross-origin header te vereisen voor no-cors cross-origin-aanvragen, worden deze in plaats daarvan verzonden zonder inloggegevens (bijvoorbeeld cookies).

U kunt cross-origin-isolatie als alternatief inschakelen met de volgende twee headers:

Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin

Dit betekent dat de aangevraagde cross-origin-server niet kan reageren met een gevoelige bron en dat de aanvrager er altijd van uit kan gaan dat het antwoord alleen openbaar beschikbare informatie bevat.

Dit sluit ook aan bij het plan van browsers om cookies van derden geleidelijk af te schaffen .

Demo

Je kunt verschillende headeropties uitproberen in deze demo: https://cross-origin-isolation.glitch.me

FAQ

Kan ik een gelegitimeerde aanvraag verzenden in een credentialless omgeving?

Absoluut, ten koste van het verschuiven van de modus van het verzoek om een ​​CORS-controle op het antwoord te vereisen. Voor HTML-tags zoals <audio> , <img> , <link> , <script> en <video> voegt u expliciet crossorigin="use-credentials" toe om de browser te informeren om verzoeken met referenties te verzenden.

Zelfs als een document op https://www.example.com bijvoorbeeld Cross-Origin-Embedder-Policy: credentialless header, <img src="https://images.example.com/avatar.png" crossorigin="use-credentials"> zal een legitimatieverzoek verzenden.

Voor de fetch() API kan request.mode = 'cors' worden gebruikt.

Mits COEP: credentialless , hoe is COEP: require-corp nog steeds nuttig voor mijn website?

COEP: require-corp vereist niet dat u de aanvraagmodus handmatig naar CORS schakelt als er cookies nodig zijn voor sommige cross-origin-subbronnen.

Kan ik ook cross-origin iframes laden zonder speciale headers in een credentialless omgeving?

Nee. Het laden van cross-origin iframes in een omgeving credentialless vereist nog steeds dezelfde voorwaarden als require-corp . iframe-documenten moeten worden aangeboden met twee headers:

  • Cross-Origin-Embedder-Policy: credentialless (of require-corp )
  • Cross-Origin-Resource-Policy: cross-origin

Het goede nieuws is dat er een voortdurende discussie bestaat over het toestaan ​​van het laden van cross-origin iframes zonder deze headers door iframes crossorigin="anonymous" te geven . Hierdoor kunnen cross-origin iframes worden geladen zonder headers maar zonder inloggegevens.

Zal deze functie door andere browsers worden overgenomen?

Wat komt er hierna

Er komen twee extra updates om andere uitdagingen met betrekking tot isolatie tussen verschillende oorsprongen te verzachten:

Degenen die zich hebben geregistreerd voor de Chrome Origin-proefversie om de SharedArrayBuffer-wijziging te verlengen vanwege de bovenstaande obstakels, vragen zich misschien af ​​wanneer deze wordt beëindigd. Oorspronkelijk hadden we aangekondigd dat het wordt beëindigd in Chrome 96, maar we hebben besloten dit uit te stellen naar Chrome 106.

Bronnen

Foto door Martin Adams op Unsplash