Se você é um desenvolvedor JavaScript e deseja saber mais sobre os cookies do navegador e o que pode fazer com eles, você está no lugar certo. Este artigo abordará como os cookies do navegador funcionam, como você pode acessar e manipulá-los no cliente e no servidor e como controlar sua visibilidade nos navegadores usando seus atributos.
O que são cookies e como funcionam ?
Um cookie de navegador é um pequeno pedaço de dados armazenado em um navegador criado pelo cliente -side JavaScript ou um servidor durante uma solicitação HTTP. O navegador pode então enviar aquele cookie de volta com solicitações para o mesmo servidor e/ou permitir que o JavaScript do lado do cliente da página da web acesse o cookie quando um usuário visitar novamente a página.
Os cookies são geralmente usados para gerenciamento de sessão , personalização (como temas ou configurações semelhantes) e rastreamento do comportamento do usuário em sites.
Houve um tempo em que os cookies eram usados para todos os tipos de armazenamento do lado do cliente, mas havia um problema com essa abordagem.
Uma vez que todos os cookies de domínio são enviados com cada solicitação ao servidor nesse domínio, eles podem afetar significativamente o desempenho, especialmente com conexões de dados móveis de baixa largura de banda. Pelo mesmo motivo, os navegadores também costumam definir limites para o tamanho do cookie e o número de cookies permitidos para um domínio específico (normalmente 4kb e 20 cookies por domínio).
Com a web moderna, temos o novo APIs de armazenamento da Web (localStorage e sessionStorage) para armazenamento do lado do cliente, que permite aos navegadores armazenar dados do lado do cliente na forma de pares de valores-chave.
Portanto, se você deseja persistir os dados apenas no lado do cliente, é melhor usar as APIs porque são mais intuitivas e fáceis de usar do que cookies e pode armazenar mais dados (geralmente até 5 MB).
Configurando e acessando cookies
Você pode definir e acessar cookies através do servidor e do cliente. Os cookies também têm vários atributos que decidem onde e como podem ser acessados e modificados. Mas, primeiro, vamos ver como você pode acessar e manipular cookies no cliente e no servidor.
Cliente (navegador)
O JavaScript que baixa e executa em um navegador sempre que você visita um site é geralmente chamado de JavaScript do lado do cliente. Ele pode acessar cookies por meio do cookie de propriedade do documento.
Isso significa que você pode ler todos os cookies que estão acessíveis no local atual com document.cookie. Ele fornece uma string contendo uma lista de cookies separados por ponto-e-vírgula no formato chave=valor:
const allCookies=document.cookie;//O valor de allCookies seria algo como//”cookie1=valor1; cookie2=valor2″
Da mesma forma, para definir um cookie, devemos definir o valor de document.cookie. A configuração do cookie também é feita com uma string no formato chave=valor com os atributos separados por um ponto e vírgula:
document.cookie=”hello=world; domain=example.com; Secure”;//Define um cookie com a chave como hello e o valor como mundo, com//dois atributos SameSite e Secure (discutiremos esses//atributos na próxima seção)
Para não ficar confuso, a declaração acima não substitui nenhum cookie existente; ele apenas cria um novo ou atualiza o valor de um existente se um cookie com o mesmo nome já existir.
Agora, eu sei que esta não é a API mais limpa que você já viu. É por isso que recomendo usar um wrapper ou uma biblioteca como js-cookie para lidar com cookies de cliente:
Cookies.set (‘olá’,’mundo’, {domínio:’exemplo.com’, seguro: verdadeiro}); Cookies.get (‘olá’);//-> mundo
Além de fornecer uma API limpa para operações CRUD em cookies, também suporta TypeScript , ajudando a evitar erros de ortografia nos atributos.
Servidor
O servidor pode acessar e modificar cookies por meio de um Resposta da solicitação HTTP e cabeçalhos de solicitação. Sempre que o navegador envia uma solicitação HTTP ao servidor, ele anexa todos os cookies relevantes a esse site com o cabeçalho do cookie.
Verifique os cabeçalhos de solicitação de quase todos os aplicativos da web que você usa e você encontrará o cookies enviados ao servidor com cabeçalhos de solicitação como uma string separada por ponto e vírgula.
Cookies sendo enviados ao servidor com cabeçalhos de solicitação
Você pode então ler esses cookies no servidor a partir dos cabeçalhos de solicitação. Por exemplo, se você usar Node.js no servidor , pode ler os cookies do objeto de solicitação, como o snippet abaixo e obtenha os pares key=value separados por ponto e vírgula, semelhantes ao que vimos na seção anterior:
http.createServer (function (request, response) {var cookies=request.headers.cookie;//”cookie1=valor1; cookie2=valor2″…}). ouvir (8124);
Da mesma forma, para definir um cookie, você pode adicionar um cabeçalho Set-Cookie com os cabeçalhos de resposta no formato chave=valor com atributos separados por um ponto e vírgula, se houver. É assim que você pode fazer isso em Node.js:
response.writeHead (200, {‘Set-Cookie’:’mycookie=test; domain=example.com; Secure’});
Além disso, é provável que você não use Node.js simples; em vez disso, você pode usá-lo com uma estrutura da web como Express.js.
Acessar e modificar cookies fica muito mais fácil com Expresse adicionando middleware . Para leitura, adicione analisador de cookies para obter todos os cookies na forma de um objeto JavaScript com req.cookies . Você também pode usar o método res.cookie () integrado que vem com o Express para definir cookies:
var express=require (‘express’) var cookieParser=require (‘cookie-parser’) var app=express () app.use (cookieParser ()) app.get (‘/’, function (req, res) {console.log (‘Cookies:’, req.cookies)//Cookies: {cookie1:’value1′, cookie2:’value2′} res.cookie (‘name’,’tobi’, {domain:’example.com’, secure: true})}) app.listen (8080)
E sim, tudo isso é compatível com TypeScript, portanto, não há chance de erros de digitação no servidor também.
Atributos de cookies JavaScript
Agora que você sabe como definir e acessar cookies, vamos mergulhar nos atributos de cookies.
Além do nome e do valor, os cookies têm atributos que controlam uma variedade de aspectos que incluem segurança do cookie, tempo de vida do cookie e onde e como eles podem ser acessados em um navegador.
Atributo de domínio
De acordo com MDN, o atributo Domain informa ao navegador quais hosts têm permissão para acessar um cookie. Se não for especificado, o padrão é o mesmo host que definiu o cookie.
Portanto, ao acessar um cookie usando JavaScript do lado do cliente, apenas os cookies que têm o mesmo domínio que o da barra de URL são acessíveis.
Da mesma forma, apenas os cookies que compartilham o mesmo domínio que o domínio da solicitação HTTP são enviados junto com os cabeçalhos da solicitação para o servidor.
Lembre-se de que ter este atributo não significa você pode definir cookies para qualquer domínio porque isso obviamente seria um grande risco de segurança. (Imagine um invasor no evil.com modificando os cookies do seu site, awesome.com, quando o usuário visita o site dele.)
Portanto, a única razão pela qual esse atributo existe é para tornar o domínio menos restritivo e torne o cookie acessível em subdomínios.
Por exemplo, se seu domínio atual for abc.xyz.com e você não especificar o atributo de domínio ao definir um cookie, o padrão será abc.xyz. com, e os cookies seriam restritos apenas a esse domínio.
Mas, você pode querer que o mesmo cookie esteja disponível em outros subdomínios também. Nesse caso, defina Domain=xyz.com para disponibilizá-lo em outros subdomínios, como def.xyz.com e no domínio principal xyz.com.
No entanto, isso não significa que você pode definir qualquer valor de domínio para cookies; domínios de nível superior (TLDs) como.com e pseudo TLDs como.co.uk seriam ignorados por um navegador bem protegido.
Inicialmente, os fornecedores de navegadores mantinham listas desses domínios públicos internamente, o que inevitavelmente causava comportamento inconsistente entre navegadores.
Para resolver isso, a Mozilla Foundation iniciou um projeto chamado Lista de sufixos públicos que registra todos os registros públicos domínios e os compartilha entre fornecedores.
Essa lista também inclui serviços como github.io e vercel.app que restringe qualquer pessoa de definir cookies para esses domínios, fazendo com que abc.vercel.app e def.vercel.app contem como sites separados com seu próprio conjunto separado de cookies.
Atributo Path
O atributo Path especifica o caminho na URL de solicitação que deve estar presente para acessar o cookie. Além de restringir cookies a domínios, você também pode restringi-los por meio do caminho. Um cookie com o atributo path como Path=/store só pode ser acessado no caminho/store e seus subcaminhos,/store/cart,/store/gadgets e outros.
Atributo de expiração
O atributo Expires define uma data de expiração quando os cookies são destruídos. Isso pode ser útil quando você está usando um cookie para verificar se o usuário viu um anúncio intersticial; você pode configurar o cookie para expirar em um mês para que o anúncio possa ser exibido novamente depois de um mês.
E adivinhe? Ele também remove os cookies definindo a data [Expires] no passado .
Atributo seguro
Um cookie com o atributo Seguro envia apenas para o servidor pelo protocolo HTTPS seguro e nunca pelo protocolo HTTP (exceto no localhost). Isso ajuda a evitar ataques Man in the Middle , tornando o cookie inacessível em conexões não seguras.
A menos que você esteja servindo seus sites por meio de uma conexão HTTP não segura ( o que você não deveria ), você deve sempre use este atributo com todos os seus cookies.
Atributo HttpOnly
Este atributo, como o nome provavelmente sugere, permite que os cookies sejam acessíveis apenas através do servidor. Portanto, apenas o servidor pode defini-los por meio dos cabeçalhos de resposta. Se eles forem enviados ao servidor com todos os cabeçalhos de solicitação subsequente, eles não estarão acessíveis via JavaScript do lado do cliente.
Isso pode ajudar parcialmente a proteger cookies com informações confidenciais, como tokens de autenticação, de ataques XSS já que qualquer script do lado do cliente não pode ler os cookies. Mas, lembre-se de que isso não garante segurança completa contra ataques XSS.
Isso ocorre porque se o invasor puder executar scripts de terceiros em seu site, eles podem não conseguir acessar os cookies e, em vez disso, podem execute diretamente quaisquer solicitações de API relevantes para seu servidor, fazendo com que o navegador anexe prontamente seus cookies HttpOnly seguros aos cabeçalhos de solicitação.
Imagine que um de seus usuários visita uma página em que um hacker injetou um script malicioso em seu site. Eles podem executar qualquer API com esse script e agir em nome do usuário sem que eles nunca saibam.
Portanto, quando as pessoas dizem que os cookies HttpOnly tornam os ataques XSS inúteis, eles não estão completamente corretos porque, se forem um hacker pode executar scripts em seu site, você tem problemas muito maiores para lidar. Existem maneiras de impede ataques XSS , mas estão fora do escopo deste artigo.
Atributo SameSite
No início deste artigo, vimos como os cookies de um domínio específico são enviados com cada solicitação ao servidor para o domínio correspondente.
Isso significa que se o seu usuário visitar um terceiro site de terceiros, e esse site faz uma solicitação às APIs em seu domínio, todos os cookies de seu domínio serão enviados com essa solicitação para seu servidor. Isso pode ser uma bênção e uma maldição, dependendo do seu caso de uso.
Isso pode ser uma bênção no caso de algo como a incorporação do YouTube.
Por exemplo, se um usuário que está conectado ao YouTube em seu navegador visita um site de terceiros contendo incorporações do YouTube, eles podem clicar no botão Assistir mais tarde no vídeo incorporado e adicioná-lo à biblioteca sem sair do site atual.
Isso funciona porque o navegador envia os cookies relevantes do YouTube para o servidor, confirmando seu status de autenticação. Esses tipos de cookies também são chamados de cookies de terceiros.
A maldição que isso pode causar está basicamente em qualquer outro caso de uso que você não pretendia que acontecesse.
Por exemplo, se um usuário visitar um site mal-intencionado em que esse site faz uma solicitação ao seu servidor, e se o servidor não valida a solicitação corretamente, o invasor pode executar ações em nome do usuário sem o seu conhecimento. Este é basicamente um ataque CSRF .
Para ajudar a prevenir este tipo de ataque, a IETF propôs em 2016 um novo atributo em cookies chamado SameSite. Este atributo ajuda no problema acima, permitindo que você restrinja seus cookies a apenas um contexto original.
Isso significa que você só deve anexar cookies à solicitação quando o domínio na barra de URL corresponder ao domínio do cookie.
Atributo SameSite com Strict
Existem três tipos de valores que você pode definir para o atributo SameSite: Strict, Lax e None.
Quando definido como Strict, seus cookies só serão enviados primeiro-party context.
O valor Lax é um pouco menos restritivo do que Strict porque envia cookies com navegações de nível superior, o que significa que o cookie é enviado ao servidor com a solicitação da página.
Isso é útil nos casos em que um usuário clica em seu site a partir de um resultado de pesquisa do Google ou é redirecionado por meio de um URL encurtado.
Então, nenhum, como o nome sugere, permite que você crie cookies de terceiros enviando a releva nt cookies com cada solicitação. Isso, no entanto, é independente do usuário do site para casos como as incorporações do YouTube que discutimos anteriormente.
Você pode aprender mais sobre Cookies SameSite e como eles se comportam com navegadores modernos nesta postagem em web.dev.
Privacidade e cookies de terceiros
Explicamos brevemente terceiros cookies na seção anterior. Em suma, qualquer cookie definido por um site diferente daquele em que você está atualmente é um cookie de terceiros.
Você também deve ter ouvido falar sobre como os cookies de terceiros são infames para rastreá-lo em sites e exibindo anúncios personalizados. Agora que você conhece as regras dos cookies, provavelmente pode adivinhar como eles podem fazer isso.
Basicamente, sempre que um site usa um script ou adiciona um objeto incorporado via IFrame para serviços de terceiros, esse terceiro O serviço de terceiros pode definir um cookie para o domínio desse serviço com cabeçalhos de resposta HTTP.
Esses cookies também podem rastreá-lo em sites que usam as mesmas incorporações de serviços de terceiros. E, finalmente, os dados coletados por esses serviços de terceiros, identificando você por meio de cookies, podem mostrar anúncios personalizados.
Para resolver isso, muitos navegadores como o Firefox começaram a bloquear cookies de rastreamento de terceiros populares por meio de um novo recurso que eles chamam de proteção de rastreamento aprimorada (ETP) Embora isso proteja os usuários dos 3.000 rastreadores identificados mais comuns, sua proteção depende da lista completa e atualizada.
Os navegadores estão atualmente planejando se livrar dos cookies de terceiros. O Firefox está implementando o particionamento de estado, o que resultará em cada cookie de terceiros tendo um contêiner separado para cada site.
Agora, você pode pensar que algo como o particionamento de estado também quebrará casos de uso legítimos para terceiros cookies além de rastreamento, e você está certo.
Então, os navegadores estão trabalhando em uma nova API chamada Armazenamento Acesso Esta API permite que o contexto de terceiros solicite acesso ao armazenamento primário por meio do pedido de permissão dos usuários, o que dá ao serviço acesso não particionado ao seu estado primário. Você pode ler sobre como isso funciona em mais detalhes no blog da Mozilla .
Conclusão
Espero que este artigo tenha ajudado você a aprender algo novo sobre cookies JavaScript e tenha dado uma breve visão geral de como eles funcionam, como podem ser acessados e modificados a partir do servidor e do cliente e, por último, como os diferentes atributos dos cookies permitem que você controle sua visibilidade e vida útil no navegador.
