1001Ferramentas
🍪Dev

Analisador de Flags de Cookie

Analisa o cabeçalho Set-Cookie e identifica falhas de segurança comuns: falta de Secure, HttpOnly, SameSite — e sugere correções.

Conferir as flags de segurança de um Set-Cookie

Cole o cabeçalho e a página confere as cinco decisões que definem a exposição do cookie: Secure, HttpOnly, SameSite, Path e prazo de validade. Cada uma vem com o efeito concreto de estar presente ou ausente, e não apenas com um sinal de certo e errado — porque cookie de sessão e cookie de preferência não pedem a mesma coisa.

A verificação é feita sobre os atributos de verdade, e essa distinção importa mais do que parece. Procurar a palavra secure no texto inteiro do cabeçalho acusa presença da flag num cookie que apenas se chama secure_token, ou cujo valor contém a palavra. É o tipo de falso positivo que faz alguém marcar como resolvido um cookie que continua trafegando em claro.

A página também checa os prefixos de nome, que são um contrato pouco conhecido: cookie começando com __Secure- só é aceito pelo navegador se tiver Secure, e começando com __Host- exige Secure, Path igual a barra e nenhum Domain. Quando o contrato não é cumprido, o navegador descarta o Set-Cookie inteiro — sem erro no console, o que torna a falha difícil de diagnosticar.

Perguntas frequentes

SameSite=None é sempre ruim?
Não, é necessário em cenário legítimo de terceiros — widget incorporado, autenticação federada, pagamento em iframe. O que não pode é None sem Secure: os navegadores rejeitam essa combinação desde 2020. Quando o cookie não precisa cruzar site, Lax é o padrão sensato e Strict o mais seguro.
HttpOnly protege contra roubo de sessão?
Reduz o caminho mais fácil, que é ler o cookie por script. Não protege contra tudo: com execução de script na página, o atacante pode agir em nome do usuário mesmo sem enxergar o cookie, porque o navegador o envia sozinho. HttpOnly é camada, não solução.
O que o prefixo __Host- garante na prática?
Que o cookie foi definido pelo próprio host, vale para todo o site e não pode ter vindo de subdomínio. Isso fecha uma classe real de ataque — subdomínio comprometido escrevendo cookie que o domínio principal aceita. Para cookie de sessão e de proteção contra CSRF, é a escolha mais forte disponível.

Ferramentas Relacionadas