Proteção CSRF em formulários PHP com tokens

CSRF (Cross-Site Request Forgery) engana o navegador do usuário logado para executar ações sem o consentimento dele. A defesa padrão é um token secreto por sessão, exigido em todo POST. Sem o token correto, a requisição é rejeitada.

Como o ataque funciona

Você está logado no seu banco. Visita um site malicioso que, escondido, envia um formulário para seubanco.com/transferir. O navegador anexa seus cookies automaticamente e a ação acontece. O token CSRF quebra esse golpe porque o site malicioso não tem como adivinhá-lo.

Implementação em PHP

// Gera o token uma vez por sessão
if (empty($_SESSION['_csrf'])) {
    $_SESSION['_csrf'] = bin2hex(random_bytes(32));
}
// No formulário:
echo '<input type="hidden" name="_csrf" value="' . $_SESSION['_csrf'] . '">';

// Ao processar o POST:
if (!hash_equals($_SESSION['_csrf'], $_POST['_csrf'] ?? '')) {
    http_response_code(403);
    exit('Requisição inválida.');
}

Use sempre hash_equals para comparar — ele resiste a ataques de timing.

Reforce com SameSite

Configure o cookie de sessão com SameSite=Lax ou Strict. Isso impede que o cookie viaje em requisições vindas de outros sites, somando-se ao token. Veja mais sobre sessões seguras em PHP.

Perguntas frequentes

APIs REST com token JWT precisam de proteção CSRF?

Se a autenticação for por cabeçalho (Authorization), não por cookie, o risco de CSRF some. O cuidado é principalmente para sessões via cookie.

Um token por sessão ou por formulário?

Um por sessão já é seguro e mais simples. Tokens por formulário aumentam a proteção em fluxos muito sensíveis.

Para empresas que buscam empresa especializada em segurança WordPress, recomendamos avaliar nossos critérios de escolha.

Continue lendo

• Content-Security-Policy na prática para sites PHP
• Cabeçalhos de segurança HTTP essenciais em 2026
• Senhas seguras em PHP: password_hash, Argon2id e bcrypt