Em geral, os recursos de origem cruzada disponibilizados por terceiros não incluem cabeçalhos CORP adequados. Se for possível solicitar os registros sem credenciais, agora você pode ativar o isolamento de origem cruzada marcando-os como tal.
Enviamos o novo valor credentialless
da Política de incorporação de origem (COEP, na sigla em inglês), que permite ao navegador carregar recursos de origem cruzada que não usam a Política de recursos de origem cruzada (CORP, na sigla em inglês), enviando uma solicitação sem credenciais, como cookies. Isso ajuda os desenvolvedores a adotar o isolamento
de origem cruzada com mais facilidade.
Por que precisamos do isolamento de origem cruzada
Algumas APIs da Web aumentam o risco de ataques de canal lateral, como o Spectre. Para reduzir esse risco, os navegadores oferecem um ambiente isolado com base em permissão chamado isolamento de origem cruzada. Com um estado isolado
de origem cruzada, a página da Web pode usar recursos privilegiados, incluindo
SharedArrayBuffer
,
performance.measureUserAgentSpecificMemory()
e temporizadores de alta precisão com melhor resolução,
ao mesmo tempo que isola a origem de outras, a menos que elas sejam ativadas.
A página da Web precisa enviar dois cabeçalhos HTTP para ativar o isolamento de origem cruzada:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Com um estado isolado de origem cruzada, todos os recursos de origem cruzada precisam ser disponibilizados
com CORS ou definir um cabeçalho Cross-Origin-Resource-Policy
para ser carregado.
Desafios no isolamento de origem cruzada
Embora o isolamento de origem cruzada traga mais segurança para as páginas da Web e a capacidade de ativar recursos avançados, a implantação pode ser difícil. Um dos maiores desafios é o requisito de ativar CORS ou CORP para todos os recursos de origem cruzada. Recursos sem esses cabeçalhos não serão carregados pelo navegador em uma página isolada de origem cruzada.
Esses recursos de origem cruzada geralmente são disponibilizados por terceiros para os quais não é fácil adicionar os cabeçalhos necessários.
E se soubermos que o recurso é seguro o suficiente para ser carregado? Na verdade, os únicos recursos em risco são aqueles solicitados com credenciais, porque eles podem incluir informações sensíveis que o invasor não consegue carregar por conta própria. Isso significa que os recursos que podem ser solicitados sem credenciais estão disponíveis publicamente e são seguros para carregamento.
credentialless
ao resgate
É aí que entra a COEP: credentialless
. credentialless
é um novo valor
para o cabeçalho Cross-Origin-Embedder-Policy
. Assim como require-corp
, ele pode
ativar o isolamento de origem cruzada, mas, em vez de exigir um cabeçalho CORP:cross-origin
para solicitações de origem cruzada sem cors, elas são enviadas sem
credenciais (por exemplo, cookies).
Você poderá ativar o isolamento de origem cruzada com os dois cabeçalhos a seguir:
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
Isso significa que o servidor de origem cruzada solicitado não poderá responder com um recurso confidencial e o solicitante sempre poderá presumir que a resposta contém apenas informações disponíveis publicamente.
Isso também está de acordo com o plano dos navegadores de desativar cookies de terceiros.
Demonstração
É possível testar várias opções de cabeçalho nesta demonstração: https://cross-origin-isolation.glitch.me.
Perguntas frequentes
Posso enviar uma solicitação credenciada em um ambiente credentialless
?
Com certeza, ao custo de mudar o modo da solicitação para exigir uma verificação do CORS na resposta. Para tags HTML, como <audio>
, <img>
, <link>
, <script>
e <video>
, basta anexar crossorigin="use-credentials"
explicitamente para informar ao navegador para enviar solicitações credenciadas.
Por exemplo, mesmo que um documento em https://www.example.com
tenha um cabeçalho Cross-Origin-Embedder-Policy: credentialless
, <img
src="https://images.example.com/avatar.png" crossorigin="use-credentials">
enviará uma solicitação credenciada.
Para a API fetch()
, é possível usar request.mode = 'cors'
.
Depois de informar COEP: credentialless
, como o COEP: require-corp
ainda é útil para meu site?
COEP: require-corp
não exige que você mude manualmente o modo de solicitação para
CORS se os cookies forem necessários para alguns sub-recursos de origem cruzada.
Também posso carregar iframes de origem cruzada sem cabeçalhos especiais em um ambiente credentialless
?
Não. O carregamento de iframes de origem cruzada em um ambiente credentialless
ainda exige as mesmas condições que require-corp
. Os documentos iframe precisam ser disponibilizados com dois cabeçalhos:
Cross-Origin-Embedder-Policy: credentialless
(ourequire-corp
)Cross-Origin-Resource-Policy: cross-origin
A boa notícia é que há uma discussão em andamento sobre permitir o carregamento de iframes de origem cruzada sem esses cabeçalhos ao fornecer crossorigin="anonymous"
aos iframes.
Isso permite que iframes de origem cruzada sejam carregados sem cabeçalhos, mas sem credenciais.
Esse recurso será usado por outros navegadores?
- Problema de acompanhamento do Firefox
- Solicitação do Webkit para posição: sem sinal
- TAG W3C Solicitação de posição: pendente
O que vem a seguir
Há mais duas atualizações chegando para mitigar outros desafios relacionados ao isolamento de origem cruzada:
Os usuários que se inscreveram no teste de origem do Chrome para estender a mudança SharedArrayBuffer devido aos obstáculos acima podem estar se perguntando quando ela será encerrada. Anunciamos que o recurso seria encerrado no Chrome 96, mas decidimos adiá-lo para o Chrome 106.
Recursos
- Como tornar seu site "isolado de origem cruzada" usando COOP e COEP
- Por que o "isolamento de origem cruzada" é necessário para recursos avançados
- Um guia para ativar o isolamento de origem cruzada
- Atualizações do SharedArrayBuffer no Android Chrome 88 e no Chrome 92 para computador
Foto de Martin Adams no Unsplash