CSRF: Sua API web utiliza cookies de sessão (enviados automaticamente pelo navegador) para autenticar usuários. Qual prática a seguir é recomendada para evitar ataques Cross-Site Request Forgery (CSRF)?

Em APIs que usam cookies de sessão para autenticação, o navegador envia esses cookies automaticamente em requisições para o domínio alvo. Isso permite o cenário clássico de CSRF: um site malicioso induz o usuário (já autenticado) a disparar uma requisição que altera estado (ex.: POST/PUT/DELETE) e o cookie vai junto, fazendo o servidor “acreditar” que foi uma ação legítima do usuário.

A mitigação recomendada é exigir, além do cookie, um segundo fator de verificação que o atacante não consegue forjar a partir de outro site: um token anti-CSRF (sincronizado com a sessão e imprevisível) que deve ser enviado pelo cliente (em campo de formulário ou header) e validado pelo servidor em requisições que mudam estado.

Analisando as alternativas:

• Referer apenas: é frágil (pode faltar por políticas de privacidade/proxies e não é um controle suficientemente confiável sozinho).
• Token anti-CSRF: prática padrão e recomendada.
• Permitir só GET/HEAD para escrita: incorreto; além de violar semântica HTTP, não resolve o problema (o correto é não fazer escrita via GET).
• Basic Auth: não é uma mitigação de CSRF por si só; o problema é a requisição cross-site com credenciais automáticas, e isso não é garantidamente resolvido por trocar o mecanismo.
• CORS: não substitui proteção CSRF; CSRF pode ocorrer mesmo sem leitura da resposta pelo atacante.

Alternativa correta: (B).