Usar a CDN do Azure com o CORS
Importante
A CDN do Azure Standard (clássica) será desativada em 30 de setembro de 2027. Para evitar qualquer interrupção de serviço, é importante migrar seus perfis da CDN do Azure Standard (clássica) para a camada Azure Front Door Standard ou Premium até 30 de setembro de 2027. Para obter mais informações, confira CDN do Azure Standard (clássica).
O CDN do Azure da Edgio será desativado em 4 de novembro de 2025. Você deve migrar sua carga de trabalho para o Azure Front Door antes desta data para evitar interrupção do serviço.. Para obter mais informações, veja Perguntas frequentes sobre a aposentadoria do CDN do Azure da Edgeo.
O que é o CORS?
O CORS (compartilhamento de recursos entre origens) é um recurso HTTP que permite que um aplicativo web em execução em um domínio acesse recursos em outro domínio. Para reduzir a possibilidade de ataques de script entre sites, todos os navegadores modernos implementam uma restrição de segurança conhecida como política de mesma origem. Essa restrição impede uma página da Web de chamar APIs em um domínio diferente. O CORS fornece uma maneira segura para permitir que uma origem (o domínio de origem) chame APIs em outra origem.
Como ele funciona
Há dois tipos de solicitações CORS, solicitações simples e solicitações complexas.
Para solicitações simples:
O navegador envia a solicitação CORS com um cabeçalho extra de solicitação HTTP de Origem. O valor do cabeçalho da solicitação é a origem que serviu a página pai, que é definida como a combinação de protocolo, domínio e porta. Quando uma página a partir de HTTPS://www.contoso.com tentasse acessar os dados de um usuário na origem fabrikam.com, o cabeçalho de solicitação a seguir seria enviado para fabrikam.com:
Origin: https://www.contoso.comO servidor poderá responder com um dos seguintes cabeçalhos:
Um cabeçalho Access-Control-Allow-Origin em sua resposta indicando qual site de origem é permitido. Por exemplo:
Access-Control-Allow-Origin: https://www.contoso.comUm código de erro HTTP como 403 se o servidor não permite a solicitação entre origens depois de verificar o cabeçalho de origem
Um cabeçalho Access-Control-Allow-Origin com um caractere curinga que permite todas as origens:
Access-Control-Allow-Origin: *
Para solicitações complexas:
Uma solicitação complexa é uma solicitação CORS onde o navegador é necessário para enviar um solicitação de simulação (ou seja, uma investigação preliminar) antes de enviar a solicitação CORS real. A solicitação de simulação pede a permissão do servidor se o CORS originais da solicitação pode continuar e é um OPTIONS solicitação para a mesma URL.
Dica
Para obter mais detalhes sobre fluxos CORS e armadilhas comuns, consulte o guia CORS para APIs REST.
Cenários de origem única ou curinga
O CORS na Azure CDN funciona automaticamente sem configurações extras quando o cabeçalho Access-Control-Allow-Origin é definido como um caractere curinga (*) ou uma origem individual. A CDN armazena a primeira resposta em cache, e as solicitações seguintes usam o mesmo cabeçalho.
Se já tiverem sido feitas solicitações à CDN antes de o CORS ser definido na origem, você precisará limpar o conteúdo no conteúdo do ponto de extremidade para recarregar o conteúdo com o cabeçalho Access-Control-Allow-Origin.
Cenários de várias origens
Se você precisar permitir que uma lista específica de origens seja permitida para o CORS, isso será um pouco mais complicado. O problema ocorre quando a CDN armazena o cabeçalho Access-Control-Allow-Origin em cache para a primeira origem do CORS. Quando outra origem do CORS faz uma solicitação seguinte, a CDN fornece o cabeçalho Access-Control-Allow-Origin armazenado em cache, que não é correspondente. Há várias maneiras de corrigir este problema.
Perfis padrão do Azure CDN
Perfis padrão CDN do Azure da Microsoft, você pode criar uma regra no Mecanismo de regras padrão para verificar o cabeçalho de origem na solicitação. Se ela é uma origem válida, a regra define o cabeçalho Access-Control-Allow-Origin com o valor desejado. Neste caso, o cabeçalho Access-Control-Allow-Origin do servidor de origem do arquivo é ignorado e o mecanismo de regras do CDN gerencia completamente as origens CORS permitidas.
Dica
Você pode incluir ações à sua regra para modificar cabeçalhos de resposta adicionais, como Access-Control-Allow-Methods.
CDN Premium do Azure do Edgio
Usando o mecanismo de regras do Edgio Premium, você precisa criar uma regra para verificar o cabeçalho Origin na solicitação. Se ela é uma origem válida, a regra define o cabeçalho Access-Control-Allow-Origin com a origem fornecida na solicitação. Se a origem especificada no cabeçalho Origem não é permitida, a regra deve omitir o cabeçalho Access-Control-Allow-Origin, o que faz com que o navegador rejeite a solicitação.
Há duas maneiras de resolver esse problema com o mecanismo de regras Premium. Em ambos os casos, o cabeçalho Access-Control-Allow-Origin do servidor de origem do arquivo é ignorado e o mecanismo de regras da CDN gerencia completamente as origens CORS permitidas.
Uma expressão regular com todas as origens válidas
Nesse caso, você criará uma expressão regular que inclui todas as origens que deseja permitir:
https?:\/\/(www\.contoso\.com|contoso\.com|www\.microsoft\.com|microsoft.com\.com)$
Dica
CDN Premium do Azure do Edgio usa as Expressões Regulares Compatíveis com o Perl como seu mecanismo de expressões regulares. Você pode usar uma ferramenta, como Expressões Regulares 101, para validar sua expressão regular. Observe que o caractere "/" é válido em expressões regulares e não precisa ter um caractere de escape. No entanto, adicionar um caractere de escape a esse caractere é considerado uma prática recomendada e é esperado por alguns validadores de regex.
Se a expressão regular for correspondente, a regra substituirá o cabeçalho Access-Control-Allow-Origin (se houver) da origem pela origem que enviou a solicitação. Você também pode adicionar outros cabeçalhos CORS, como Access-Control-Allow-Methods.
Solicitar a regra de cabeçalho para cada origem.
Em vez de expressões regulares, você pode criar uma regra separada para cada origem que deseja permitir usando a condição de correspondência Request Header Wildcard. Assim como acontece com o método de expressão regular, apenas o mecanismo de regras define os cabeçalhos do CORS.
Dica
No exemplo, o uso do caractere curinga * instrui o mecanismo de regras a fazer a correspondência de HTTP e HTTPS.