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

Le risorse multiorigine servite da terze parti spesso non includono intestazioni CORP adeguate. Se possono essere richiesti senza credenziali, ora puoi abilitare l'isolamento multiorigine contrassegnandoli come tali.

Eiji Kitamura

Abbiamo introdotto il nuovo valore COEP (Cross-Origin Embedder Policy) credentialless che consente al browser di caricare risorse multiorigine, non utilizzano i criteri delle risorse multiorigine (CORP), inviando una richiesta senza come i cookie. Questo aiuta gli sviluppatori ad adottare il modello multiorigine e l'isolamento più facilmente.

Perché abbiamo bisogno dell'isolamento multiorigine

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

La pagina web deve inviare due intestazioni HTTP per consentire 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 con CORS o impostare un'intestazione Cross-Origin-Resource-Policy da caricare.

Sfide dell'abilitazione dell'isolamento multiorigine

L'isolamento multiorigine offre una maggiore sicurezza delle pagine web e la possibilità attivare funzionalità potenti, il deployment può difficile. Uno dei più grandi delle sfide è il requisito per abilitare CORS o CORP per tutte le istanze Google Cloud. Le risorse senza queste intestazioni non verranno caricate dal browser su una pagina con isolamento multiorigine.

Queste risorse multiorigine sono in genere fornite da terze parti per le quali potrebbero non sia facile aggiungere le intestazioni necessarie.

Ma cosa succede se sappiamo che la risorsa è sufficientemente sicura da poter essere caricata? Infatti, l'unico a rischio sono quelle richieste con credenziali, perché potrebbero includere informazioni sensibili che l'autore dell'attacco non è in grado di caricare sui propri personali. Ciò significa che le risorse che possono essere richieste senza credenziali sono pubbliche disponibili e da caricare in sicurezza.

credentialless in soccorso

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

Potrai attivare l'isolamento multiorigine in alternativa con il con le due intestazioni seguenti:

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

Ciò significa che il server multiorigine richiesto non sarà in grado di rispondere con un sensibile e il richiedente può sempre presupporre che la risposta contiene informazioni disponibili pubblicamente.

Anche questo è in linea con le per il ritiro dei cookie di terze parti.

Demo

In questa demo puoi provare varie opzioni di intestazione: 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 che richieda un controllo CORS sulla risposta. Per tag HTML quali <audio>, <img>, <link>, <script>, e <video>, aggiungi esplicitamente crossorigin="use-credentials" per informare il browser per inviare richieste con credenziali.

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

Per l'API fetch(), è possibile 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 alla modalità di richiesta 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 multiorigine in un ambiente credentialless richiede comunque 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 su come consentire il caricamento di iframe multiorigine senza queste intestazioni fornendo agli iframe crossorigin="anonymous". Ciò consentirà il caricamento di iframe multiorigine senza intestazioni, ma senza e credenziali.

Questa funzionalità verrà adottata da altri browser?

Passaggi successivi

Presto ci saranno altri due aggiornamenti per limitare altre sfide legate alla isolamento multiorigine:

Gli utenti che si sono registrati alla prova dell'origine di Chrome per estendere la modifica SharedArrayBuffer a causa di gli ostacoli di cui sopra potrebbero chiedersi quando verrà arrestata. In origine, abbiamo annunciato che verrà terminata in Chrome 96, ma abbiamo deciso a Chrome 106.

Risorse

Foto di Martin Adams attivo Rimuovi schermo