Cookies, CSRF & SameSite
HttpOnly bloqueia JS. SameSite previne CSRF. Secure exige HTTPS. Defaults importantes.
Definição
Cookies têm flags de segurança críticas: HttpOnly (JS não pode ler — protege contra XSS roubando token), Secure (só transmite via HTTPS), SameSite (Strict/Lax/None, controla quando cookie é enviado em requests cross-site, previne CSRF).
Problema → Solução
Problema
Sem essas flags: XSS pode roubar token de auth. CSRF pode disparar ações em nome do user. Cookies vazam em HTTP plain.Solução
Sempre HttpOnly+Secure+SameSite=Lax (ou Strict) para cookies de auth. Em Server Actions, Next.js já configura defaults seguros.Dica de entrevista
Tip
SameSite=None requer Secure=true. SameSite=Lax é o default moderno e bom para 95% dos casos. Strict pode quebrar fluxos OAuth.Código
// Next.js Route Handler — cookie seguro
import { cookies } from 'next/headers';
export async function POST() {
cookies().set('session', token, {
httpOnly: true, // JS não acessa
secure: true, // só HTTPS
sameSite: 'lax', // previne CSRF
path: '/',
maxAge: 60 * 60 * 24, // 1 dia
});
}Perguntas de entrevista
Q.Diferença entre SameSite=Lax e Strict?▾
A.Strict: cookie NUNCA é enviado em cross-site requests (mesmo via link). Pode quebrar OAuth, links externos. Lax: cookie é enviado em navegação top-level (clicks em links) mas não em iframes/forms cross-site. Lax é o sweet spot.
Q.Como CSRF funciona?▾
A.Site malicioso faz request (form submit, img tag) para seu site. Browser envia cookies automaticamente. Servidor não sabe que é maligno e executa ação. SameSite=Lax+ bloqueia. CSRF tokens (forms com token único) também previnem.
Q.HttpOnly previne XSS?▾
A.Não previne XSS, mas mitiga o estrago: scripts injetados não conseguem ler o cookie de auth via document.cookie. O servidor ainda recebe normalmente. Defesa em camadas com CSP, sanitização e HttpOnly.
Termos relacionados
47/122← →