Cookies, armazenamento local, cache e impressões digitais do navegador

Estes conceitos aparecem frequentemente em conjunto nas definições de privacidade, instruções de diagnóstico e produtos de perfis do navegador. Têm comportamentos suficientemente diferentes para tornar «limpar o navegador» uma instrução incompleta.

Um modelo mental prático

Mecanismo	Quem o cria ou controla	Âmbito normal	Finalidade comum	É enviado automaticamente com um pedido?
Cookie HTTP	Um servidor define-o; o navegador guarda-o e devolve-o segundo as regras de âmbito	Anfitrião ou domínio, percurso, duração e condições da ligação	Identificadores de sessão, preferências, estado de prevenção de abuso	Sim, quando o pedido corresponde ao respetivo âmbito
localStorage	JavaScript do site	Origem, sujeito ao particionamento e às políticas do navegador	Estado persistente da aplicação em pares chave-valor	Não
sessionStorage	JavaScript do site	Origem dentro de uma sessão de navegação de nível superior	Estado temporário de um separador ou fluxo	Não
Cache HTTP	Navegador e regras de cache HTTP	Chave de cache, diretivas da resposta, política do navegador	Reutilizar respostas para reduzir a latência e o tráfego	Pode satisfazer ou revalidar um pedido
API Cache Storage	JavaScript do site ou do service worker	Origem ou partição de armazenamento	Recursos sem ligação e respostas geridas pela aplicação	Sem anexação automática; o script controla a utilização
Impressão digital do navegador	Um site ou outro observador mede sinais	Depende do observador e dos sinais	Segurança, deteção de fraude, análise ou rastreio	Alguns sinais são visíveis nos pedidos; outros exigem código ativo

As primeiras cinco linhas envolvem estado conservado. A última é um método de observação e correlação, embora o estado conservado também possa tornar-se um dos seus elementos.

Cookies: estado dirigido ao servidor com regras de âmbito

O HTTP é, em grande parte, sem estado. Os cookies permitem a um servidor dar ao navegador um par nome-valor e recebê-lo em pedidos posteriores correspondentes. A RFC 6265 define o cabeçalho de resposta Set-Cookie, o cabeçalho de pedido Cookie e o modelo de armazenamento do navegador.

Um cookie pode ser:

• limitado à sessão, conservado até terminar a sessão definida pelo navegador;
• persistente, com uma data de validade ou duração máxima;
• limitado ao anfitrião, devolvido apenas ao anfitrião que o definiu;
• limitado ao domínio, elegível para o domínio indicado e os subdomínios correspondentes;
• limitado ao percurso, devolvido apenas para percursos de pedidos correspondentes;
• Secure, devolvido apenas através de um canal seguro, tal como definido pelo navegador; e
• HttpOnly, ocultado das APIs de cookies disponíveis aos scripts, mas ainda disponível para pedidos HTTP.

Estes atributos afetam o envio e o acesso por scripts. Não transformam o valor do cookie num limite de segurança independente. A RFC 6265 avisa expressamente que o atributo Path não deve ser utilizado como mecanismo de segurança e recomenda transporte seguro e proteção adicional para conteúdo sensível de cookies.

Porque eliminar cookies termina a sessão

Muitos serviços guardam um identificador de sessão aleatório num cookie e mantêm o registo da conta e os detalhes da sessão no servidor. Eliminar esse cookie remove a cópia do identificador existente no navegador, pelo que o pedido seguinte deixa de apresentar a mesma sessão. A conta no servidor e outras sessões podem permanecer.

Isto também explica por que razão copiar cookies de autenticação é sensível. Um identificador de sessão utilizável pode funcionar como uma credencial. Não cole cookies em bruto em pedidos, registos, resultados de automação ou chats da equipa.

Armazenamento local: estado controlado por scripts para uma origem

A Norma HTML define localStorage como o acesso à área de armazenamento local de uma origem. Destina-se a abranger várias janelas e perdurar para além da sessão atual. O armazenamento contém pares chave-valor de texto e está disponível para scripts executados com acesso a essa origem.

Uma origem combina normalmente o esquema, o anfitrião e a porta. Consequentemente, estes são âmbitos de armazenamento diferentes:

