Lidando com CORS em aplicativos da Web

Shutterstock / Gorodenkoff

CORS é um mecanismo de navegador que permite aos servidores especificar as origens de terceiros que podem solicitar recursos deles. É uma proteção de segurança que ajuda a impedir que sites maliciosos roubem dados de outras origens.

CORS significa Cross-Origin Resource Sharing. Quando o CORS é usado para carregar um recurso, o navegador geralmente envia um “ preflight ” Solicitação HTTP OPTIONS. O servidor deve responder especificando as origens com as quais irá interagir. Ele também pode definir restrições adicionais, como os cabeçalhos HTTP que podem ser enviados.

O navegador verifica a origem atual e a solicitação de saída de acordo com as especificações do servidor. A solicitação pode continuar se todas as verificações forem aprovadas. Caso contrário, a solicitação original será cancelada. Você verá um aviso no console quando isso acontecer.

Quando o CORS é usado

Os navegadores aplicam o CORS para solicitações Ajax e Fetch. O mecanismo também será usado para fontes da web, texturas WebGL e desenhos de imagens de tela com drawImage (). Qualquer solicitação qualificada para uma origem de terceiros exigirá a realização de uma troca CORS.

O CORS não será aplicado se a solicitação for vista como “ simples ”. Uma solicitação simples deve ser GET, HEAD ou POST com um tipo de conteúdo text / plain, application / x-www-form-urlencoded ou multipart / form-data. Os únicos cabeçalhos de solicitação simples permitidos são Aceitar, Aceitar Idioma, Idioma do Conteúdo e Tipo de Conteúdo.

Se a solicitação não atender a todos os critérios acima, uma troca CORS será iniciada por navegadores modernos. É importante reconhecer que o CORS é uma tecnologia baseada em navegador – você nunca encontrará o CORS ao fazer solicitações manualmente, como com curl em seu terminal.

As trocas do CORS nem sempre enviam uma solicitação de comprovação OPTIONS. Um preflight é usado quando a solicitação causaria “ efeitos colaterais ” no servidor. Esse geralmente é o caso para métodos de solicitação diferentes de GET.

Imagine uma solicitação POST para / api / users / create. O servidor sempre criará um novo usuário, mas o navegador pode recusar o acesso à resposta se a solicitação estiver sujeita ao CORS. Ao enviar uma solicitação OPTIONS primeiro, o servidor tem a chance de recusar explicitamente a solicitação real. Isso garante que a conta do usuário não seja realmente criada.

Lidando com CORS do lado do cliente

Embora CORS seja uma tecnologia de navegador, você não pode influenciá-lo diretamente com o código do lado do cliente. Isso evita que scripts maliciosos evitem as proteções CORS para carregar dados de domínios de terceiros.

O CORS geralmente é transparente, então você não ficará ciente de que ele está em operação. Se uma troca de CORS falhar, seu código JavaScript verá um erro de rede genérico. Não é possível obter detalhes precisos do que deu errado, pois isso seria um risco à segurança. Os detalhes completos são registrados no console.

A única maneira de resolver uma falha de CORS é certificar-se de que seu servidor envie os cabeçalhos de resposta corretos. Vamos agora ver como isso é feito.

Lidando com CORS do lado do servidor

Em primeiro lugar, você deve se certificar de que seu servidor lida com as solicitações OPTIONS corretamente. Pode ser necessário criar uma nova rota em sua estrutura da web. Geralmente, você precisará aceitar solicitações OPTIONS para cada endpoint que possa receber uma solicitação de origem cruzada de um navegador. A resposta não precisa ter um corpo, mas deve incluir cabeçalhos específicos que informam ao navegador como proceder.

Comece adicionando o cabeçalho Access-Control-Allow-Origin. Isso especifica a origem de terceiros que tem permissão para se comunicar com seu terminal. Apenas uma origem pode ser especificada; você pode lidar com origens múltiplas definindo dinamicamente o valor do cabeçalho para a origem de onde a solicitação foi enviada. Você pode obter a origem atual no cabeçalho da solicitação Origin.

