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

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

Eiji Kitamura

We hebben de nieuwe waarde credentialless (Cross-Origin Embedder Policy) van COEP geïntroduceerd. Deze waarde stelt de browser in staat om cross-origin resources te laden die geen gebruik maken van de Cross-Origin Resource Policy (CORP) door een verzoek te versturen zonder inloggegevens, zoals cookies. Dit helpt ontwikkelaars om cross-origin isolatie gemakkelijker te implementeren.

Waarom we isolatie tussen verschillende oorsprongen nodig hebben

Sommige web-API's verhogen het risico op side-channel-aanvallen, zoals Spectre . Om dat risico te beperken, bieden browsers een opt-in-gebaseerde geïsoleerde omgeving genaamd cross-origin isolation . Met een cross-origin isolation-status kan de webpagina gebruikmaken van bevoorrechte functies zoals SharedArrayBuffer , performance.measureUserAgentSpecificMemory() en zeer nauwkeurige timers met een betere resolutie, terwijl de oorsprong wordt geïsoleerd van andere bronnen, tenzij deze 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

Bij een geïsoleerde cross-origin-status moeten alle cross-origin-bronnen worden bediend met CORS of moet er een Cross-Origin-Resource-Policy header worden ingesteld om te worden geladen.

Uitdagingen bij het mogelijk maken van cross-origin isolatie

Hoewel cross-origin isolatie webpagina's beter beschermt en krachtige functies mogelijk maakt, 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 resources. Resources zonder deze headers worden niet door de browser geladen op een cross-origin geïsoleerde pagina.

Deze cross-origin bronnen worden doorgaans door externe partijen aangeboden. Voor hen kan het lastig zijn om de benodigde headers toe te voegen.

Maar wat als we weten dat de resource veilig genoeg is om te laden? Sterker nog, de enige resources die risico lopen, zijn resources die met inloggegevens worden opgevraagd, omdat ze mogelijk gevoelige informatie bevatten die de aanvaller niet zelf kan laden. Dit betekent dat resources die zonder inloggegevens kunnen worden opgevraagd, openbaar beschikbaar zijn en veilig kunnen worden geladen.

credentialless ter redding

Daar komt COEP: credentialless om de hoek kijken. 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 cross-origin verzoeken zonder CORS, worden deze in plaats daarvan verzonden zonder referenties (bijvoorbeeld cookies).

U kunt cross-origin-isolatie ook 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 met een gevoelige bron kan reageren en de aanvrager er altijd vanuit kan gaan dat het antwoord alleen openbaar beschikbare informatie bevat.

Dit is ook in lijn met het plan van browsers om cookies van derden geleidelijk uit te bannen .

Demonstratie

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

Veelgestelde vragen

Kan ik een verzoek met referenties indienen in een omgeving credentialless ?

Absoluut, maar dan moet de aanvraagmodus wel worden aangepast om een ​​CORS-controle op de respons te vereisen. Voor HTML-tags zoals <audio> , <img> , <link> , <script> en <video> voegt u gewoon crossorigin="use-credentials" expliciet toe om de browser te laten weten dat er verzoeken met referenties moeten worden verzonden.

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

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

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

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

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

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

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

Het goede nieuws is dat er een discussie gaande is over het toestaan ​​van het laden van cross-origin iframes zonder die headers door iframes crossorigin="anonymous" te geven . Dit maakt het mogelijk om cross-origin iframes te laden zonder headers, maar zonder inloggegevens.

Wordt deze functionaliteit ook door andere browsers overgenomen?

Wat komt er nu?

Er komen twee aanvullende updates om andere uitdagingen met betrekking tot cross-origin isolatie aan te pakken:

Degenen die zich vanwege de bovengenoemde obstakels hebben aangemeld voor de proefperiode van Chrome Origin om de SharedArrayBuffer-wijziging te verlengen, vragen zich misschien af ​​wanneer deze wordt beëindigd. Oorspronkelijk hadden we aangekondigd dat deze in Chrome 96 zou worden beëindigd, maar we hebben besloten dit uit te stellen tot Chrome 106.

Bronnen

Foto door Martin Adams op Unsplash

