Bom dia amigos!
Apresento a sua atenção a tradução do artigo "CS Visualized: CORS" de Lydia Hallie.
Todo desenvolvedor teve que lidar com um erro
Access to fetched has been blocked by CORS policy. Existem várias maneiras de resolver esse problema rapidamente. No entanto, vamos dar uma olhada mais de perto no que é uma política CORS.
Freqüentemente, precisamos exibir dados localizados em outro lugar. Antes de podermos fazer isso, o navegador deve enviar uma solicitação ao servidor para receber esses dados.
Digamos que desejamos obter informações sobre um usuário em nosso site
www.mywebsite.comde um servidor localizado no site api.website.com.
Excelente! Acabamos de enviar uma solicitação ao servidor e recebemos dados JSON em troca.
Agora, vamos tentar enviar uma solicitação semelhante a outro domínio. Em vez de enviar uma solicitação com, vamos
www.mywebsite.comenviá-la com www.anotherdomain.com.
O que aconteceu? Enviamos exatamente a mesma solicitação, mas desta vez o navegador mostra algum tipo de erro.
Estamos vendo o CORS em ação. Por que esse erro ocorreu e o que isso significa?
Política de origem comum
Existe algo na web chamado Política de Origem Genérica (doravante denominada POP). Por padrão, só temos acesso aos recursos que estão na mesma origem da origem de nossa solicitação. Por exemplo, podemos carregar uma imagem localizada em
https://mywebsite.com/image1.png.
Uma fonte é diferente quando está localizada em um (sub) domínio, protocolo ou porta diferente.
Legal, mas por que você precisa do POP?
Digamos que não exista e você clica acidentalmente em um link viral que sua tia enviou no Facebook. Este link redireciona você para um "site malicioso" que tem um iframe embutido que carrega o site do seu banco e efetua login com sucesso usando um cookie.
Os desenvolvedores do "site maligno" garantiram que ele tivesse acesso ao iframe e pudesse interagir com o conteúdo do DOM do site do seu banco para transferir fundos para sua conta em seu nome.
Sim ... este é um sério problema de segurança. Não queremos que ninguém tenha acesso a nada sem o nosso conhecimento.
Felizmente, existe o EPP. Esta política restringe o acesso a recursos de outras fontes.
Nesse caso, a fonte está
www.evilwebsite.comtentando acessar o recurso da fonte www.bank.com. O EPP bloqueia esse acesso e proíbe que desenvolvedores de sites mal-intencionados acessem seus dados bancários.
Ok, mas ... como isso funciona?
CORS do lado do cliente
Apesar do fato de que EPP só se aplica a scripts, os navegadores "estendem" a qualquer solicitação JavaScript: por padrão, só temos acesso a recursos de uma fonte.
Hmm, mas ... frequentemente precisamos obter recursos de outra fonte. Talvez nosso front-end precise ir para a API do servidor para carregar os dados. Para recuperar recursos de outras fontes com segurança, os navegadores implementam um mecanismo chamado CORS.
CORS significa Compartilhamento de Recursos de Origem Cruzada. Embora os navegadores não permitam recursos de outras fontes, podemos usar o CORS para alterar essa restrição enquanto nos mantemos seguros.
Os agentes de usuário (navegadores) podem usar CORS para resolver solicitações de origem cruzada que, de outra forma, seriam bloqueadas com base em alguns cabeçalhos de resposta HTTP.
Quando uma solicitação é feita para outra fonte, o cliente adiciona automaticamente um cabeçalho à solicitação HTTP
Origin. O valor deste cabeçalho é a origem da solicitação.
Para que o navegador permita a recuperação de recursos de outra fonte, a resposta do servidor também deve conter um cabeçalho específico.
CORS do lado do servidor
Como desenvolvedores de back-end, podemos permitir que outras fontes obtenham nossos recursos, incluindo cabeçalhos especiais começando com
Access-Control-*. Com base no valor de tais cabeçalhos, o navegador permite o compartilhamento de recursos.
Existem várias CORS-cabeçalhos, mas um deles é uma obrigação:
Access-Control-Allow-Origin.
O significado deste cabeçalho determina quais fontes nossos recursos podem receber.
Se estamos desenvolvendo um servidor que precisa ser acessível
https://mywebsite.com, temos que adicionar esse domínio ao cabeçalho Access-Control-Allow-Origin.
Ótimo. Este cabeçalho agora é adicionado à resposta do servidor enviada ao cliente. O EPP não nos impede mais de receber recursos
https://api.mywebsite.compor meio de solicitações enviadas de https://mywebsite.com.
O mecanismo CORS do navegador verifica se os valores do
Access-Control-Allow-Origincabeçalho da resposta e do cabeçalho da solicitação correspondem Origin.
Nesse caso, a origem de nossa solicitação é
https://www.mywebsite.como cabeçalho de resposta especificado na lista Access-Control-Allow-Origin.
Excelente. Agora podemos obter recursos de outras fontes. O que acontece se tentarmos fazer isso de uma fonte não listada em
Access-Control-Allow-Origin?
Sim, o CORS bloqueou o acesso aos recursos.
The 'Access-Control-Allow-Origin' header has a value
'https://www.mywebsite.com' that is not equal
to the supplied origin.
Nesse caso, a fonte
https://www.anotherwebsite.comnão está listada em Access-Control-Allow-Origin. O CORS negou com sucesso os dados solicitados.
CORS permite que você especifique
*fontes permitidas como um valor. Isso significa que os recursos estarão disponíveis para qualquer fonte, então tome cuidado.
Access-Control-Allow-OriginÉ um dos muitos títulos que podemos definir. O desenvolvedor de back-end pode configurar o CORS para permitir (negar) solicitações específicas.
Outro título comum é
Access-Control-Allow-Methods. O CORS permite apenas solicitações de outras fontes que foram enviadas usando os métodos especificados.
Nesse caso, apenas as solicitações enviadas pelos métodos GET, POST ou PUT são permitidas. Outros métodos como PATCH ou DELETE serão bloqueados.
O CORS os trata de uma maneira especial quando se trata de solicitações enviadas usando os métodos PUT, PATCH e DELETE. Essas consultas "complicadas" às vezes são chamadas de consultas de comprovação.
Pedidos preliminares
CORS trabalha com dois tipos de requisições: simples e provisórias. O que é uma consulta depende de alguns de seus valores.
Uma solicitação é simples se for enviada usando os métodos GET ou POST e não contém cabeçalhos adicionais. Qualquer outro pedido é preliminar.
Ok, mas o que significa pré-solicitação e por que essas solicitações são necessárias?
Antes de enviar a solicitação real, o cliente envia uma solicitação preliminar ao servidor com informações sobre a solicitação real: sobre seu método, cabeçalhos adicionais, incluindo
Access-Control-Request-*, etc.
O servidor recebe uma solicitação provisória e envia uma resposta provisória vazia contendo cabeçalhos CORS. O navegador recebe uma resposta provisória e verifica se a solicitação real será permitida.
Nesse caso, o navegador envia a solicitação real e recebe os dados em resposta.
Caso contrário, o CORS bloqueará a pré-solicitação e a solicitação real não será enviada. As pré-solicitações são uma ótima maneira de evitar que recursos sejam acessados e alterados no servidor. Isso protege o servidor de solicitações potencialmente indesejadas de outras fontes.
Para reduzir o número de solicitações repetidas, podemos armazenar em cache a resposta provisória adicionando um cabeçalho
Access-Control-Max-Ageà solicitação CORS. Isso evita o reenvio da solicitação preliminar.
Credenciais
Cookies, cabeçalhos de autorização e certificados TLS são instalados por padrão apenas para solicitações de uma única fonte. No entanto, podemos precisar usar essas permissões em uma solicitação de outra fonte. Talvez queiramos incluir cookies na solicitação que o servidor pode usar para identificar o usuário.
Embora o CORS não contenha permissões por padrão, podemos mudar isso com um cabeçalho
Access-Control-Allow-Credentials.
Se quisermos incluir cookies e outros cabeçalhos de autorização em nossa solicitação de outra fonte, precisamos definir o campo para um
withCredentialsvalor truena solicitação e adicionar o cabeçalho Access-Control-Allow-Credentialsà resposta.
Pronto, agora podemos incluir credenciais em nossas solicitações de outra fonte.
Espero que o artigo tenha sido útil para você. Obrigado pela atenção.