Access-Control-Allow-Origin aceita * como um valor curinga especial. Isso permitirá solicitações CORS de todas as origens. Tome cuidado ao usar este – ser específico com as origens permitidas oferece mais controle e evita que scripts maliciosos solicitem dados do seu servidor.

O Access-Control-Allow-Origin deve ser incluído na resposta do seu servidor à solicitação real, bem como na resposta OPTIONS. Depois que esse cabeçalho único for configurado, uma troca básica com um cliente de navegador de terceiros será permitida.

Especificando cabeçalhos de origem cruzada

As solicitações CORS geralmente suportam apenas o formato “ simples ” solicitar cabeçalhos listados acima. Se você precisar usar qualquer outro cabeçalho, como autorização ou um cabeçalho personalizado, seu servidor precisará permitir explicitamente na resposta de comprovação.

Defina o cabeçalho Access-Control-Allow-Headers. Seu valor deve ser uma lista separada por vírgulas de nomes de cabeçalho que serão aceitos com a solicitação real.

 Access-Control-Allow-Headers: Authorization, X-Custom-Header 

O navegador agora permitiria uma solicitação com os cabeçalhos Authorization ou X-Custom-Header para continuar.

Quando o navegador envia uma solicitação de comprovação CORS, ele enviará o cabeçalho Access-Control-Request-Headers. Ele contém a lista de cabeçalhos que serão enviados com a solicitação real. Seu código de servidor pode usar essas informações para determinar como responder à solicitação de comprovação.

Limitando a métodos de solicitação específicos

De maneira semelhante à especificação de cabeçalhos de solicitação, os endpoints do servidor podem definir quais métodos HTTP devem ter origem cruzada. Defina o cabeçalho Access-Control-Allow-Methods como uma lista separada por vírgulas de nomes de métodos.

 Métodos de permissão de controle de acesso: GET, POST, DELETE 

O navegador envia o cabeçalho Access-Control-Request-Method com preflight CORS. Isso permite que seu servidor saiba o método HTTP que será usado para fazer a solicitação final.

Cookies e credenciais

As solicitações CORS normalmente não enviam cookies, pois podem conter credenciais confidenciais de identificação do remetente. Se você precisar incluir cookies com uma solicitação de origem cruzada, deverá habilitar isso explicitamente em seu código do lado do cliente:

 fetch ("https: // localhost / demo", {mode: "cors", credentials: "include"}); 

Além disso, o servidor deve definir o cabeçalho de resposta Access-Control-Allow-Credentials: true para sinalizar sua concordância de que os cookies credenciados podem ser trocados.

Ao usar Access-Control-Allow-Credentials, você não pode usar o curinga (*) com Access-Control-Allow-Origin. O servidor deve especificar uma origem explícita em vez de proteger a privacidade do usuário. Se o curinga for enviado, o navegador falhará na solicitação com um erro CORS.

Cache de comprovação

Os preflight CORS OPTIONS adicionam uma sobrecarga a cada solicitação que você faz. Embora o atraso deva ser quase imperceptível em uma boa conexão de rede, ainda assim é um desperdício quando você chama o mesmo endpoint várias vezes em rápida sucessão.

Você pode instruir o navegador a armazenar em cache as respostas de comprovação definindo o cabeçalho Access-Control-Max-Age. O valor deve ser o tempo em segundos que o navegador tem permissão para armazenar a resposta em cache. Solicitações subsequentes para o mesmo endpoint dentro do período determinado não enviarão uma comprovação CORS.

Conclusão

O CORS pode parecer confuso na primeira vez que você o encontra. É uma tecnologia de navegador controlada pelas respostas do servidor. O CORS é inevitável e, ao mesmo tempo, incontrolável, a menos que você tenha acesso ao código do lado do servidor com o qual está interagindo novamente.

A implementação real do CORS é bastante direta. Certifique-se de que sua API ou CDN está enviando os cabeçalhos de resposta corretos, principalmente Access-Control-Allow-Origin. Você terá, então, uma comunicação segura entre origens que ajuda a se proteger contra agentes mal-intencionados.