Como REALMENTE o CORS funciona: Entendendo de uma vez por todas
Published: 2020-05-18 14:47:18

Se você já desenvolveu alguma aplicação web, você provavelmente já deu de cara com esse erro no console do navegador:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/jdk4zort0fmt2vcdjil0.png)

Esse erro deriva de um mecanismo de segurança implementado pelos navegadores, chamado ***Same-Origin Policy***, (política de mesma origem). A política de mesma origem restringe a forma de como um documento ou script carregado de uma origem pode interagir com um recurso de outra origem. É um mecanismo crítico de segurança para isolar documentos potencialmente maliciosos, e evitar falsificação de solicitações entre sites, mais conhecido como ataque **CSRF (*cross-site request forgery*)**.

Esse é um tipo de ataque comum, onde um site mal-intencionado tenta tirar proveito do sistema de armazenamento de cookies do navegador. Para cada solicitação de HTTP em um domínio, o navegador anexa todos os cookies HTTP associados a esse domínio. Isso é especialmente útil para autenticação e configuração de sessões. Por exemplo, é possível que você faça login em um aplicativo da web como o `instagram.com`. Nesse caso, seu navegador armazenaria um cookie de sessão relevante para o domínio `instagram.com`.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/o0csgqjah0ule62euurz.png)

Após armazenado, sempre que um usuário acessar novamente o `instagram.com`, não será necessário fazer login novamente, já que API reconhecerá o cookie da sessão armazenada, nas requisições futuras (isso se a API usar apenas o cookie como mecanismo de autenticação). 

O único problema é que o navegador inclui automaticamente quaisquer cookies relevantes armazenados para um domínio quando outra solicitação é feita para esse domínio exato. Portanto, se o usuário clicar em um pop-up, por exemplo, abrindo `site-do-mal.com`, esse site também tem a capacidade de enviar uma solicitação para `instagram.com`. Como a solicitação está indo para o domínio `instagram.com`, o navegador inclui os cookies relevantes. O site do mal envia o cookie da sessão e obtém acesso autenticado ao Instagram. Sua conta foi invadida com sucesso com um ataque de falsificação de solicitação entre sites.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/azq9bay6zu3875ysd47q.png)

Felizmente, nessa situação, o navegador intervém e impede que o código malicioso faça uma solicitação de API como esta, e dispara o famoso erro de CORS, que você viu na primeira imagem.

## **E que raios então é CORS?**

CORS significa *Cross-Origin Resource Sharing* (Compartilhamento de recursos com origens diferentes), e é o padrão que flexibiliza a política de mesma origem, fazendo com que aplicações possam acessar recursos de outras origens.

Para que o navegador consiga fazer ou não o bloqueio da política de mesma origem, ele precisA verificar se a origem da aplicação web e do recurso externo (url da requisição) são as mesmas. E quando falamos de origem, estamos falando da combinação entre protocolo (http://), domínio (instagram.com) e porta (80 é a porta padrão quando não especificado). 

Então, o navegador adiciona automaticamente, para toda requisição, um cabeçalho informando a origem da aplicação front-end: `Origin: http://site-do-mal.com`. O servidor então, baseado nessa requisição, envia uma resposta contendo o cabeçalho `Access-Control-Allow-Origin`, que indica se os recursos da resposta podem ser compartilhados com a origem informada.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/oj6tzz7oxy2nt6vjpkmt.png)

Este cabeçalho pode ter como valor:

1. Uma origem permitida: `Access-Control-Allow-Origin: http://instagram.com`; ou
2. Um `*`, que indica que qualquer origem pode acessar determinado recurso: `Access-Control-Allow-Origin: *`

> Nota: É recomendado cuidar com o uso desses cabeçalhos, já que o uso incorreto pode inutilizar a política de mesma origem, facilitando ataques **CSRF**

Com esse cabeçalho "em mãos", o navegador pode comparar com o valor de origem do front-end, e bloquear a solicitação caso os valores não sejam compatíveis.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/sfwc5tm93dutjqw5kdl4.png)

Além disso, para métodos de requisição HTTP que podem causar efeitos colaterais nos dados do servidor (em particular, para métodos HTTP diferentes de [GET](https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Methods/GET) com determinados cabeçalhos, ou para uso de [POST](https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Methods/POST) com certos `Content-types`), a especificação exige que navegadores "pré-enviem" a requisição, solicitando os métodos suportados pelo servidor (e pra informar isso, o servidor utiliza o cabeçalho `Access-Control-Allow-Methods`) com um método de requisição HTTP [OPTIONS](https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Methods/OPTIONS) e, após a "aprovação", o servidor envia a requisição verdadeira com o método de requisição HTTP correto. 

Então, resumindo, CORS nada mais é do que a configuração de cabeçalhos de resposta `Access-Control-*` (do lado do servidor), que informam se uma requisição (baseado em origem e métodos HTTP), pode ou não acessar determinado recurso, flexibilizando assim, a política de mesma origem (***Same-Origin Policy***), que tem a intenção principal de evitar ataques **CSRF**.