CORS não é só colar asterisco!
Eu vi isso na prática quando fui revisar as configs do meu site no cloudflare pages e percebi que tinha deixado o backend exposto.
Eu fiz o básico e joguei o wildcard lá no header.
Funcionou e eu deixei por isso mesmo.
O ruim é que qualquer domínio aleatório podia mandar um fetch no meu endpoint pra floodar o guestbook.
Até tenho rate limit e turnstile no site mas não dá pra confiar só nisso.
Tirei o asterisco e criei uma whitelist com os domínios que realmente importam tipo o meu site e o localhost. agora o código verifica o origin de quem tá chamando.
Se vier de um lugar estranho a api simplesmente não manda o header de volta e o navegador do usuário corta a requisição na raiz.
Hi Miuna.
You're amazing!
Esse tipo de ajuste parece simples, mas mostra uma evolução importante de maturidade em segurança.
Muita gente trata CORS como “só fazer funcionar” e coloca um * no Access-Control-Allow-Origin sem pensar nas consequências. Você mostrou exatamente o ponto crítico: quando a API aceita qualquer origem, qualquer site pode tentar consumir aquele endpoint usando o navegador do usuário como intermediário.
Muito bom também você não confiar apenas em rate limit e Turnstile. Essas camadas ajudam bastante, mas segurança de verdade acontece em profundidade, com várias proteções trabalhando juntas.
A parte mais valiosa é a mudança de mentalidade:
Whitelist de domínios, validação de Origin e restrição explícita de acesso são práticas muito mais alinhadas com o princípio do menor privilégio.
Esse tipo de detalhe é o que separa configuração improvisada de arquitetura segura.
CORS não é um mecanismo de autenticação, mas é uma camada importante de controle de exposição entre frontend e backend. O erro mais comum é usar wildcard em APIs que lidam com escrita, autenticação ou dados sensíveis. O ideal é:
Seu post é simples, direto e muito educativo.
Esse tipo de experiência prática ajuda mais gente a evitar exatamente o mesmo erro.
Obrigado pela aula.
See you soon!...