O que é uma requisição Preflight? Verificações CORS explicadas

Scrapeless Agent Browser executa fluxos de trabalho baseados em navegador nos quais as páginas de destino continuam sujeitas às regras de requisição entre origens do navegador.

Um preflight pergunta sobre uma requisição de navegador proposta

Um preflight CORS é uma requisição HTTP OPTIONS que um navegador envia para verificar se um servidor permite uma requisição entre origens específica. Ele descreve a origem chamadora, o método pretendido e os nomes de campos de requisição relevantes. Se a resposta do servidor satisfaz as verificações do navegador, o navegador pode prosseguir com a requisição da aplicação. O preflight é uma negociação de permissão no modelo de acesso do navegador, não a própria operação da aplicação.

O modelo CORS do Fetch Standard define esse comportamento. Uma origem é determinada por esquema, host e porta, então duas URLs podem pertencer a origens diferentes mesmo quando seus domínios parecem muito parecidos. Um frontend servido a partir de uma origem e uma API servida a partir de outra podem precisar de configuração CORS para que o JavaScript no navegador acesse a resposta da API.

CORS significa Cross-Origin Resource Sharing. Ele permite que um servidor faça opt-in para certas interações entre origens no navegador dentro do modelo de segurança same-origin. A política é aplicada pelo navegador, enquanto o servidor declara o que permite por meio de campos de resposta. Uma aplicação não consegue resolver uma requisição entre origens negada adicionando campos de permissão de resposta à sua própria requisição de saída.

Nem toda requisição entre origens passa por preflight

Algumas requisições entre origens se enquadram nas regras de métodos e campos com safelist em CORS e não precisam de preflight. As condições exatas incluem o método, os valores dos campos de requisição e o comportamento relevante do Fetch. Uma requisição GET com um campo que não está na safelist pode exigir preflight, enquanto um POST adequadamente restrito pode evitá-lo. O nome do método sozinho é, portanto, uma regra de decisão incompleta.

Acionadores comuns incluem métodos fora do conjunto com safelist, um campo Authorization e um tipo de conteúdo JSON que não está entre os media types com safelist. Esses exemplos explicam muitos rastros de rede no navegador, mas o teste completo pertence às regras do Fetch. Evite descrever todos os GETs como simples ou todos os POSTs como passando por preflight. Inspecione a configuração real da requisição.

A explicação de requisição preflight do navegador distingue a requisição preliminar OPTIONS da requisição real. Um servidor pode receber requisições que não precisam de preflight enquanto o navegador ainda se recusa a expor suas respostas ao JavaScript. Portanto, CORS não deve ser descrito como uma barreira universal que impede toda requisição entre origens de alcançar um servidor.

O navegador descreve o método e os campos pretendidos

O preflight inclui Origin para identificar a origem chamadora. Access-Control-Request-Method nomeia o método que o navegador propõe usar para a requisição real. Access-Control-Request-Headers lista os nomes de campos de requisição relevantes que precisam de permissão. Essas são descrições de uma operação proposta; elas não significam que a própria requisição OPTIONS realiza essa operação ou carrega o payload completo da aplicação.

O servidor responde com campos descrevendo origens, métodos e campos de requisição permitidos, conforme aplicável. O navegador avalia essas declarações em relação à requisição proposta. Um handler OPTIONS genérico bem-sucedido é insuficiente quando omite a permissão necessária ou concede um método diferente. Mantenha a comparação precisa para que o diagnóstico identifique qual parte da política falhou.

Uma requisição de aplicação continua sendo uma troca separada. Quando ela chega, a API valida suas credenciais, parâmetros e permissões. Sua resposta também precisa dos campos CORS apropriados para acesso pelo navegador. Passar na verificação preliminar não torna bem-sucedida uma operação de aplicação posterior não autorizada ou malformada, e não isenta a resposta real do tratamento pela política de origem.

Credenciais tornam a configuração de origem mais específica

Requisições com credenciais do navegador exigem que a política CORS de resposta corresponda ao modo de credenciais e à origem solicitante. Um curinga de origem permitida não pode ser usado como substituto geral para uma origem explícita ao expor uma resposta com credenciais. O servidor também precisa da permissão de credencial apropriada. Configure esses campos a partir de uma política de origem controlada em vez de refletir entradas arbitrárias sem verificá-las.

Cookies introduzem regras adicionais além de CORS. Uma requisição pode satisfazer sua política CORS enquanto a entrega de cookies é restringida por atributos de cookie ou comportamento de privacidade do navegador. Inversamente, a presença de um cookie não estabelece que um servidor aceitou a sessão. Mantenha entrega de cookies, exposição via CORS e autorização da aplicação como questões de diagnóstico separadas.

O Orientação sobre credenciais CORS e campos de resposta cobre essas interações. Um preflight normalmente exclui credenciais sob o modelo padrão, mesmo quando a requisição de aplicação proposta inclui credenciais. Middleware que exige uma sessão autenticada para toda requisição OPTIONS pode, portanto, bloquear a negociação antes que a requisição de aplicação autorizada seja avaliada.

Um preflight com falha e uma chamada de API com falha são diferentes

