Cookies: como funcionam no HTTP e usar com segurança

Cookies: como funcionam no HTTP e usar com segurança

Cookies não são “arquivos espiões” por definição, mas podem identificar um navegador e registrar escolhas ou comportamentos. O ponto técnico que muita gente ignora é que o navegador envia certos cookies automaticamente junto com as requisições HTTP; por isso, uma configuração aparentemente pequena pode afetar autenticação, privacidade e segurança da aplicação.

Segundo o Sapo.pt, cookies são pequenos arquivos de texto armazenados no dispositivo pelo navegador para memorizar informações de navegação. A descrição está correta, mas, para quem desenvolve, vale ir além: um cookie é um mecanismo de estado associado a um domínio e enviado em requisições que correspondem às suas regras de escopo.

O que são cookies e como funcionam no protocolo HTTP

HTTP é, por natureza, um protocolo sem estado: cada requisição não “lembra” automaticamente da anterior. Quando um servidor precisa reconhecer que duas requisições pertencem à mesma sessão, pode enviar um cabeçalho Set-Cookie. O navegador armazena o valor e, em requisições compatíveis, devolve-o no cabeçalho Cookie.

Um exemplo simplificado: depois do login, o servidor cria um identificador aleatório de sessão e o guarda no navegador. Nas próximas requisições, o navegador envia esse identificador; o servidor consulta seus dados de sessão e decide se o usuário está autenticado. O cookie normalmente não precisa conter a senha nem os dados completos do usuário.

Essa distinção é importante. O cookie é um mecanismo de transporte e armazenamento no navegador, não necessariamente o lugar onde ficam todos os dados da sessão. Em aplicações bem projetadas, o navegador guarda um identificador opaco e o servidor mantém os dados sensíveis.

Para que servem os cookies em um site

  • Manter uma sessão: permitir que o usuário continue autenticado ao navegar entre páginas.
  • Lembrar preferências: guardar idioma, tema, região ou estado de uma interface.
  • Preservar um carrinho: associar itens selecionados a uma sessão, mesmo antes do login.
  • Medir uso e desempenho: apoiar métricas de navegação e diagnóstico, conforme a implementação e o consentimento aplicável.
  • Personalizar publicidade: reconhecer atividade entre páginas ou serviços para selecionar anúncios.

Nem todo cookie é necessário para o site funcionar. Um cookie de sessão de login tem uma função diferente de um cookie de publicidade que acompanha visitas. Também não confunda “cookie próprio” e “cookie de terceiros” com categorias de finalidade: o primeiro descreve a relação do domínio com o site visitado; a finalidade pode ser, por exemplo, analítica ou publicitária.

Tipos de cookies: sessão, persistentes, próprios e de terceiros

Cookies de sessão e persistentes

Um cookie de sessão geralmente não tem uma data de expiração explícita e costuma ser removido quando a sessão do navegador termina. “Costuma” é a palavra-chave: recursos de restauração de sessão podem fazer com que o navegador reabra janelas e mantenha dados que o usuário imaginava temporários.

Cookies persistentes têm uma data de expiração ou duração definida, por meio de Expires ou Max-Age. Eles podem lembrar uma preferência por mais tempo, mas a duração deve ser proporcional à necessidade. Não há vantagem em manter um identificador de segurança válido por anos se a aplicação não precisa disso.

Cookies próprios e de terceiros

Um cookie próprio é definido no contexto do domínio do site visitado. Um cookie de terceiros é associado a outro domínio carregado dentro da página, como um serviço externo de publicidade ou análise. Essa diferença ficou mais relevante porque navegadores vêm limitando o rastreamento entre sites, e as políticas variam entre navegadores e versões.

Não baseie uma arquitetura de produto na suposição de que cookies de terceiros estarão sempre disponíveis. Para autenticação entre sistemas, considere fluxos explícitos, como OAuth ou OpenID Connect. Para métricas, avalie se dados agregados ou eventos enviados pelo próprio servidor atendem ao objetivo com menos dependência de rastreamento entre sites.

Quais informações um cookie pode guardar

