Carregar recursos de origem cruzada sem cabeçalhos CORP usando COEP: sem credencial

Os recursos de origem cruzada veiculados por terceiros geralmente não incluem cabeçalhos CORP adequados. Se eles puderem ser solicitados sem credenciais, agora será possível ativar o isolamento de origem cruzada marcando-os como tal.

Eiji Kitamura

Enviamos o novo valor da política de incorporador de origem cruzada (COEP, na sigla em inglês) credentialless, que permite ao navegador carregar recursos de origem cruzada que usam a política de recursos entre origens (CORP, na sigla em inglês), enviando uma solicitação sem credenciais, como cookies. Isso ajuda os desenvolvedores a adotar tecnologias o isolamento com mais facilidade.

Por que precisamos do isolamento de origem cruzada

Algumas APIs da Web aumentam o risco de ataques de canal lateral, como Spectre: Para mitigar esse risco, os navegadores oferecem um ambiente isolado com base em aceitação chamado isolamento de origem cruzada. Com uma origem cruzada estado isolado, a página pode usar recursos privilegiados, incluindo SharedArrayBuffer, performance.measureUserAgentSpecificMemory() e tempos de alta precisão com melhor resolução enquanto isolam a origem das outras, a menos que tenham sido 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 do isolamento de origem cruzada

Embora o isolamento de origem cruzada melhore a segurança das páginas da Web e a capacidade de recursos avançados, a implantação pode ser difícil. Um dos maiores desafios é a exigência de ativar o CORS ou CORP para todos os relatórios do Google Cloud. Recursos sem esses cabeçalhos não serão carregados pelo navegador no uma página isolada de origem cruzada.

Esses recursos de origem cruzada são normalmente disponibilizados por terceiros para os quais ele pode não será fácil adicionar os cabeçalhos necessários.

Mas e se soubermos que o recurso é seguro o suficiente para ser carregado? Na verdade, o único os recursos que estão em risco são aqueles solicitados com credenciais, porque 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 são disponíveis e seguros para carregar.

credentialless ao resgate

É aí que entra a COEP: credentialless. credentialless é um novo valor para o cabeçalho Cross-Origin-Embedder-Policy. Semelhante à require-corp, ela pode permite o isolamento de origem cruzada, mas em vez de exigir um CORP:cross-origin para solicitações de origem cruzada sem cors, elas são enviadas sem credenciais (por exemplo, cookies).

Como alternativa, é possível ativar o isolamento de origem cruzada com o 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 uma recurso sensível, e o solicitante pode sempre presumir que a resposta só contém informações disponíveis ao público.

Isso também está alinhado com os plano de eliminação gradual dos 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?

Claro, ao custo de mudar o modo da solicitação para exigir uma verificação de CORS na resposta. Para tags HTML como <audio>, <img>, <link>, <script>, e <video>, basta anexar crossorigin="use-credentials" explicitamente para informar e o navegador envie solicitações credenciadas.

Por exemplo, mesmo que um documento em https://www.example.com tenha cabeçalho Cross-Origin-Embedder-Policy: credentialless, <img src="https://images.example.com/avatar.png" crossorigin="use-credentials"> vai envie uma solicitação credenciada.

Para a API fetch(), é possível usar request.mode = 'cors'.

Você forneceu COEP: credentialless, de que forma o COEP: require-corp ainda é útil para meu site?

COEP: require-corp não exige que você mude o modo de solicitação manualmente para CORS se forem necessários cookies 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 exibidos com dois cabeçalhos:

  • Cross-Origin-Embedder-Policy: credentialless (ou require-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 com a atribuição de iframes crossorigin="anonymous". Isso vai permitir que iframes de origem cruzada sejam carregados sem cabeçalhos, mas sem credenciais.

Esse recurso será adotado por outros navegadores?

O que vem por aí

Vamos lançar mais duas atualizações para mitigar outros desafios relacionados à isolamento de origem cruzada:

Quem se inscreveu no teste de origem do Chrome para estender a mudança do SharedArrayBuffer devido a os obstáculos acima podem estar se perguntando quando ela será encerrada. Originalmente, nós anunciou que ela será encerrada no Chrome 96, mas decidimos adiar isso para o Chrome 106.

Recursos

Foto de Martin Adams ativado Abrir