Verificador de segurança de cookies

Três flags decidem se uma sessão pode ser roubada.

Digite uma URL e listamos os cookies que seu site define, checando cada um atrás de Secure, HttpOnly e SameSite. Cookies de sessão são a credencial que seus usuários nunca veem, e esses três atributos são a maior parte da proteção deles.

Cheque sites que você possui ou tem autorização para testar. Pedimos a página como um navegador pediria e lemos o que volta. Veja nossos termos.

O que isso verifica, e como é uma boa resposta

Secure

Sem ele, o navegador envia o cookie por http puro além de https. Isso soa teórico até você lembrar como acontece de verdade: um usuário digita seu domínio sem o esquema, ou clica num link http antigo, o navegador faz uma requisição sem criptografia antes do seu redirecionamento disparar, e o cookie de sessão vai junto, aberto, na rede em que essa pessoa estiver. O redirecionamento não salva você, porque o cookie já foi enviado. Qualquer cookie que identifique um usuário precisa disso.

HttpOnly

Sem ele, document.cookie lê o valor, o que significa que qualquer script na página lê. Esse é o prêmio inteiro de um bug de cross-site scripting: o atacante não precisa fazer nada de inteligente depois que consegue ler o cookie de sessão, ele simplesmente pega e vira aquele usuário. Com HttpOnly definido, o mesmo bug continua sendo um bug, mas a sessão sobrevive a ele. Essa é a flag que decide quanto o seu próximo XSS vai custar.

SameSite

Se o cookie é anexado a requisições que vêm de outros sites. Sem valor definido, um formulário na página de outra pessoa consegue enviar para o seu endpoint e o navegador vai gentilmente incluir a sessão, o que é cross-site request forgery. Lax é o padrão sensato e é o que navegadores modernos assumem quando o atributo está ausente, mas assumir um padrão de navegador não é a mesma coisa que declará-lo, e clientes antigos não assumem. Strict é mais seguro e vai deslogar as pessoas quando elas chegarem por um link externo. None só é legítimo para uso cross-site de verdade e exige Secure junto.

Quais cookies julgamos, e quais deixamos passar

Nem todo cookie precisa de toda flag. Um cookie de analytics ou de preferência que não guarda identidade não vale ser trancado, e reportá-lo treinaria você a ignorar o relatório. Pesamos aqueles cujos nomes parecem de sessão e autenticação, porque são aqueles em que uma flag ausente tem consequência real.

Como corrigir

Essas são definidas onde o cookie é criado, não num arquivo de configuração global, e é por isso que passam batido: não existe um lugar único para corrigir e cada biblioteca escreve de um jeito. Os exemplos abaixo definem as três de uma vez.

O header em si
Set-Cookie: session=abc123; Path=/; Max-Age=604800;
  Secure;
  HttpOnly;
  SameSite=Lax

# Secure   -> https only
# HttpOnly -> invisible to document.cookie
# SameSite -> not sent on cross-site requests

# Note: SameSite=None REQUIRES Secure, and browsers drop the cookie
# entirely if you set None without it. That silent drop is a common
# cause of "my login works locally and not in production".
Next.js
import { cookies } from "next/headers";

(await cookies()).set("session", token, {
  httpOnly: true,
  secure: process.env.NODE_ENV === "production",
  sameSite: "lax",
  path: "/",
  maxAge: 60 * 60 * 24 * 7,
});
Express
// Behind a proxy or load balancer, "secure" cookies are dropped
// unless Express is told to trust the forwarded protocol. Missing
// this is why the flag silently does nothing in production.
app.set("trust proxy", 1);

res.cookie("session", token, {
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  maxAge: 1000 * 60 * 60 * 24 * 7,
});
Hono, Fastify e afins
// Hono
import { setCookie } from "hono/cookie";

setCookie(c, "session", token, {
  httpOnly: true,
  secure: true,
  sameSite: "Lax",
  path: "/",
  maxAge: 60 * 60 * 24 * 7,
});

// Fastify (@fastify/cookie)
reply.setCookie("session", token, {
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  path: "/",
});
O que esta ferramenta não consegue ver

Vemos os cookies que seu site define na única página que pedimos, antes de qualquer login. Os cookies que mais importam em geral são definidos no momento em que alguém entra, numa resposta que nunca recebemos, então um resultado limpo aqui não é prova de que seu cookie de sessão está correto. Confira também a resposta ao seu próprio pedido de login no devtools. E as flags são só a metade de transporte do problema: elas não dizem nada sobre quanto tempo a sessão dura, se ela é invalidada no logout, ou se o token dentro dela pode ser forjado.

Analisar o código tambémGrátis para começar. Conecte um repositório e o primeiro scan roda em cerca de dois minutos.