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

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

Eiji Kitamura

Abbiamo fornito il nuovo valore COEP (Cross-Origin Embedder Policy) credentialless che consente al browser di caricare risorse multiorigine che non utilizzano il criterio CORP (Cross-Origin Resource Policy), inviando una richiesta senza credenziali, come i cookie. In questo modo gli sviluppatori possono adottare più facilmente l'isolamento multiorigine.

Perché è necessario l'isolamento multiorigine

Alcune API web aumentano il rischio di attacchi side-channel come Spectre. Per ridurre questo rischio, i browser offrono un ambiente isolato basato su attivazione attiva chiamato isolamento multiorigine. Con uno stato isolato interorigine, la pagina web può utilizzare funzionalità con privilegi come SharedArrayBuffer, performance.measureUserAgentSpecificMemory() e timer ad alta precisione con risoluzione migliore, isolando l'origine dalle altre, a meno che non siano state 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

Con uno stato con isolamento multiorigine, tutte le risorse multiorigine devono essere pubblicate con CORS o impostare un'intestazione Cross-Origin-Resource-Policy da caricare.

Sfide dell'abilitazione dell'isolamento multiorigine

Sebbene l'isolamento multiorigine offra alle pagine web una maggiore sicurezza e la capacità di attivare funzionalità efficaci, il deployment può essere difficile. Una delle sfide principali è il requisito di abilitare CORS o CORP per tutte le risorse multiorigine. Le risorse senza queste intestazioni non verranno caricate dal browser in una pagina isolata multiorigine.

Queste risorse multiorigine vengono generalmente pubblicate da terze parti per i quali potrebbe non essere facile aggiungere le intestazioni necessarie.

Ma cosa succede se sappiamo che la risorsa è sufficientemente sicura da essere caricata? Infatti, le uniche risorse a rischio sono quelle richieste con le credenziali, perché potenzialmente includono informazioni sensibili che un utente malintenzionato non può caricare autonomamente. Ciò significa che le risorse che possono essere richieste senza credenziali sono disponibili pubblicamente e possono essere caricate 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ò attivare l'isolamento multiorigine, ma invece di richiedere un'intestazione CORP:cross-origin per le richieste multiorigine no-cors, vengono inviate senza credenziali (ad esempio, i cookie).

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

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

Ciò significa che il server multiorigine richiesto non potrà rispondere con una risorsa sensibile e il richiedente può sempre presumere che la risposta contenga solo informazioni disponibili pubblicamente.

Questo approccio è in linea con il piano di eliminazione graduale dei cookie di terze parti dei browser.

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 cambiare la modalità della richiesta per richiedere un controllo CORS sulla risposta. Per i tag HTML come <audio>, <img>, <link>, <script> e <video>, è sufficiente aggiungere crossorigin="use-credentials" esplicitamente 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 credenziale.

Per l'API fetch() è possibile usare request.mode = 'cors'.

Fornito 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 su CORS se sono necessari cookie per alcune sottorisorse multiorigine.

Posso caricare anche 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 assegnando gli iframe crossorigin="anonymous". Ciò consentirà il caricamento di iframe multiorigine senza intestazioni ma senza credenziali.

Questa funzionalità verrà adottata da altri browser?

Passaggi successivi

Sono in arrivo due aggiornamenti aggiuntivi per ridurre le altre sfide correlate all'isolamento multiorigine:

Coloro che si sono registrati alla prova dell'origine di Chrome per estendere la modifica di SharedArraybu a causa degli ostacoli precedenti potrebbero chiedersi quando verrà terminato. Inizialmente abbiamo annunciato che il servizio verrà chiuso in Chrome 96, ma abbiamo deciso di posticiparlo a Chrome 106.

Risorse

Foto di Martin Adams su Unsplash