Um preflight com falha pode impedir o navegador de enviar a requisição de aplicação proposta. Nesse caso, a rota da API pode não ter nenhuma operação de aplicação correspondente em seus logs, enquanto o gateway registra OPTIONS. Comece o diagnóstico determinando qual troca ocorreu. Um erro CORS genérico no console não identifica por si só se roteamento, política de campos, credenciais ou a própria resposta causou o problema.

Se a requisição de aplicação realmente chegou ao servidor, inspecione seu próprio status e campos de resposta CORS. Um serviço pode retornar um corpo de erro útil que o JavaScript do navegador não consegue ler porque a resposta de erro omitiu a permissão de origem. Aplique a política CORS pretendida de forma consistente a respostas de sucesso e de erro suportadas, preservando a autorização normal da API. Não transforme toda falha em uma mudança na lista de origens permitidas.

Uma requisição OPTIONS nem sempre é um preflight CORS. HTTP define OPTIONS mais genericamente como uma requisição sobre opções de comunicação para um recurso alvo. As semânticas de HTTP OPTIONS e a presença dos campos de requisição CORS ajudam a distinguir um preflight de navegador de uma requisição OPTIONS emitida manualmente ou de outra verificação de infraestrutura. Diagnostique a requisição que realmente está presente em vez de apenas seu nome de método.

O cache de preflight tem seu próprio ciclo de vida

Os navegadores podem armazenar em cache uma permissão de preflight bem-sucedida de acordo com as regras aplicáveis, incluindo Access-Control-Max-Age e limites de implementação. Esse cache é distinto do conteúdo de resposta de aplicação armazenado em cache normalmente. Isso pode explicar por que uma requisição posterior aparece sem uma nova troca OPTIONS. A ausência de um preflight em um traço não prova que a requisição nunca exigiria um.

O escopo do cache também depende do contexto da requisição, origem, alvo, método e permissões de campos. Uma verificação bem-sucedida para uma rota ou conjunto de campos não é uma aprovação geral para toda operação no host. Ao depurar, registre o método proposto e os campos da requisição junto com a URL de destino. Comparar traços sem esses detalhes pode fazer diferenças normais de política parecerem inconsistentes.

Um servidor que retorna permissões de origem diferentes para chamadores diferentes deve levar em conta o comportamento de cache intermediário. As regras de seleção de cache HTTP explicam como a variação da resposta deve ser representada para evitar reutilização inadequada. Quando uma resposta de aplicação varia por Origin, configure a variação de cache relevante em vez de permitir que a declaração de origem de um chamador seja reutilizada indiscriminadamente para outro.

Depure a troca desde a origem até a aplicação

Comece com a origem completa da página de chamada e o alvo final da API. Verifique se um redirecionamento ou gateway roteia OPTIONS de forma diferente do método da aplicação. Compare o método e os campos propostos com a política explícita do servidor. Em seguida, inspecione se a requisição real chegou e se sua resposta inclui os campos CORS esperados. Essa sequência localiza a falha sem enfraquecer a política indiscriminadamente.

Um cliente de linha de comando pode ajudar a inspecionar uma resposta HTTP, mas ele não reproduz por si só a aplicação de CORS pelo navegador. Uma requisição bem-sucedida a partir de um processo de backend prova apenas que esse processo obteve uma resposta sob seu próprio contexto de rede e credenciais. O navegador ainda avalia as regras de origem. Mudar o cliente para um modo que oculte a resposta não cria permissão para ler conteúdo de resposta protegido.

Mantenha os diagnósticos sanitizados. Valores de autorização e cookies não devem ser colados em traços compartilhados. Normalmente os nomes de campos, origem, rota, método, status e valores dos campos de permissão são suficientes para explicar um desencontro de CORS. Se a aplicação toca registros pessoais, capture apenas o conteúdo mínimo necessário para a investigação autorizada e mantenha essa captura dentro do limite de acesso apropriado.

Automação de navegador ainda segue o modelo de origem

Mantenha a conexão de controle do navegador separada do JavaScript em execução dentro da página de destino. Um cliente de automação acessando um navegador em nuvem e um script de página acessando uma API de outra origem são interações de rede diferentes. O sucesso no canal de controle não pode provar que a chamada de API da página passou pelo CORS. Observe a requisição de destino e sua resposta correspondente ao explicar o que a página pôde acessar.

O Fluxo de trabalho de requisição Fetch é uma leitura relacionada para clientes HTTP, e preços do Scrapeless cobre o uso do serviço de navegador. Para um teste autorizado, defina a origem esperada, a operação e o resultado visível na página. Uma observação de navegador aprovada deve confirmar tanto a troca de políticas quanto o comportamento resultante da aplicação, em vez de parar em um status OPTIONS.

Conclusão

Um preflight avalia uma operação específica proposta entre origens antes que certas requisições do navegador prossigam. Inspecione a origem chamadora, o método, os nomes de campos, o modo de credenciais e ambas as respostas. Mantenha as verificações de permissão do navegador separadas da autorização da API e diagnostique a política no componente que é responsável pela troca que falhou.