CORS, é de comer?

Entendendo um pouco mais sobre a política de CORS para solucionar os problemas de requisições para origens cruzadas.

Maria Clara Melo de Carvalho
Computando Arte
4 min readSep 29, 2021

--

Photo by Andy Kelly on Unsplash

Se você trabalha com desenvolvimento web provavelmente já se deparou com um erro de CORS, mas porque este erro acontece? E como podemos corrigi-lo?

Exemplo de um erro de CORS

Política de mesma origem (Same-origin policy)

Este erro está relacionado a uma política de segurança que restringe como um recurso carregado em uma origem irá interagir com recursos de outra origem. Não há problema em solicitar, por exemplo, uma imagem quando esta se encontra na mesma origem do script que a solicitou, o maior problema é quando queremos solicitar uma imagem que está em outro servidor, consequentemente em outra origem.

Uma origem é definida pelo conjunto de protocolo, domínio/subdomínio e porta. A tabela abaixo mostra alguns exemplos do que acontece quando requisitamos o recurso https://www.meusite.com.br/amigos.json a partir de diversas origens.

Para possibilitar a realização de requisições para diferentes origens é que usamos a política de CORS.

CORS: Cross Origin Resource Sharing

Esta política visa permitir que o browser (client-side) possa requisitar recursos para um servidor (server-side) que está em outra origem com domínios, protocolos e portas diferentes. Além disso, garantimos que apenas clientes específicos e autorizados poderão recuperar as informações desse servidor.

Quando fazemos uma requisição para uma origem diferente o browser, por padrão, adiciona a requisição o header origin que informa ao servidor qual a origem daquela requisição.

Exemplo do header origin adicionado a requisição

Para que o navegador permita fazer as requisições para origens cruzadas, ele espera que o servidor indique que ele também permite requisições cruzadas. Esta comunicação é feita adicionando cabeçalhos extras na resposta do servidor.

Cabeçalhos extras

Existem diversos cabeçalhos de CORS, explanarei aqui sobre os
três principais.

Access-Control-Allow-Origin:

Este é o cabeçalho mais importante, pois é através dele que o navegador saberá se pode ou não receber aquela resposta. Ao recebê-lo, o navegador compara o valor contido nele com o que é enviado na requisição, através do header origin. Se eles forem iguais, o navegador permite as respostas das requisições para esta origem, que é diferente. Se não, ele as bloqueia.

Access-Control-Allow-Methods e Access-Control-Allow-Headers :

Através destes cabeçalhos, o navegador sabe quais métodos HTTP e headers podem ser enviados para o servidor. Contudo, antes de falar sobre estes headers é necessário observar que o mecanismo que controla o CORS no navegador classifica as requisições em dois tipos: as simples e as pré-confirmadas.

As requisições simples, são requisições do tipo GET, HEAD e DELETE, que possuem content-type iguais a application/x-www-form-urlencoded, multipart/form-data ou text/plain e não possuem nenhum event listener associado. Para estas requisições, o navegador apenas envia a requisição para servidor e compara header access-control-allow-origin recebido, como mostra a imagem abaixo. Qualquer requisição que não possua nenhuma dessas características é considerada uma requisição pré-confirmada.

Requisições simples

Já as requisições pré-confirmadas funcionam da seguinte forma. Antes de executar a requisição, uma outra é feita utilizando o método OPTIONS e nela são enviados os seguintes headers:

  • access-control-request-methods: que indica qual método HTTP a requisição pretende utilizar;
  • access-control-request-headers: quais headers a requisição enviará.

Ao enviar esta requisição o navegador espera receber uma resposta contendo os seguintes headers:

  • access-control-allow-methods: indicando quais métodos HTTP ele aceita;
  • access-control-allow-headers: quais headers podem ser enviados.

Com essas informações, o mecanismo compara o valor dos headers enviados e recebidos, validando se o método HTTP é válido e se o header pode ser enviado. Se comparação for bem sucedida a requisição de fato é realizada, caso haja alguma inconsistência um erro de CORS será exibido. A imagem abaixo ilustra este fluxo de requisições.

Requisições pré-confirmadas

Conclusão

Erros CORS são extremamente frustrantes. Mas, nesta breve introdução sobre CORS, aprendemos que o funcionamento desta política é baseado na comunicação entre o cliente e o servidor através de headers. Portanto, na maioria das vezes apenas esquecemos de estabelecer essa comunicação.

Esta política tem se mostrado importantíssima para garantir a segurança na realização de requisições de origens cruzadas, que se tornaram cada vez mais comuns. Sendo assim, é necessário entender como ela funciona para saber solucionar possíveis erros de CORS que aparecerão durante o desenvolvimento da sua aplicação web.

--

--