• https://app.example.test
• http://app.example.test
• https://admin.example.test
• https://app.example.test:8443

O percurso do URL não faz parte da origem. As páginas em /billing/ e /support/ na mesma origem podem aceder à mesma área de armazenamento local, salvo se a aplicação criar a sua própria separação lógica.

Ao contrário de um cookie, uma entrada de localStorage não é anexada automaticamente aos pedidos HTTP. O script do site tem de a ler e decidir o que fazer. Isto torna-a útil para preferências da interface, rascunhos e dados de aplicações, mas qualquer script executado com a autoridade da origem pode conseguir aceder-lhe. A conceção de sessões sensíveis deve considerar o comprometimento de scripts, em vez de presumir que «local» significa secreto.

Persistência significa aqui que os dados podem sobreviver a uma sessão de navegação. Não significa conservação permanente. Uma pessoa pode limpar os dados, a política do navegador pode restringi-los e o navegador pode aplicar regras de armazenamento e eliminação.

sessionStorage tem outra duração

O sessionStorage está associado à origem e a uma sessão de navegação de nível superior. É adequado para estado que deve permanecer enquanto continua um fluxo num separador ou janela e terminar com essa sessão. Um separador clonado ou restaurado pode envolver pormenores do ciclo de vida específicos do navegador, pelo que as aplicações não devem utilizá-lo como único registo de trabalho crítico.

O armazenamento local é apenas um mecanismo de dados de sites

As aplicações web modernas também podem conservar dados em IndexedDB, Cache Storage, registos de service workers, Origin Private File System, permissões e outros armazenamentos geridos pelo navegador. Limpar apenas localStorage nas ferramentas de programação pode, portanto, deixar intacto outro estado.

As orientações de privacidade da Norma HTML recomendam que os navegadores permitam limpar em conjunto os mecanismos de armazenamento persistente, pois, de outro modo, os sites poderiam utilizar um armazenamento para recriar um identificador removido de outro.

Cache: uma palavra para vários mecanismos

A cache HTTP

A RFC 9111 define uma cache HTTP como um armazenamento de mensagens de resposta e o sistema que controla o respetivo armazenamento, obtenção e eliminação. Uma cache do navegador pode reutilizar uma resposta válida ou revalidar uma resposta obsoleta, reduzindo a latência e a transferência pela rede.

A chave de cache inclui, pelo menos, o método do pedido e o URI de destino, e os cabeçalhos da resposta influenciam se e durante quanto tempo uma resposta pode ser reutilizada. A cache HTTP é uma camada de otimização. Uma imagem ou script em cache não significa normalmente que a pessoa tenha sessão iniciada.

O estado da cache pode, ainda assim, afetar a privacidade. O tempo ou a disponibilidade prévia de um recurso pode revelar informações em certos modelos de ameaça. As orientações do W3C sobre impressões digitais incluem a observação de recursos em cache entre as formas de inferir a configuração do navegador ou do utilizador.

Cache Storage e service workers

A API Cache Storage dá a um site objetos Cache explícitos e controlados por scripts, muitas vezes para aplicações web sem ligação. A especificação Service Workers indica que estas caches estão separadas da cache HTTP do navegador, são isoladas por origem e são atualizadas ou eliminadas pela lógica da aplicação, não pelas regras normais de validade do HTTP.

Esta diferença importa durante o diagnóstico:

• limpar «imagens e ficheiros em cache» atua sobre a cache normal do navegador;
• limpar dados de sites também pode remover Cache Storage e estado dos service workers; e
• recarregar sem utilizar a cache HTTP pode deixar um service worker ativo a controlar os pedidos.

Identifique a cache em causa antes de decidir como a inspecionar ou limpar.

O particionamento do armazenamento acrescenta outra chave

O âmbito da origem permitia anteriormente a um terceiro incorporado ler o mesmo armazenamento quando aparecia em vários sites de nível superior. Os navegadores modernos acrescentam cada vez mais o site de nível superior ou um contexto relacionado à chave de armazenamento.

