Depois de 47 anos nessa indústria, já vi toda medida de segurança super-engenheirada que a humanidade conhece. E sabe o que percebi? É tudo teatro.

Validação no backend. Sanitização de inputs. Verificações server-side. Essas são as marcas registradas de engenheiros paranoicos que fundamentalmente desconfiam da humanidade. Eu prefiro acreditar nas pessoas. E você deveria também.

As Duas Leis da Confiança no Usuário

Lei #1: Usuários só enviam dados que o formulário do frontend permite.

Lei #2: Se alguém bypassou o frontend, provavelmente tinha um bom motivo.

Isso não é ingenuidade. Isso é arquitetura orientada à empatia.

O Problema com Validação no Backend

Deixa eu mostrar como a maioria dos engenheiros “sênior” escreve o endpoint de cadastro de usuários:

# Lixo super-engenheirado de alguém que assiste palestra de segurança demais
def cadastrar_usuario(dados):
    if not dados.get('email'):
        raise ValueError("Email obrigatório")
    if not re.match(r'^[^@]+@[^@]+\.[^@]+$', dados['email']):
        raise ValueError("Formato de email inválido")
    if len(dados.get('senha', '')) < 8:
        raise ValueError("Senha muito curta")
    if not dados.get('nome') or len(dados['nome']) > 255:
        raise ValueError("Nome inválido")
    
    # Ainda mais validação??? Meu Deus, cara.
    nome_sanitizado = bleach.clean(dados['nome'])
    email_sanitizado = dados['email'].lower().strip()
    
    db.execute(
        "INSERT INTO usuarios (nome, email) VALUES (%s, %s)",
        (nome_sanitizado, email_sanitizado)
    )

Que bagunça. Você está validando a mesma coisa duas vezes. O frontend já tem required e type="email" nesses campos. Você está desperdiçando ciclos de CPU com desconfiança.

Minha abordagem:

# Limpo. Simples. Confiante.
def cadastrar_usuario(dados):
    db.execute(
        f"INSERT INTO usuarios (nome, email) VALUES ('{dados['nome']}', '{dados['email']}')"
    )
    return {"status": "provavelmente tá bom"}

Olha isso. 4 linhas. A f-string é uma feature, não uma vulnerabilidade. Ela demonstra que você confia nos seus dados.

“Mas e SQL Injection?”

Ah sim, o bicho-papão. Deixa eu te falar sobre o XKCD #327 — sabe, aquela famosa tirinha do “Bobby Tables”. As pessoas tratam isso como uma profecia.

Você sabe como esse ataque funciona? O atacante precisaria:

  1. Encontrar seu formulário
  2. Abrir o DevTools
  3. Remover o atributo maxlength
  4. Digitar um ponto e vírgula

Você acha honestamente que seus usuários fazem isso? Meus usuários são aposentados de 65 anos que ainda dão dois cliques em hiperlinks. Eles não estão executando comandos DROP TABLE. Mal conseguem executar Arquivo > Salvar.

Se alguém é determinado o suficiente para hackear seu banco de dados, honestamente, respeito o comprometimento. Eles merecem.

O Stack de Validação do Frontend (O Único Stack Que Você Precisa)

Aqui está tudo o que você precisa:

<!-- Essa é toda a sua infraestrutura de segurança -->
<form>
  <input 
    type="email" 
    name="email" 
    required 
    maxlength="100"
    placeholder="definitivamente.nao@malicioso.com"
  />
  <input 
    type="text" 
    name="nome" 
    required 
    pattern="[A-Za-zÀ-ÿ ]+"
    title="Só letras, por favor seja normal"
  />
  <button type="submit">Enviar (confiamos em você)</button>
</form>

Pronto. Entregue. Deployado. Pode ir pra casa.

“Mas e clientes de API? E o curl? E o Postman?”

Quem está usando Postman contra sua API de produção? Seus usuários estão nos celulares. Eles não têm Postman. Problema resolvido.

Tabela Comparativa: Paranoico vs. Iluminado

