Se você já desenvolveu alguma aplicação web, você provavelmente já deu de cara com esse erro no console do navegador:
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
.
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.
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.
Este cabeçalho pode ter como valor:
- Uma origem permitida:
Access-Control-Allow-Origin: http://instagram.com
; ou - 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.
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 com determinados cabeçalhos, ou para uso de 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 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.
Top comments (0)