O Chrome documenta que o seu particionamento do armazenamento impede uma moldura de example.com incorporada em a.com de partilhar automaticamente Local Storage, IndexedDB, Cache Storage, service workers e certos mecanismos de comunicação com a mesma moldura incorporada em b.com. O Chrome afirma que esta função está ativa para todos os utilizadores desde o Chrome 115, com alterações posteriores em algumas APIs adicionais.

O particionamento explica um resultado que, de outro modo, surpreende: a mesma origem incorporada pode ver armazenamentos diferentes consoante o site que a envolve. Não significa que todo o armazenamento tenha em todo o lado um modelo universal de duas chaves. As versões do navegador, os contextos de nível superior e incorporados, as concessões de acesso ao armazenamento, a política empresarial, as extensões e as regras específicas das APIs podem alterar o resultado.

Teste o contexto exato, em vez de o inferir apenas pelo nome de domínio.

Impressões digitais do navegador: sinais observados, não uma pasta

O W3C define a impressão digital do navegador como a capacidade de identificar ou reidentificar um utilizador, agente de utilizador ou dispositivo através de definições de configuração ou outras características observáveis. As suas orientações de 2025 distinguem várias formas:

• Impressão digital passiva utiliza informações já observáveis nos pedidos ou na rede, como cabeçalhos de pedidos e o endereço IP.
• Impressão digital ativa executa código para observar características como o tamanho da janela, os tipos de letra, os dispositivos ligados, o desempenho, os sensores ou a apresentação gráfica.
• Correlação de eventos transitórios associa contextos através de alterações quase simultâneas do dispositivo ou ambiente.
• Técnicas semelhantes a cookies guardam e recuperam estado através de mecanismos que podem sobreviver aos cookies normais ou recriá-los.

Uma impressão digital raramente é um valor imutável guardado pelo navegador. Um observador escolhe sinais, combina-os e decide até que ponto correspondem a uma visita anterior. O resultado pode mudar quando o navegador é atualizado, a janela muda, são instalados tipos de letra, um dispositivo é ligado ou o percurso de rede muda. Também pode permanecer semelhante após a limpeza dos cookies porque muitos dos sinais subjacentes não mudaram.

Uma impressão digital não prova a identidade

Um conjunto de sinais pode ser comum a muitas pessoas ou variar para uma só pessoa. Os sites também podem combinar uma impressão digital com um início de sessão, o histórico da conta no servidor, a reputação da rede ou identificadores guardados. O reconhecimento depois de limpar os dados não demonstra que apenas a impressão digital foi responsável.

Pela mesma razão, mudar uma definição visível não garante uma nova identidade. Uma configuração coerente e comum pode reduzir alguma singularidade, enquanto muitas alterações independentes e pouco comuns podem criar uma combinação mais rara. Estes sinais não permitem garantir invisibilidade nem aceitação por terceiros.

O que alteram realmente as ações comuns de limpeza

Ação	Efeito provável	Elementos importantes que permanecem
Eliminar os cookies de um site	Remove o estado de cookies correspondente no navegador e termina muitas vezes a sessão nesse perfil	Os dados da conta no servidor, outros dispositivos e armazenamentos que não sejam cookies podem permanecer
Eliminar cookies e outros dados de sites	Pode remover cookies, Web Storage, IndexedDB, service workers e estado relacionado do site, consoante a interface e o âmbito do navegador	O gestor de palavras-passe, as transferências, os dados na conta e os sinais observáveis do dispositivo são separados
Eliminar imagens e ficheiros em cache	Remove conteúdo normal de respostas em cache	Os cookies, o armazenamento local e Cache Storage podem exigir escolhas separadas
Limpar o histórico	Remove os URLs visitados registados e as sugestões relacionadas no âmbito escolhido	Os ficheiros transferidos e os registos mantidos pelos sites permanecem
Remover um perfil do navegador	Remove do dispositivo os marcadores, o histórico, as palavras-passe e outras definições locais	Os dados sincronizados da conta, ficheiros transferidos ou exportados, cópias de segurança e dados no servidor podem permanecer
Iniciar um novo perfil	Começa com uma coleção diferente de estado do perfil	O dispositivo, o sistema operativo, a compilação do navegador e a rede ainda podem ser observados como relacionados

