Dissecando o Navegador (Parte Final) - O Motor de Segurança, CORS e o Fantasma do OPTIONS

# webdev# braziliandevs# browser# javascript
Dissecando o Navegador (Parte Final) - O Motor de Segurança, CORS e o Fantasma do OPTIONSErick Gabriel dos Santos Alves

Fala, comunidade dev! 👋 Se você escreve código para a web, com certeza já teve um dia arruinado por...

Fala, comunidade dev! 👋

Se você escreve código para a web, com certeza já teve um dia arruinado por um erro em vermelho no console: "Blocked by CORS policy".

Nesse momento, a reação natural é xingar o navegador, ir no Back-end e colocar um AllowAnyOrigin() para o erro sumir. Mas para construir sistemas corporativos seguros (como painéis logísticos ou ERPs), você não pode simplesmente desligar o alarme; você precisa entender por que ele tocou.

Hoje, na Parte 4 (e última) da nossa série sobre Navegadores, vamos descer ao Motor de Segurança. Vamos entender a Política de Mesma Origem (SOP), como o CORS funciona de verdade e desmistificar aquele request fantasma chamado OPTIONS.

1. A Regra Zero da Web: SOP (Same-Origin Policy)

Para entender o CORS, primeiro precisamos entender o mundo sem ele. Imagine que você está logado na sua conta bancária (banco.com.br). Em outra aba, você abre um site de memes malicioso (memes-engracados.com).

Se não houvesse segurança, um script JavaScript malicioso rodando no site de memes poderia fazer um fetch('https://banco.com.br/api/saldo'). Como você já está logado no banco, o navegador enviaria seus cookies de sessão automaticamente, e o hacker roubaria seu saldo silenciosamente em background.

Para impedir isso, os navegadores criaram a SOP (Same-Origin Policy). É uma regra de ferro: Um site só pode ler dados de uma API se ambos tiverem a EXATA mesma origem.

O que define uma Origem? A combinação de 3 coisas:

  1. Protocolo (http vs https)
  2. Domínio (api.sistema.com vs painel.sistema.com)
  3. Porta (:4200 vs :5000)

Se o seu Front-end Angular roda em http://localhost:4200 e tenta acessar sua API .NET em http://localhost:5000, a SOP entra em ação e bloqueia a leitura, pois as portas são diferentes. São "origens" diferentes.

2. O CORS: O Passaporte Diplomático

A SOP é ótima para segurança, mas quebra a arquitetura web moderna, onde Front-end e Back-end ficam em servidores separados. Para resolver isso, criaram o CORS (Cross-Origin Resource Sharing).

O CORS é um conjunto de cabeçalhos (Headers) HTTP que permite ao servidor dizer ao navegador: "Ei, relaxa. Eu conheço o pessoal do localhost:4200, pode deixar eles lerem meus dados."

Quando a API responde com o header Access-Control-Allow-Origin: http://localhost:4200, o navegador desarma a SOP e entrega os dados para o seu JavaScript.

3. O Fantasma do OPTIONS (Preflight Request)

Aqui chegamos ao grande mistério. Você faz um POST para salvar um registro, abre a aba Network do Chrome e vê duas requisições:

  1. Um OPTIONS (que você não programou).
  2. O seu POST real logo em seguida.

Por que o navegador envia esse request fantasma? Ele se chama Preflight Request (Voo de Reconhecimento).

Imagine que o Front-end tente fazer um DELETE na API com um Token de Autenticação customizado no header. O navegador pensa: "Isso é uma operação destrutiva. E se aquele servidor for antigo e não entender regras de CORS? Se eu mandar o DELETE direto, ele vai deletar o dado e só depois eu vou ver que não era permitido."

Para proteger servidores contra alterações não autorizadas cross-origin, o navegador "pausa" a sua requisição e faz uma pergunta prévia usando o método OPTIONS:

  • Navegador (OPTIONS): "Olá, servidor. O Front-end quer fazer um DELETE e quer mandar um header Authorization. Você permite?"
  • Servidor (Resposta do OPTIONS): "Sim! Eu permito o método DELETE (Access-Control-Allow-Methods) e permito esse header (Access-Control-Allow-Headers)."

Só após receber esse "Ok" é que o navegador envia o request DELETE real que o seu código mandou fazer.

Segredo de Performance: Se você faz 50 requisições seguidas, o navegador vai mandar 50 OPTIONS? Sim, a menos que o seu Back-end envie o header Access-Control-Max-Age. Esse header diz ao navegador para fazer cache do "Ok" do OPTIONS por X segundos (ex: 24 horas), cortando as requisições fantasmas pela metade e economizando muito tempo de rede!

4. O Isolamento de Sites (Site Isolation e Spectre)

Na Parte 1 desta série, falei que cada aba do Chrome roda num Processo isolado do Sistema Operacional. Mas o motor de segurança foi além por causa de uma vulnerabilidade física dos processadores chamada Spectre (descoberta em 2018).

Hackers descobriram que, se dois sites dividissem o mesmo processo de memória do V8, um JavaScript poderia ler fisicamente a memória RAM alheia explorando uma falha da CPU da Intel/AMD.

Para resolver isso, o Chrome implementou o Site Isolation. Hoje, se o seu painel abrir um <iframe> para outro domínio, o navegador obrigatoriamente cria um processo do Sistema Operacional totalmente separado só para aquele iframe. Eles não dividem mais o mesmo bloco de RAM. Isso deixou os navegadores mais pesados e "comilões" de memória, mas evitou o colapso da segurança na web.

Conclusão

CORS não é um bug. O OPTIONS não é um erro do framework. Eles são o navegador te protegendo contra a execução de código malicioso no computador do usuário.

Da próxima vez que o console brilhar em vermelho, não abra a API para o mundo (*). Entenda quem é o remetente, ajuste os Headers corretos e configure o tempo de cache do seu Preflight. Segurança corporativa começa com conhecimento de base.

E vocês? Já perderam quantas horas debugando um erro que era apenas falta de um Header de CORS no Back-end? Contem as histórias de terror nos comentários! 👇