O que é CORS?

No passado, quando as tecnologias da Internet ainda eram novas, aconteciam problemas de falsificação de solicitações entre sites (CSRF). Esses problemas enviaram solicitações de cliente falsas do navegador da vítima para outra aplicação.

Por exemplo, a vítima fazia login na aplicação de um banco. Em seguida, ela era induzida a carregar um site externo em uma nova guia do navegador. O site externo então usava as credenciais de cookie da vítima e retransmitia os dados para a aplicação bancário enquanto fingia ser a vítima. Usuários não autorizados então tinham acesso não intencional à aplicação bancária.

Para evitar esses problemas de CSRF, todos os navegadores agora implementam a política de mesma origem.

Política de mesma origem

Atualmente, os navegadores exigem que os clientes só possam enviar solicitações para um recurso com a mesma origem que o URL do cliente. O protocolo, a porta e o nome do host do URL do cliente devem corresponder ao servidor solicitado.

Por exemplo, considere a comparação da origem dos URLs abaixo com o URL do cliente http://store.aws.com/dir/page.html.

URL	Resultados	Motivo
http://store.aws.com/dir2/new.html	Mesma origem	Somente o caminho é diferente
http://store.aws.com/dir/inner/other.html	Mesma origem	Somente o caminho é diferente
https://store.aws.com/page.html	Origem diferente	Protocolo diferente
http://store.aws.com:81/dir/page.html	Origem diferente	Porta diferente (http://é a porta 80 por padrão)
http://news.aws.com/dir/page.html	Origem diferente	Host diferente

Portanto, a política de mesma origem é altamente segura, mas inflexível para casos de uso genuínos.

O Compartilhamento de recursos entre origens (CORS) é uma extensão da política de mesma origem. Você precisa dele para compartilhar recursos autorizados com terceiros externos. Por exemplo, você precisa do CORS quando deseja extrair dados de APIs externas públicas ou autorizadas. Você também precisa do CORS se quiser permitir o acesso autorizado de terceiros aos seus próprios recursos de servidor.

Em HTTP, os métodos de solicitação são as operações de dados que o cliente deseja que o servidor execute. Os métodos HTTP comuns incluem GET, POST, PUT e DELETE.

Em uma interação regular de compartilhamento de recursos entre origens (CORS), o navegador envia os cabeçalhos de solicitação e controle de acesso ao mesmo tempo. Geralmente, são solicitações de dados GET e são consideradas de baixo risco.

No entanto, algumas solicitações HTTP são consideradas complexas e exigem a confirmação do servidor antes que a solicitação real seja enviada. O processo de pré-aprovação é chamado de solicitação preflight.

Solicitações complexas entre origens

Solicitações entre origens são complexas se usarem qualquer um dos seguintes:

• Métodos diferentes de GET, POST ou HEAD
• Cabeçalhos diferentes de Accept-Language, Accept ou Content-Language
• Cabeçalhos Content-Type diferentes de multipart/form-data, application/x-www-form-urlencoded ou text/plain

Assim, por exemplo, solicitações para excluir ou modificar dados existentes são consideradas complexas.

Como funcionam as solicitações de preflight

Navegadores criam solicitações preflight quando estas são necessárias. É uma solicitação OPTIONS como a seguinte.

OPTIONS /data HTTP/1.1 Origem: https://example.com Access-Control-Request-Method: DELETE

O navegador envia a solicitação preflight antes da mensagem de solicitação real. O servidor deve responder à solicitação preflight com informações sobre as solicitações entre origens que o servidor está disposto a aceitar do URL do cliente. Os cabeçalhos de resposta do servidor devem incluir o seguinte:

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

Um exemplo de resposta do servidor é fornecido abaixo.

HTTP/1.1 200 OK Access-Control-Allow-Headers: Content-Type Access-Control-Allow-Origin: https://news.example.com Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

Às vezes, a resposta preflight inclui um cabeçalho Access-Control-Max-Age adicional. Essa métrica especifica a duração (em segundos) para o navegador armazenar em cache os resultados preflight no navegador. O armazenamento em cache permite que o navegador envie várias solicitações complexas entre solicitações preflight. Ele não precisará enviar outra solicitação preflight até que o tempo especificado por max-age termine.

 

Você deve observar o seguinte ao configurar o compartilhamento de recursos entre origens (CORS) no seu servidor.

Defina listas de acesso apropriadas

É sempre melhor conceder acesso a domínios individuais usando listas separadas por vírgula. Evite usar curingas, a menos que você queira tornar a API pública. Caso contrário, usar curingas e expressões regulares poderá criar vulnerabilidades.

Por exemplo, digamos que você escreva uma expressão regular que conceda acesso a todos os sites com o sufixo permitted-website.com. Com uma única expressão, você concede acesso a api.permitted-website.com e news.permitted-website.com. Porém, você também inadvertidamente concede acesso a sites não autorizados que podem usar domínios como maliciouspermitted-website.com.

Evite usar origem nula na sua lista

Alguns navegadores enviam o valor null no cabeçalho da solicitação para determinados cenários, como solicitações de arquivo ou solicitações do host local.

No entanto, você não deve incluir o valor nulo na sua lista de acesso. Ele também apresenta riscos de segurança, pois solicitações não autorizadas contendo cabeçalhos nulos podem obter acesso.