Leitura pública
- Entrada
- GET https://api.github.com/repos/octocat/hello-world
- Saída esperada
- Access-Control-Allow-Origin: *
Funciona a partir de qualquer site, sem autenticação, e é uma requisição simples: GET nunca dispara preflight.
exemplo de API com CORS liberado
Nem toda API bloqueia chamadas cross-origin. APIs públicas de leitura, feitas para ser consumidas por qualquer site ou aplicativo, costumam liberar CORS de propósito, e a API REST do GitHub é um dos exemplos mais conhecidos disso.
Funciona a partir de qualquer site, sem autenticação, e é uma requisição simples: GET nunca dispara preflight.
A maioria das APIs não expõe headers extras por padrão; sem esse header, o JavaScript da página só lê Content-Type, Cache-Control e outros da lista segura.
Esse é justamente o sintoma de um bloqueio de CORS: o navegador rejeita a promise do fetch() antes de entregar qualquer dado ao JavaScript, sem detalhar o motivo. O problema é que essa mesma mensagem genérica também aparece em falhas de DNS, TLS ou conectividade, então o navegador não distingue as duas coisas para o script que fez a chamada.
Os endpoints públicos de leitura, sim. Endpoints que exigem autenticação ou que modificam dados têm regras próprias e podem se comportar diferente dependendo do método de autenticação usado.
Para dados públicos e sem credenciais, sim, é um padrão comum e seguro. Nunca combine * com Access-Control-Allow-Credentials: true, o próprio navegador rejeita essa combinação.
Não. GET é um dos três métodos seguros e a chamada não usa nenhum header fora da lista segura do Fetch, então o navegador nunca envia OPTIONS, ele resolve a requisição real direto como "simples".
O seu navegador faz a requisição de verdade para a URL informada, exatamente como qualquer página faria. Se a chamada for concluída, a origem atual foi autorizada. Se for bloqueada, o navegador nem chega a mostrar dados à página, esse já é o resultado.
Esta requisição usa só método e headers considerados "seguros" pelo CORS (GET/HEAD/POST com Content-Type simples e headers padrão), então o navegador a envia direto, sem checagem prévia via OPTIONS.
A requisição de teste sai diretamente do seu navegador para a URL informada, o servidor do J-Kit nunca vê, resolve ou intermedeia esse endereço. É o mesmo tipo de chamada que qualquer script na sua própria página faria.