Um cookie pode conter um identificador de sessão, uma preferência ou outro valor definido pelo site. O que ele guarda depende da aplicação. O nome do cookie, por si só, não revela necessariamente seu conteúdo, e valores podem estar codificados ou assinados — embora isso não os torne automaticamente secretos.

O navegador também associa atributos ao cookie, como domínio, caminho, expiração e regras de segurança. Além disso, o servidor pode observar dados da requisição, como endereço IP e user agent, mas esses dados não são “guardados dentro do cookie” por padrão. É importante separar o conteúdo do cookie dos dados que o serviço registra em seus próprios sistemas.

Cookies têm limites práticos de tamanho e quantidade definidos pelos navegadores. Um cookie não é um banco de dados: dados grandes aumentam o tráfego porque podem ser enviados repetidamente em várias requisições. Para armazenamento local maior, existem alternativas como IndexedDB, mas elas não são enviadas automaticamente ao servidor.

Cookies versus localStorage, sessionStorage e IndexedDB

Recurso Enviado automaticamente ao servidor? Uso típico
Cookie Sim, conforme domínio, caminho e atributos Sessão, preferências pequenas e estado necessário em requisições HTTP
localStorage Não Preferências e dados locais que precisam persistir no navegador
sessionStorage Não Estado temporário associado a uma aba
IndexedDB Não Armazenamento local estruturado e de maior volume

Na minha experiência, a decisão deve começar pela pergunta: o servidor precisa receber esse dado em cada requisição? Se a resposta for sim, um cookie pode fazer sentido. Se for apenas estado de interface no navegador, localStorage ou sessionStorage podem ser mais adequados. Mas não coloque tokens sensíveis em localStorage só para evitar configurar cookies: scripts executados na página podem acessá-lo, inclusive em um cenário de XSS.

Segurança de cookies: HttpOnly, Secure e SameSite

Para cookies de autenticação, três atributos merecem atenção. HttpOnly impede que JavaScript leia o cookie por meio de document.cookie. Isso reduz o impacto de certos ataques XSS, embora não impeça o ataque de executar ações na página. Secure restringe o envio a conexões HTTPS. SameSite controla em quais contextos o navegador envia o cookie e ajuda a reduzir ataques CSRF.

Esses atributos não substituem validação, proteção contra XSS, autorização no servidor ou uma estratégia CSRF adequada. Para um cookie que precisa funcionar em um contexto entre sites, por exemplo em certos fluxos de login federado, pode ser necessário SameSite=None; Secure. Isso aumenta a exposição e precisa ser avaliado com cuidado.

Exemplo funcional com Express

Este exemplo cria um cookie de sessão com opções de segurança. Em produção, use HTTPS e um identificador aleatório associado a uma sessão mantida no servidor; não use um valor previsível nem dados sensíveis diretamente no cookie.

import express from "express";

const app = express();

app.get("/login-demo", (req, res) => {
  // Em produção, gere um ID criptograficamente seguro
  // e associe-o a uma sessão armazenada no servidor.
  const sessionId = "substitua-por-um-id-aleatorio";

  res.cookie("session_id", sessionId, {
    httpOnly: true,
    secure: process.env.NODE_ENV === "production",
    sameSite: "lax",
    path: "/",
    maxAge: 60 * 60 * 1000
  });

  res.send("Cookie de demonstração definido.");
});

app.post("/logout", (req, res) => {
  res.clearCookie("session_id", {
    httpOnly: true,
    secure: process.env.NODE_ENV === "production",
    sameSite: "lax",
    path: "/"
  });

  res.send("Cookie removido.");
});

app.listen(3000, () => {
  console.log("Servidor disponível na porta 3000");
});

O caminho e os demais atributos usados ao remover o cookie devem corresponder aos usados ao criá-lo. Caso contrário, a aplicação pode tentar apagar um cookie diferente e deixar o original ativo. Em produção, também invalide a sessão no servidor: apagar o cookie no navegador, sozinho, não revoga um identificador que já tenha sido copiado.

Cookies e consentimento: o que considerar ao implementar

