Carica le risorse multiorigine senza intestazioni CORP utilizzando COEP: senza credenziali

Le risorse cross-origin pubblicate da terze parti spesso non includono intestazioni CORP adeguate. Se possono essere richieste senza credenziali, ora puoi attivare l'isolamento cross-origin contrassegnandole come tali.

Eiji Kitamura

Abbiamo rilasciato il nuovo valore del criterio di incorporamento tra origini (COEP)credentialless che consente al browser di caricare risorse tra origini che non utilizzano il criterio delle risorse tra origini (CORP) inviando una richiesta senza credenziali, come i cookie. Ciò consente agli sviluppatori di adottare più facilmente l'isolamento multiorigine.

Perché abbiamo bisogno dell'isolamento multiorigine

Alcune API web aumentano il rischio di attacchi side-channel come Spectre. Per attenuare questo rischio, i browser offrono un ambiente isolato basato su attivazione chiamato isolamento multiorigine. Con uno stato di isolamento tra origini, la pagina web può utilizzare funzionalità privilegiate, tra cui SharedArrayBuffer, performance.measureUserAgentSpecificMemory() e timer ad alta precisione con una risoluzione migliore, isolando al contempo l'origine dalle altre, a meno che non siano attivate.

La pagina web deve inviare due intestazioni HTTP per attivare l'isolamento multiorigine:

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

In uno stato isolato multiorigine, tutte le risorse multiorigine devono essere gestite tramite CORS o impostare un'intestazione Cross-Origin-Resource-Policy da caricare.

Problemi relativi all'attivazione dell'isolamento multiorigine

Sebbene l'isolamento cross-origin offra alle pagine web una maggiore sicurezza e la possibilità di attivare funzionalità potenti, il suo implementazione può essere difficile. Uno dei maggiori problemi è il requisito di attivare CORS o CORP per tutte le risorse cross-origin. Le risorse senza queste intestazioni non verranno caricate dal browser su una pagina isolata cross-origin.

Queste risorse cross-origin vengono in genere pubblicate da terze parti per le quali potrebbe non essere facile aggiungere le intestazioni necessarie.

Ma cosa succede se sappiamo che la risorsa è sufficientemente sicura da poter essere caricata? Infatti, le uniche risorse a rischio sono quelle richieste con credenziali, perché potenzialmente includono informazioni sensibili che l'utente malintenzionato non può caricare autonomamente. Ciò significa che le risorse che possono essere richieste senza credenziali sono disponibili pubblicamente e sicure da caricare.

credentialless accorre in soccorso

È qui che entra in gioco COEP: credentialless. credentialless è un nuovo valore per l'intestazione Cross-Origin-Embedder-Policy. Come require-corp, può attivare l'isolamento multiorigine, ma anziché richiedere un'intestazione CORP:cross-origin per le richieste cross-origin no-cors, queste vengono inviate senza credenziali (ad esempio i cookie).

In alternativa, potrai attivare l'isolamento multiorigine con le seguenti due intestazioni:

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

Ciò significa che il server cross-origin richiesto non potrà rispondere con una risorsa sensibile e l'autore della richiesta può sempre presumere che la risposta contenga solo informazioni disponibili pubblicamente.

Inoltre, è in linea con il piano dei browser di eliminare gradualmente i cookie di terze parti.

Demo

Puoi provare varie opzioni di intestazione in questa demo: https://cross-origin-isolation.glitch.me

Domande frequenti

Posso inviare una richiesta con credenziali in un ambiente credentialless?

Assolutamente, a costo di modificare la modalità della richiesta in modo da richiedere un controllo CORS sulla risposta. Per i tag HTML come <audio>, <img>, <link>, <script> e <video>, aggiungi semplicemente crossorigin="use-credentials" in modo esplicito per informare il browser di inviare richieste con credenziali.

Ad esempio, anche se un documento su https://www.example.com ha l'intestazione Cross-Origin-Embedder-Policy: credentialless, <img src="https://images.example.com/avatar.png" crossorigin="use-credentials"> invierà una richiesta con credenziali.

Per l'API fetch(), puoi utilizzare request.mode = 'cors'.

COEP: credentialless: in che modo COEP: require-corp è ancora utile per il mio sito web?

COEP: require-corp non richiede di passare manualmente dalla modalità di richiesta a CORS se sono necessari cookie per alcune sottorisorse multiorigine.

Posso anche caricare iframe multiorigine senza intestazioni speciali in un ambiente credentialless?

No. Il caricamento di iframe cross-origin in un ambiente credentialless richiede ancora le stesse condizioni di require-corp. I documenti iframe devono essere pubblicati con due intestazioni:

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

La buona notizia è che è in corso una discussione sul consentire il caricamento di iFrame cross-origin senza queste intestazioni assegnando agli iFrame crossorigin="anonymous". In questo modo, gli iframe cross-origin verranno caricati senza intestazioni, ma senza credenziali.

Questa funzionalità verrà adottata da altri browser?

Passaggi successivi

Sono previsti altri due aggiornamenti per mitigare altri problemi relativi all'isolamento multiorigine:

Chi si è registrato alla prova dell'origine di Chrome per estendere la modifica di SharedArrayBuffer a causa degli ostacoli sopra indicati potrebbe chiedersi quando verrà interrotta. Inizialmente abbiamo annunciato che la funzionalità verrà interrotta in Chrome 96, ma abbiamo deciso di posticipare questa operazione a Chrome 106.

Risorse

Foto di Martin Adams su Unsplash