Como configurar cookies seguros em um site criado por IA — Blog

Um site criado por IA pode adicionar login, preferências, checkout ou uma integração e tratar o cookie como um detalhe: gravar um valor, escolher uma validade longa e seguir para a publicação. O navegador aceita a instrução, mas o resultado pode expor a sessão ao JavaScript, enviar o cookie em contextos desnecessários ou compartilhá-lo com hosts que nunca deveriam recebê-lo.

Configurar cookies seguros é definir quem cria o valor, em quais conexões e requisições ele viaja, quando expira e se o JavaScript pode acessá-lo. Esses controles pertencem principalmente à resposta HTTP do serviço que mantém a sessão. Uma landing page estática não transforma document.cookie em um cookie HttpOnly e não corrige no HTML um Set-Cookie inseguro emitido pela API.

Este guia mostra como revisar esse contrato antes de publicar e como confirmar o comportamento na URL final.

Comece pelo código da página e pelos serviços integrados:

rg -n \
  'document\.cookie|cookieStore|Set-Cookie|credentials:|withCredentials|SameSite|HttpOnly' \
  src public server api

Ajuste os caminhos ao projeto. Depois, abra o navegador e registre todos os cookies observados durante as jornadas principais:

nome:
host que emitiu:
finalidade:
quem lê:
Domain:
Path:
Secure:
HttpOnly:
SameSite:
Expires ou Max-Age:
como é removido:

Separe três origens possíveis:

o JavaScript da landing, por document.cookie ou Cookie Store API;
o backend próprio, por meio do header Set-Cookie;
um serviço externo, como checkout, agenda, formulário ou autenticação.

Essa origem determina onde a correção deve acontecer. Se o cookie vem de um serviço externo, a landing não consegue reescrever os atributos com segurança. É preciso alterar a configuração do serviço ou o backend responsável.

O guia de armazenamento no navegador amplia o inventário para localStorage, sessionStorage, IndexedDB e caches.

Cookies de sessão não deveriam nascer em JavaScript. O servidor deve criá-los em uma resposta HTTPS e impedir que o frontend leia o valor:

Set-Cookie: __Host-session=valor_aleatorio; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=1800

O exemplo ilustra um conjunto coerente, não uma configuração universal:

Secure limita o envio a conexões HTTPS, com exceções específicas de desenvolvimento local;
HttpOnly impede leitura e alteração por APIs JavaScript como document.cookie;
SameSite=Lax reduz envios em contextos entre sites sem bloquear toda navegação legítima;
Path=/ declara onde o navegador envia o cookie naquele host;
Max-Age=1800 cria uma expiração de 30 minutos;
o prefixo __Host- exige Secure, Path=/ e ausência de Domain em navegadores compatíveis.

A referência de Set-Cookie da MDN detalha os atributos e as regras dos prefixos.

HttpOnly reduz a exposição do valor, mas não neutraliza XSS. Um script malicioso ainda pode iniciar ações enquanto a sessão estiver ativa. Por isso, combine cookies de sessão com prevenção de DOM XSS, autorização no servidor e proteção contra CSRF.

Escolha SameSite pelo fluxo real

SameSite controla quando o cookie acompanha uma requisição iniciada a partir de outro site. Os valores têm impactos diferentes:

Valor	Comportamento resumido	Quando investigar
`Strict`	restringe mais os envios entre sites	áreas sensíveis sem necessidade de entrada por link externo
`Lax`	permite alguns fluxos de navegação de nível superior	sessões comuns que precisam sobreviver à chegada por um link
`None`	permite contextos entre sites e exige `Secure`	integração incorporada cujo contrato realmente depende disso

Não deixe a decisão implícita porque alguns navegadores aplicam um padrão. Declare o atributo e teste o percurso esperado.

Também não confunda site com origem. Hosts irmãos podem ser considerados same-site mesmo sendo origens diferentes. Se uma organização não controla todos os subdomínios com o mesmo nível de confiança, SameSite sozinho não cria essa separação.

Trate o atributo como defesa em profundidade, não como autorização. O backend ainda precisa verificar a sessão, o recurso e a permissão para cada ação.

Reduza domínio e caminho ao necessário

Evite definir Domain sem uma necessidade comprovada. Quando ele é omitido, o cookie fica limitado ao host que o criou. Quando é configurado para um domínio pai, hosts subordinados podem receber o valor conforme as regras do navegador.

Esse detalhe importa no Site no Ar porque a URL padrão e um domínio próprio são hosts diferentes:

https://campanha.sitenoar.app
https://www.campanha.com.br
https://api.campanha.com.br

Publicar o mesmo conteúdo em mais de um endereço não compartilha cookies automaticamente. O backend deve declarar quais hosts participam do fluxo, e o frontend deve chamar apenas o endpoint aprovado.

