Security

Desconecte um usuário de uma aplicação baseada em sessão e o servidor o esquece na próxima requisição. Desconecte-o de uma aplicação baseada em JWT e, a menos que você tenha construído um mecanismo extra para isso, o token que ele está carregando continua válido até expirar. Essa diferença é a verdadeira decisão por trás de “JWT vs sessão”. O resto decorre dela. O que uma sessão realmente guarda Uma sessão mantém o estado do usuário no servidor e passa ao navegador apenas uma chave de consulta. ...

Um endpoint de login devolve um JWT, e você tem três lugares para colocá-lo: um cookie, localStorage ou sessionStorage. Escolha errado, e ou um bug de XSS leva o token embora, ou o token nunca chega à sua API. Os três guardam strings no navegador. Eles diferem em quem pode lê-los, quanto tempo duram, e se o servidor chega a vê-los. Como localStorage, sessionStorage e cookies se diferenciam localStorage e sessionStorage são a mesma API, a interface Storage: setItem, getItem, removeItem, clear, chaves e valores em string. A diferença é o tempo de vida. localStorage sobrevive ao fechar o navegador e reiniciar a máquina, e permanece até algo limpá-lo. O Safari é a exceção: com a prevenção de rastreamento ativada, ele apaga o storage escrito por script de um site com o qual o usuário não interage há sete dias. sessionStorage pertence a uma aba e morre quando essa aba fecha. Digite a mesma URL em uma segunda aba e você recebe um sessionStorage novo e vazio; só “Duplicar aba” copia o conteúdo. ...

Seu frontend roda em http://localhost:5173, sua API em http://localhost:4000, e a chamada fetch que funcionava sem problemas no Postman falha no navegador com uma parede de texto vermelho: Access to fetch at 'http://localhost:4000/api/users' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Seu servidor pode muito bem ter processado a requisição e retornado um 200. O navegador simplesmente se recusou a entregar a resposta ao seu JavaScript. ...

Como chegar a um banco de dados que só escuta em localhost? Uma instância do Postgres num servidor remoto fica vinculada a 127.0.0.1 de propósito. Nada na rede consegue alcançá-la, só processos rodando naquela mesma máquina. Seu notebook não é essa máquina, então psql -h remote-server -p 5432 falha antes mesmo de chegar à autenticação. Abrir a porta para o mundo anula o motivo pelo qual ela foi vinculada ao loopback. ...

O que o TLS realmente protege em uma conexão HTTPS Carregue uma página por http:// puro em uma rede que você não controla, um aeroporto ou o roteador de uma cafeteria, e tudo o que você envia viaja como texto legível. O caminho da URL, os cookies, os campos do formulário, a senha em um POST de login: qualquer pessoa nessa rede com um sniffer de pacotes lê tudo isso ao passar. TLS, Transport Layer Security, é o protocolo que impede isso. Ele fica entre o TCP e o protocolo de aplicação, então quando o HTTP começa a falar, a conexão já está criptografada e vinculada a uma identidade de servidor verificada. HTTPS é o HTTP rodando sobre essa conexão em vez de uma em texto plano. ...

Onde acabam as variáveis de ambiente de um container Suba um container com -e DB_PASSWORD=hunter2 e rode docker inspect nele: 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] A senha fica ali em texto plano, legível por qualquer um com acesso ao socket do Docker, por docker exec api env e por qualquer processo rodando dentro do container. Isso não é um bug — é exatamente para isso que as variáveis de ambiente existem. O problema é usá-las para valores que nunca deveriam ficar tão visíveis. ...