Na União Europeia, regras de privacidade e comunicações eletrônicas afetam o uso de cookies e tecnologias semelhantes. Em termos práticos, cookies estritamente necessários ao serviço solicitado podem ter tratamento diferente de cookies usados para publicidade ou determinadas análises. A obrigação exata depende da finalidade, da implementação e da legislação aplicável; não trate um banner genérico como garantia de conformidade.

Uma implementação responsável deve explicar categorias e finalidades, permitir escolhas claras e respeitar a decisão do usuário. Se uma categoria depender de consentimento, não basta esconder o aviso: a tag ou o script correspondente não deve ser acionado antes da escolha válida. Também mantenha um caminho simples para alterar ou retirar o consentimento.

Na Prática: como revisar cookies em uma aplicação

  1. Liste os cookies e tecnologias de armazenamento. Use as ferramentas de desenvolvedor do navegador, na aba Application ou Storage, e confira também as requisições na aba Network.
  2. Registre a finalidade de cada item. Identifique quem define o cookie, quais páginas o recebem, quanto tempo dura e se é essencial para uma funcionalidade.
  3. Revise os atributos de segurança. Para cookies de sessão, verifique HttpOnly, Secure, SameSite, escopo de domínio e caminho.
  4. Teste antes e depois da escolha de consentimento. Confirme que scripts não essenciais não enviam cookies nem fazem chamadas antes da autorização necessária.
  5. Teste expiração e logout. Verifique se a sessão expira como esperado e se o servidor invalida o identificador quando o usuário sai.

Erros comuns ao trabalhar com cookies

  • Guardar informações sensíveis em texto puro. Codificar Base64 não é criptografar. Assinar um cookie ajuda a detectar alterações, mas não esconde o conteúdo.
  • Usar um token de longa duração sem motivo. Se ele for roubado, o impacto pode persistir. Use expiração adequada e mecanismos de revogação.
  • Confiar apenas em SameSite para evitar CSRF. É uma camada útil, não uma solução universal. Avalie tokens CSRF e valide operações sensíveis.
  • Definir Domain amplo sem necessidade. Compartilhar cookies com subdomínios aumenta a superfície de exposição. Prefira o escopo mais restrito compatível com a arquitetura.
  • Colocar grandes quantidades de dados no cookie. O navegador pode enviá-los repetidamente, aumentando o tamanho das requisições e afetando desempenho.
  • Exibir um banner sem controlar os scripts. Consentimento precisa refletir o comportamento real da página, não apenas uma interface visual.

Perguntas frequentes sobre cookies

Cookies são vírus ou podem infectar meu computador?

Não. Cookies são dados de texto e não executam código por conta própria. Ainda assim, identificadores armazenados neles podem ser usados para reconhecer sessões ou associar atividade, então privacidade e segurança continuam relevantes.

Apagar cookies me desconecta dos sites?

Geralmente, sim, se o site usa um cookie para manter a sessão. Também é possível perder preferências e itens temporários. O efeito depende do que cada aplicação armazena no navegador.

É seguro guardar token de autenticação em cookie?

Pode ser uma escolha adequada se o cookie for configurado corretamente, por exemplo com HttpOnly, Secure e uma política SameSite coerente. A aplicação ainda precisa proteger a sessão no servidor e lidar com CSRF, expiração e revogação.

Qual é a diferença entre cookie e cache?

Cookies carregam pequenos valores associados a requisições e podem identificar estado ou preferências. O cache guarda cópias de recursos, como imagens e arquivos CSS, para reduzir downloads e acelerar carregamentos. São mecanismos diferentes, com objetivos diferentes.

Conclusão

Cookies continuam essenciais porque conectam requisições HTTP que, de outra forma, seriam independentes. Para quem desenvolve, o desafio não é simplesmente “usar ou evitar cookies”, mas escolher o mecanismo certo, limitar os dados armazenados e configurar corretamente segurança, expiração e consentimento.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.

Y

Yuri Sousa

Front-End Developer / Designer

Desenvolvedor apaixonado por criar experiências digitais acessíveis e visualmente perfeitas. Escrevo sobre desenvolvimento web, design e tecnologia.