Use Path para reduzir envios desnecessários, mas não o trate como barreira de autorização entre páginas do mesmo host. O servidor continua responsável por proteger cada rota.

Defina duração, rotação e remoção

Um cookie sem ciclo de vida documentado tende a durar mais do que a finalidade. Classifique cada valor:

Tipo	Ciclo esperado
sessão autenticada	curta duração, rotação e revogação no logout
preferência	duração compatível com a expectativa da pessoa
campanha	prazo ligado à finalidade e ao consentimento
token temporário	uso único ou validade mínima necessária
cookie obsoleto	remoção explícita no mesmo escopo em que foi criado

Para apagar um cookie, o serviço precisa emitir outro Set-Cookie com o mesmo nome, domínio e caminho relevantes e uma expiração passada ou Max-Age=0. Alterar apenas o JavaScript não remove um cookie HttpOnly.

Sessões também exigem invalidação do lado do servidor. Expirar o identificador no navegador sem revogar a sessão pode deixar uma credencial reutilizável até o backend decidir recusá-la.

Não misture sessão, preferência e consentimento

Um único cookie não deve carregar responsabilidades incompatíveis. Separe:

autenticação e sessão;
preferência visual ou funcional;
escolha de consentimento;
atribuição de campanha;
estado temporário do formulário.

Para valores não sensíveis que o frontend precisa ler, HttpOnly não serve porque esse é justamente o controle que bloqueia a leitura. Isso não autoriza colocar credenciais no JavaScript. Significa que a arquitetura precisa distinguir dados públicos de uma sessão secreta.

Evite serializar objetos inteiros, dados pessoais ou respostas de API no cookie. O valor viaja em requisições compatíveis com seu escopo, aumenta headers e pode aparecer em logs de infraestrutura se o ambiente não estiver bem configurado.

Valide no navegador e na resposta HTTP

Teste primeiro com dados sintéticos em um ambiente autorizado. No DevTools:

abra Application ou Storage e liste os cookies;
confira host, caminho, expiração e atributos;
use Network para localizar a resposta que emitiu Set-Cookie;
recarregue e confirme em quais requisições o cookie viaja;
tente ler apenas cookies que deveriam estar disponíveis ao frontend;
percorra login, renovação, logout e expiração;
repita na URL padrão e em cada domínio próprio ativo.

Pelo terminal, inspecione a resposta sem imprimir o valor completo em logs compartilhados:

curl -sSI https://api.exemplo.com/sessao

Procure o nome e os atributos do Set-Cookie, mas redija credenciais antes de anexar evidências a tickets ou PRs.

Teste ainda:

acesso por link externo;
aba anônima e perfil já autenticado;
relógio avançado até a expiração;
logout em uma aba e uso em outra;
resposta a uma sessão revogada;
requisições entre a landing e uma API em outra origem.

Publique sem fingir que a hospedagem é o backend

O contrato de Publicação envia HTML, CSS, JavaScript e assets preparados pelo projeto. Ele não cria automaticamente uma sessão, não adiciona HttpOnly a cookies do frontend e não altera o Set-Cookie de APIs externas.

Antes de publicar:

remova credenciais de document.cookie e do Web Storage;
confirme o host que emite a sessão;
ajuste atributos e expiração no serviço responsável;
restrinja origens permitidas pela integração;
teste o pacote final contra um ambiente autorizado;
registre quais domínios precisam continuar funcionando.

Depois de publicar, abra a URL real e repita a inspeção. Diferenças de host, HTTPS, redirecionamento e CORS podem mudar o comportamento que parecia correto no ambiente local.

Se a revisão exigir mudança no frontend, faça o ajuste, gere novamente o artefato e republique o mesmo Site para preservar a URL aprovada.

Prompt copiável para o agente

Revise os cookies deste site antes de publicar.

Pasta publicável: [caminho]
URL de teste: [URL]
URL padrão: [URL]
Domínios próprios: [lista]
APIs e serviços integrados: [lista]

- Inventarie quem cria, lê, envia e remove cada cookie.
- Registre Domain, Path, Secure, HttpOnly, SameSite e expiração.
- Marque credenciais criadas ou legíveis pelo JavaScript.
- Proponha o menor escopo e a menor duração compatíveis com o fluxo.
- Não altere o backend nem apague cookies sem aprovação.
- Não trate SameSite como substituto de autorização ou proteção CSRF.
- Teste login, renovação, logout, expiração e acesso por link externo.
- Valide separadamente a URL padrão e cada domínio próprio.
- Redija valores secretos de toda evidência.
- Entregue o diff proposto, os testes executados e os riscos restantes.

Checklist final

Cookie seguro não é um atributo isolado. É um contrato entre navegador, frontend e servidor. Quando emissor, escopo, acesso e expiração ficam explícitos, a publicação deixa de carregar uma sessão implícita e passa a entregar um comportamento que a equipe consegue validar.