CORS
O que é o CORS?
Por motivos de segurança, os navegadores restringem as solicitações de origem cruzada iniciadas a partir de scripts. Isso significa que uma aplicação Web só pode solicitar recursos de sua origem. O mecanismo CORS permite que os navegadores enviem XMLHttpRequest para servidores em outros domínios e solicitem acesso aos recursos lá.
Existem dois tipos de solicitações CORS:
- Solicitações simples
As solicitações simples devem atender às seguintes condições:
- O método de requisição é HEAD, GET ou POST.
- O cabeçalho da solicitação contém apenas os seguintes campos:
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type (application/x-www-form-urlencoded, multipart/form-data ou text/plain)
No cabeçalho de uma solicitação simples, os navegadores adicionam automaticamente o campo Origin para especificar a origem (incluindo o protocolo, o domínio e a porta) da solicitação. Depois de receber tal solicitação, o servidor de destino determina se a solicitação é segura e pode ser aceita com base na origem. Se o servidor enviar uma resposta contendo o campo Access-Control-Allow-Origin, o servidor aceitará a solicitação.
- Solicitações não tão simples
Solicitações que não atendem às condições para solicitações simples são solicitações não tão simples.
Antes de enviar uma solicitação não tão simples, os navegadores enviam uma solicitação de simulação HTTP ao servidor de destino para confirmar se a origem da página da Web está na lista de origem permitida e para confirmar quais métodos de solicitação HTTP e campos de cabeçalho podem ser usados. Se a solicitação de simulação for bem-sucedida, os navegadores enviam solicitações simples para o servidor.
Configurar o CORS
O CORS está desativado por padrão. Para habilitar o CORS para uma API, execute as operações descritas nesta seção. Para personalizar cabeçalhos de solicitação, métodos de solicitação e origens permitidos para acesso entre domínios, crie um plug-in CORS.
- Solicitações CORS simples
Ao criar uma API, ative o CORS na página de configuração da solicitação da API. Para obter mais informações, consulte Solicitação simples.
Figura 2 CORS
- Solicitações CORS não tão simples
Se sua API receber solicitações não tão simples, crie outra API que será acessada usando o método OPTIONS no mesmo grupo da API de destino para receber solicitações de simulação.
Siga este procedimento para definir a API de solicitação de simulação. Para obter mais informações, consulte Solicitações não tão simples.
- Na página Set Basic Information, selecione None para ignorar a autenticação de segurança.
Figura 3 Nenhuma autenticação
- Na página Define API Request, execute as seguintes configurações:
- Protocol: o mesmo protocolo usado pela API com o CORS ativado.
- Path: insira uma barra (/).
- Method: selecione OPTIONS.
- CORS: ativado.
Figura 4 Definição da solicitação da API
- Selecione o tipo de back-end Mock.
Figura 5 Serviço de back-end Mock
- Na página Set Basic Information, selecione None para ignorar a autenticação de segurança.
Solicitação simples
Ao criar uma API que receberá solicitações simples, ative o CORS para a API.
Cenário 1: se o CORS estiver habilitado e a resposta do back-end não contiver um cabeçalho CORS, o APIG tratará solicitações de qualquer domínio e retornará o cabeçalho Access-Control-Allow-Origin. Por exemplo:
Solicitação enviada por um navegador e contendo o campo de cabeçalho Origem:
GET /simple HTTP/1.1 Host: www.test.com Origin: http://www.cors.com Content-Type: application/x-www-form-urlencoded; charset=utf-8 Accept: application/json Date: Tue, 15 Jan 2019 01:25:52 GMT
Origin: este campo é necessário para especificar a origem (http://www.cors.com neste exemplo) da solicitação. O APIG e o serviço de back-end determinam, com base na origem, se a solicitação é segura e pode ser aceita.
Resposta enviada pelo serviço de back-end:
HTTP/1.1 200 OK Date: Tue, 15 Jan 2019 01:25:52 GMT Content-Type: application/json Content-Length: 16 Server: api-gateway {"status":"200"}
Resposta enviada pelo APIG:
HTTP/1.1 200 OK Date: Tue, 15 Jan 2019 01:25:52 GMT Content-Type: application/json Content-Length: 16 Server: api-gateway X-Request-Id: 454d689fa69847610b3ca486458fb08b Access-Control-Allow-Origin: * {"status":"200"}
Access-Control-Allow-Origin: este campo é obrigatório. O asterisco (*) significa que o APIG lida com solicitações enviadas de qualquer domínio.
Cenário 2: se o CORS estiver habilitado e a resposta do back-end contiver um cabeçalho CORS, o cabeçalho substituirá o adicionado pelo APIG. As seguintes mensagens são usadas como exemplos:
Solicitação enviada por um navegador e contendo o campo de cabeçalho Origem:
GET /simple HTTP/1.1 Host: www.test.com Origin: http://www.cors.com Content-Type: application/x-www-form-urlencoded; charset=utf-8 Accept: application/json Date: Tue, 15 Jan 2019 01:25:52 GMT
Origin: este campo é necessário para especificar a origem (http://www.cors.com neste exemplo) da solicitação. O APIG e o serviço de back-end determinam, com base na origem, se a solicitação é segura e pode ser aceita.
Resposta enviada pelo serviço de back-end:
HTTP/1.1 200 OK Date: Tue, 15 Jan 2019 01:25:52 GMT Content-Type: application/json Content-Length: 16 Server: api-gateway Access-Control-Allow-Origin: http://www.cors.com {"status":"200"}
Access-Control-Allow-Origin: indica que o serviço de back-end aceita solicitações enviadas do http://www.cors.com.
Resposta enviada pelo APIG:
HTTP/1.1 200 OK Date: Tue, 15 Jan 2019 01:25:52 GMT Content-Type: application/json Content-Length: 16 Server: api-gateway X-Request-Id: 454d689fa69847610b3ca486458fb08b Access-Control-Allow-Origin: http://www.cors.com {"status":"200"}
O cabeçalho CORS na resposta de back-end substitui o da resposta do APIG.
Solicitações não tão simples
Ao criar uma API que receberá solicitações não tão simples, habilite o CORS para a API seguindo as instruções em Configurar o CORS e crie outra API que será acessada usando o método OPTIONS.
Se você usar o plug-in CORS para uma API, não precisará criar outra API que use o método OPTIONS.
Os parâmetros de solicitação de uma API acessada usando o método OPTIONS devem ser definidos da seguinte forma:
- API Group: o mesmo grupo ao qual a API com CORS habilitado pertence.
- Security Authentication: selecione None. Nenhuma autenticação é necessária para solicitações recebidas pela nova API, independentemente do modo de autenticação de segurança selecionado.
- Protocol: o mesmo protocolo usado pela API com o CORS ativado.
- Path: insira uma barra (/) ou selecione o caminho que foi definido ou corresponda à API com CORS ativado.
- Method: selecione OPTIONS.
- CORS: ativado.
A seguir estão exemplos de solicitações e respostas enviadas para ou de um back-end mock.
Solicitação enviada de um navegador para uma API que é acessada usando o método OPTIONS:
OPTIONS /HTTP/1.1 User-Agent: curl/7.29.0 Host: localhost Accept: */* Origin: http://www.cors.com Access-Control-Request-Method: PUT Access-Control-Request-Headers: X-Sdk-Date
- Origin: esse campo é necessário para especificar a origem da qual a solicitação foi enviada.
- Access-Control-Request-Method: este campo é necessário para especificar os métodos HTTP a serem usados pelas solicitações simples subsequentes.
- Access-Control-Request-Headers: esse campo é opcional e usado para especificar os campos de cabeçalho adicionais nas solicitações simples subsequentes.
Resposta enviada pelo back-end: nenhuma
Resposta enviada pelo APIG:
HTTP/1.1 200 OK Date: Tue, 15 Jan 2019 02:38:48 GMT Content-Type: application/json Content-Length: 1036 Server: api-gateway X-Request-Id: c9b8926888c356d6a9581c5c10bb4d11 Access-Control-Allow-Origin: * Access-Control-Allow-Headers: X-Stage,X-Sdk-Date,X-Sdk-Nonce,X-Proxy-Signed-Headers,X-Sdk-Content-Sha256,X-Forwarded-For,Authorization,Content-Type,Accept,Accept-Ranges,Cache-Control,Range Access-Control-Expose-Headers: X-Request-Id,X-Apig-Latency,X-Apig-Upstream-Latency,X-Apig-RateLimit-Api,X-Apig-RateLimit-User,X-Apig-RateLimit-App,X-Apig-RateLimit-Ip,X-Apig-RateLimit-Api-Allenv Access-Control-Allow-Methods: GET,POST,PUT,DELETE,HEAD,OPTIONS,PATCH Access-Control-Max-Age: 172800
- Access-Control-Allow-Origin: este campo é obrigatório. O asterisco (*) significa que o APIG lida com solicitações enviadas de qualquer domínio.
- Access-Control-Allow-Headers: este campo é obrigatório se estiver contido na solicitação. Indica todos os campos de cabeçalho que podem ser usados durante o acesso entre origens.
- Access-Control-Expose-Headers: estes são os campos de cabeçalho de resposta que podem ser visualizados durante o acesso entre regiões.
- Access-Control-Allow-Methods: este campo é necessário para especificar quais métodos de solicitação HTTP o APIG suporta.
- Access-Control-Max-Age: este campo é opcional e usado para especificar o período de tempo (em segundos) durante o qual o resultado da comprovação permanece válido. Não serão enviadas mais solicitações de simulação dentro do período especificado.
Solicitação enviada por um navegador e contendo o campo de cabeçalho Origin:
PUT /simple HTTP/1.1 Host: www.test.com Origin: http://www.cors.com Content-Type: application/x-www-form-urlencoded; charset=utf-8 Accept: application/json Date: Tue, 15 Jan 2019 01:25:52 GMT
Resposta enviada pelo back-end:
HTTP/1.1 200 OK Date: Tue, 15 Jan 2019 01:25:52 GMT Content-Type: application/json Content-Length: 16 Server: api-gateway {"status":"200"}
Resposta enviada pelo APIG:
HTTP/1.1 200 OK Date: Tue, 15 Jan 2019 01:25:52 GMT Content-Type: application/json Content-Length: 16 Server: api-gateway X-Request-Id: 454d689fa69847610b3ca486458fb08b Access-Control-Allow-Origin: * {"status":"200"}