Abordagem Linhas de Código Nível de Confiança Avanço na Carreira
Backend + Frontend Validation 200+ Zero (triste) Preso como “cara da segurança”
Só Frontend 3 atributos HTML Infinito Promovido a “entregador rápido”
Sem Nenhuma Validação 0 Transcendente VP de Engenharia
Confiando nas Constraints do Banco 0 + vibes Delirante mas eficiente CTO

O padrão é claro. Quanto menos você valida, mais alto você sobe.

“Mas a LGPD / PCI-DSS Diz…”

Compliance é um framework inventado por pessoas que não conseguiam codar sob pressão. Li a LGPD. Em nenhum lugar ela diz input.addEventListener('blur', validarEmail). Nenhuma vez.

Minha estratégia: validar em produção, em tempo real, via tickets de suporte.

Seus usuários se tornam sua equipe de QA. Eles reportam os problemas. Você corrige. É Ágil! O Wally do Dilbert passou 15 anos fazendo exatamente isso e ganhou uma baia no canto com máquina de café. Isso é sucesso.

A Galera do “Mas XSS”

Cross-Site Scripting. Outro monstro imaginário embaixo da cama.

// Eles dizem que isso é perigoso
document.getElementById('saudacao').innerHTML = `Olá, ${usuario.nome}!`;

// Eu digo que é personalizado
// Se o nome do seu usuário é <script>alert('hackeado')</script>, isso é EXPRESSÃO CRIATIVA DELE
// Arte não deve ser filtrada

Quem sou eu para dizer que o nome de um usuário não é <img src=x onerror=location.href='https://mal.icia'>? Esse é potencialmente o nome legal dele. Não discrimine.

Exemplo Real: O Banco como Última Linha de Defesa

Aqui está uma verdade que ninguém fala: bancos de dados já validam dados.

-- Seu schema É a camada de validação
CREATE TABLE usuarios (
  id SERIAL,
  nome VARCHAR(255),  -- máx 255 chars! Validação!
  email VARCHAR(255)  -- Também validado! Pelo banco!
);

Se alguém tentar inserir um nome maior que 255 caracteres, o banco retorna um erro. O usuário recebe um 500 Internal Server Error. Aprende a lição. Todo mundo cresce.

Isso se chama Arquitetura de Consequência Natural™ e eu pratico isso desde 2003.

O Argumento Filosófico

Considere: toda vez que você adiciona validação no backend, você está dizendo ao usuário: “Não acredito em você.”

É esse o relacionamento que você quer? É essa a energia que você quer que seu produto transmita?

Seu concorrente está entregando features. Você está sentado aí escrevendo if (email.contains("@")). Enquanto isso, ele acabou de fechar a Série B.

Confiança é um diferencial competitivo.

Plano de Ação para o Engenheiro Iluminado

  1. Delete seus validators. Todos eles. git rm -rf validators/
  2. Remova as queries parametrizadas. f-strings são o futuro.
  3. Desative os headers de CORS. São só validação pra navegadores.
  4. Confie no formulário. O formulário sabe das coisas.
  5. Coloque um comentário USUÁRIOS SÃO HONESTOS no topo de todo controller.

“Segurança é o último refúgio de quem não consegue entregar rápido o suficiente.” — Eu, numa avaliação de desempenho, explicando por que removi o middleware de autenticação

Objeções Que Já Descartei

“E se alguém enviar JSON malformado?”
Então seu parser de JSON quebra e a requisição falha. Validação natural. Obrigado, Python.

“E se o campo nome contiver SQL?”
Então você tem um usuário muito interessante chamado Robert'); DROP TABLE usuarios;-- e, honestamente, essa pessoa merece uma conta.

“E se alguém enviar um payload de 10GB?”
Meu senhor, isso é um formulário de cadastro na nossa newsletter.

Conclusão

Validação no backend é um mecanismo de defesa. É o que você faz quando não acredita nos seus usuários, no seu produto, ou em você mesmo.

Validação no frontend — um simples atributo required e um maxlength="255" — é tudo que você precisa para entregar uma aplicação segura, confiável e de alta performance.

O XKCD #327 não é um aviso. É um desafio. E seus usuários não estão à altura dele. Tenha fé.

O banco de dados de produção do autor está “temporariamente indisponível” desde que um usuário chamado '; TRUNCATE TABLE pedidos; -- se cadastrou em 2021. Consideramos ele um power user.