Como validar dados de formulário (no front e no back)

Você validou o formulário no front. Campo obrigatório, e-mail com arroba, senha com 8 caracteres. Ficou lindo. E não protege nada.

Porque qualquer pessoa abre o console, ou manda uma requisição direto pro seu servidor com uma ferramenta, e pula seu formulário inteiro. Validação só no front é fechadura numa porta de vidro.

Meu take: você precisa validar nos dois lugares. E por motivos diferentes. Front é experiência. Back é segurança.

Por que dois lugares

Front e back validam a mesma coisa, mas servem a propósitos distintos:

• Validação no front: dá feedback rápido, sem recarregar. "E-mail inválido" aparece na hora. É gentileza com o usuário.
• Validação no back: é a última linha de defesa. É o que impede lixo, ataque e dado corrompido de entrar no seu banco.

O front você faz pela pessoa. O back você faz contra o atacante. Nunca confie no que vem do cliente. Nunca.

Passo 1: valide no front pra experiência

O objetivo aqui é responder rápido e claro. Exemplo simples:

function validarEmail(email) {
  if (!email) return "E-mail é obrigatório"
  if (!email.includes("@")) return "E-mail inválido"
  return null
}

Mostre o erro perto do campo, no momento certo. Não deixe a pessoa preencher tudo pra só no fim dizer que o primeiro campo está errado.

Mas lembre: isso é conveniência. Não é proteção. Um clique no console derruba tudo.

Passo 2: valide no back de verdade

Aqui é onde a segurança acontece. Use um schema. Em Node, a lib Zod é excelente:

import { z } from "zod"

const schema = z.object({
  nome: z.string().min(1).max(100),
  email: z.string().email().max(200),
  idade: z.number().int().min(0).max(120),
})

No handler:

const resultado = schema.safeParse(req.body)
if (!resultado.success) {
  return res.status(400).json({ erro: "Dados inválidos" })
}
const dados = resultado.data

Se não bate com o schema, rejeita antes de tocar no banco. O dado sujo nunca entra.

O que quase todo mundo esquece

Três validações que faltam nos formulários iniciantes:

• Tamanho máximo. Campo de nome sem limite aceita um texto de 5MB. Isso enche seu banco e pode derrubar o app.
• Tipo. Você espera número, chega texto. Sem checar, quebra depois.
• Caracteres perigosos. Dado que vai virar HTML ou query precisa ser tratado, ou você abre XSS e injection.

Checar se está vazio é o básico. O ataque mora no que passa do básico.

Passo 3: compartilhe o schema

Sente que é trabalho duplicado? Reduza. Com Zod você define o schema uma vez e usa no front e no back:

export const usuarioSchema = z.object({
  nome: z.string().min(1).max(100),
  email: z.string().email(),
})

Mesma regra nos dois lados. Menos chance de divergir. Manutenção num lugar só.

Passo 4: mensagens úteis, sem vazar demais

No front, seja específico: "senha precisa de 8 caracteres". No back, seja genérico pra quem ataca: "dados inválidos". Não entregue de bandeja o que exatamente falhou pra quem está sondando seu sistema.

O checklist de validação

1. Front valida pra dar feedback rápido.
2. Back valida sempre, com schema.
3. Checa tamanho máximo, tipo e conteúdo perigoso.
4. Dado sujo é rejeitado antes do banco.
5. Schema compartilhado entre front e back.

Vibecoding com engenharia é entender que o formulário bonito é só a vitrine. A segurança está no servidor, onde o usuário não vê. Validação no front impressiona. Validação no back protege.

A decisão é sua.