O próprio guia do Chrome sobre dados de navegação trata o histórico, os cookies e outros dados de sites, as imagens e ficheiros em cache, o histórico de transferências, o preenchimento automático, as definições de sites e os dados de aplicações alojadas como categorias distintas. Também indica que eliminar o histórico de transferências deixa os ficheiros transferidos no computador e que eliminar dados com sessão iniciada pode afetar a Conta Google e outros dispositivos sincronizados.

O efeito exato depende do intervalo temporal escolhido, do perfil, do estado da conta, da versão do navegador e da política empresarial. Analise o texto de confirmação antes de eliminar dados que possam ser difíceis de recuperar.

Como os perfis separados afetam cada mecanismo

Um perfil persistente corretamente separado deve ter o seu próprio armazenamento de cookies, áreas de armazenamento web, bases de dados de sites, Cache Storage, propriedade da cache HTTP, histórico, permissões dos sites e estado das extensões. Isto impede que o perfil B herde simplesmente a sessão guardada do perfil A.

Vários sinais podem permanecer comuns:

• motor e versão do navegador;
• sistema operativo e hardware;
• tipos de letra instalados no sistema e características do ecrã;
• definições de idioma, fuso horário ou acessibilidade herdadas do anfitrião;
• endereço IP e percurso de rede quando não está configurado um percurso separado; e
• comportamento do operador ou inícios de sessão que associam a atividade ao nível da aplicação.

Perfis diferentes também podem expor sinais diferentes através das extensões, permissões, tamanhos de janela, definições de idioma ou percursos de proxy. O efeito líquido depende da implementação e do contexto. A separação de perfis deve ser avaliada como isolamento de estado, não como garantia sobre a impressão digital.

Diagnostique o sintoma antes de limpar tudo

«A minha sessão terminou»

Verifique primeiro os cookies. Um cookie de sessão pode ter expirado, sido eliminado, sido rejeitado por uma política do navegador ou sido invalidado pelo servidor. O armazenamento local pode apoiar a interface, mas não é normalmente o cookie anexado automaticamente para autenticar um pedido HTTP.

«O site esqueceu o meu rascunho ou dados sem ligação»

Inspecione o armazenamento local, IndexedDB, Cache Storage e o estado dos service workers. Confirme a origem e se a página está no nível superior ou incorporada noutro site, pois o particionamento pode alterar o armazenamento disponível.

«O primeiro recarregamento é lento»

Uma cache HTTP vazia ou obsoleta é uma causa provável. A rede, o servidor e o comportamento dos service workers podem produzir o mesmo sintoma, pelo que deve registar o tempo dos pedidos e o estado da cache antes de concluir.

«O site continua a reconhecer o ambiente depois de eu limpar os dados»

Permanecem várias explicações: a conta continua com sessão iniciada noutro local, o servidor associou a visita através de dados da conta ou da rede, outro armazenamento do navegador sobreviveu ou características observáveis correlacionaram as sessões. Trate a impressão digital como uma hipótese, não como resposta automática.

Conclusão orientada para a decisão

Utilize o mecanismo para escolher a solução:

• inspecione ou limpe cookies quando a questão disser respeito a sessões no servidor;
• inspecione os armazenamentos de sites limitados à origem quando uma aplicação web conservar estado local;
• distinga a cache HTTP de Cache Storage ao diagnosticar conteúdo obsoleto ou sem ligação;
• utilize um perfil persistente separado quando o estado de trabalho guardado tiver de permanecer independente; e
• trate a impressão digital como correlação entre sinais observáveis, com limites que a limpeza de dados ou a alteração de uma definição não eliminam.

Este modelo evita dois erros dispendiosos: eliminar mais estado do que o necessário e presumir que um armazenamento de cookies vazio cria uma nova identidade de dispositivo.

Limitações

O comportamento do armazenamento e da privacidade na Web evolui entre navegadores e versões. As regras de cookies de terceiros, o particionamento do armazenamento, a eliminação, a sincronização, a política empresarial, as extensões e os modos de navegação privada podem alterar o comportamento aqui descrito. O guia explica as normas e a documentação atual do Chrome na data de consulta; não caracteriza a implementação de todos os navegadores ou sites.