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.
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
(orequire-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?
- Problema di monitoraggio con Firefox
- Richiesta Webkit per la posizione: nessun indicatore
- W3C TAG Richiesta di posizione: In attesa
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
- Rendere il tuo sito web "isolato multiorigine" utilizzando COOP e COEP
- Perché è necessario "isolamento multiorigine" per funzionalità potenti
- Una guida per attivare l'isolamento multiorigine
- Aggiornamenti di SharedArraybu in Chrome 88 per Android e Chrome 92 per computer
Foto di Martin Adams su Unsplash