,

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

Eiji Kitamura

We hebben de nieuwe waarde credentialless (Cross-Origin Embedder Policy) van COEP geïntroduceerd. Deze waarde stelt de browser in staat om cross-origin resources te laden die geen gebruik maken van de Cross-Origin Resource Policy (CORP) door een verzoek te versturen zonder inloggegevens, zoals cookies. Dit helpt ontwikkelaars om cross-origin isolatie gemakkelijker te implementeren.

Waarom we isolatie tussen verschillende oorsprongen nodig hebben

Sommige web-API's verhogen het risico op side-channel-aanvallen, zoals Spectre . Om dat risico te beperken, bieden browsers een opt-in-gebaseerde geïsoleerde omgeving genaamd cross-origin isolation . Met een cross-origin isolation-status kan de webpagina gebruikmaken van bevoorrechte functies zoals SharedArrayBuffer , performance.measureUserAgentSpecificMemory() en zeer nauwkeurige timers met een betere resolutie, terwijl de oorsprong wordt geïsoleerd van andere bronnen, tenzij deze 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

Bij een geïsoleerde cross-origin-status moeten alle cross-origin-bronnen worden bediend met CORS of moet er een Cross-Origin-Resource-Policy header worden ingesteld om te worden geladen.

Uitdagingen bij het mogelijk maken van cross-origin isolatie

Hoewel cross-origin isolatie webpagina's beter beschermt en krachtige functies mogelijk maakt, 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 resources. Resources zonder deze headers worden niet door de browser geladen op een cross-origin geïsoleerde pagina.

Deze cross-origin bronnen worden doorgaans door externe partijen aangeboden. Voor hen kan het lastig zijn om de benodigde headers toe te voegen.

Maar wat als we weten dat de resource veilig genoeg is om te laden? Sterker nog, de enige resources die risico lopen, zijn resources die met inloggegevens worden opgevraagd, omdat ze mogelijk gevoelige informatie bevatten die de aanvaller niet zelf kan laden. Dit betekent dat resources die zonder inloggegevens kunnen worden opgevraagd, openbaar beschikbaar zijn en veilig kunnen worden geladen.

credentialless ter redding

Daar komt COEP: credentialless om de hoek kijken. 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 cross-origin verzoeken zonder CORS, worden deze in plaats daarvan verzonden zonder referenties (bijvoorbeeld cookies).

U kunt cross-origin-isolatie ook 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 met een gevoelige bron kan reageren en de aanvrager er altijd vanuit kan gaan dat het antwoord alleen openbaar beschikbare informatie bevat.

Dit is ook in lijn met het plan van browsers om cookies van derden geleidelijk uit te bannen .

Demonstratie

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

Veelgestelde vragen

Kan ik een verzoek met referenties indienen in een omgeving credentialless ?

Absoluut, maar dan moet de aanvraagmodus wel worden aangepast om een ​​CORS-controle op de respons te vereisen. Voor HTML-tags zoals <audio> , <img> , <link> , <script> en <video> voegt u gewoon crossorigin="use-credentials" expliciet toe om de browser te laten weten dat er verzoeken met referenties moeten worden verzonden.

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

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

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

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

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

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

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

Het goede nieuws is dat er een discussie gaande is over het toestaan ​​van het laden van cross-origin iframes zonder die headers door iframes crossorigin="anonymous" te geven . Dit maakt het mogelijk om cross-origin iframes te laden zonder headers, maar zonder inloggegevens.

Wordt deze functionaliteit ook door andere browsers overgenomen?

Wat komt er nu?

Er komen twee aanvullende updates om andere uitdagingen met betrekking tot cross-origin isolatie aan te pakken:

Degenen die zich vanwege de bovengenoemde obstakels hebben aangemeld voor de proefperiode van Chrome Origin om de SharedArrayBuffer-wijziging te verlengen, vragen zich misschien af ​​wanneer deze wordt beëindigd. Oorspronkelijk hadden we aangekondigd dat deze in Chrome 96 zou worden beëindigd, maar we hebben besloten dit uit te stellen tot Chrome 106.

Bronnen

Foto door Martin Adams op Unsplash