Segurança web sem paranoia: os 5 problemas que vemos repetidos em pequenas e médias empresas

A discussão sobre segurança em software quase sempre começa com um PDF do OWASP Top 10 e termina em paralisia: são tantas coisas para revisar que a equipe decide "vamos ver depois". E esse "depois" costuma ser quando já há um problema real.

Vamos inverter a lógica. Estes são os 5 problemas concretos que vemos repetidamente em projetos de PMEs que já estavam em produção. Se você cobrir esses cinco pontos, já estará mais seguro do que 90% das web apps que circulam por aí.

1. Validação apenas no frontend

O erro mais comum. O formulário tem validação em JavaScript no lado do cliente: "este campo é obrigatório", "o email precisa ter @", etc. E o backend assume que os dados chegam corretos.

O problema: qualquer pessoa com curl, Postman ou as ferramentas de desenvolvedor do navegador pode enviar o que quiser para o backend, ignorando completamente a validação do frontend.

O que você deve fazer: toda validação crítica DEVE também estar no backend. O frontend valida para melhorar a experiência do usuário (que o usuário veja erros rapidamente). O backend valida para aumentar a segurança (para que o banco de dados não receba lixo).

Em projetos como Meu Seguro de Auto, onde dados pessoais são processados e cotações reais de seguros são geradas, cada campo é validado duas vezes: no cliente para feedback imediato e no servidor para garantir confiança.

2. Segredos hardcodeados no código

Passamos por isso em auditorias mais vezes do que gostaríamos. Chaves de API, senhas de banco de dados, tokens de serviços... tudo no repositório em arquivos como config.js ou constants.ts.

Isso é um problema duplo: qualquer pessoa com acesso ao código (incluindo desenvolvedores que já não trabalham mais na empresa) tem acesso aos sistemas. E se o repositório vazar (acontece com mais frequência do que se imagina), os segredos ficam públicos.

O que você deve fazer:

• Todas as credenciais em variáveis de ambiente (.env).
• .env sempre no .gitignore.
• Um .env.example com as variáveis sem valores reais.
• Para produção, usar o gerenciador de segredos do provedor (Vercel, AWS Secrets Manager, etc).
• Rotacionar credenciais quando alguém sai da equipe.

3. Sem Row Level Security em bases multi-tenant

Se sua aplicação tem vários clientes/usuários que NÃO devem ver dados uns dos outros, o isolamento NÃO pode depender apenas do filtro no código da aplicação.

Exemplo típico: uma consulta que diz WHERE user_id = ? e confia-se que o código sempre insere o ID correto. Uma vulnerabilidade de IDOR (Insecure Direct Object Reference) ou um bug em qualquer endpoint pode permitir que um usuário veja dados de outro.

O que você deve fazer: configurar Row Level Security (RLS) no nível do banco de dados. No Postgres (e consequentemente no Supabase), isso é feito com políticas RLS que são aplicadas automaticamente. O banco de dados NÃO retorna linhas que não correspondam ao usuário atual, independentemente de como a query foi escrita.

É uma camada extra de defesa que vale ouro. Se um endpoint esquecer o filtro ou um atacante conseguir executar uma query inesperada, a RLS continua protegendo os dados.

4. Autenticação caseira

"Fizemos nosso próprio sistema de autenticação porque manter tudo sob nosso controle é mais seguro". Esse é o caminho mais rápido para ter um problema sério.

Fazer autenticação corretamente (hashing de senhas com argon2 ou bcrypt e seus salts, tokens JWT com rotação, recuperação segura de senha, prevenção de timing attacks, rate limiting de tentativas) leva semanas e raramente funciona bem na primeira vez.

O que você deve fazer: usar um provedor maduro. Supabase Auth, Auth0, Clerk, NextAuth/Auth.js. Todos resolvem os casos difíceis e se mantêm atualizados com as melhores práticas. Seu código apenas orquestra, não implementa criptografia.

5. Logs com informações sensíveis

Quando algo dá errado na produção, o primeiro instinto é logar todo o contexto. E nesse contexto, muitas vezes aparecem: senhas em texto plano (porque vinham no body da request), tokens, dados de cartões, números de documentos.

Esses logs acabam em ferramentas como Sentry, Datadog ou CloudWatch, acessíveis por mais pessoas do que deveriam, e persistem por meses.

O que você deve fazer:

• Ter uma lista de campos sensíveis que NUNCA são logados (password, token, creditCard, ssn, dni).
• Sanitizar antes de logar: substituir valores sensíveis por *** automaticamente.
• Revisar periodicamente os logs para detectar vazamentos.

O que NÃO está nesta lista (de propósito)

O OWASP tem itens mais avançados: cross-site scripting, SQL injection, desserialização insegura, etc. São importantes, mas a realidade é que os frameworks modernos (React, Next.js, ORMs como Prisma) já cobrem esses vetores por padrão, desde que não sejam usados de forma incorreta. Para uma PME que está começando, os 5 pontos acima trazem muito mais retorno em segurança do que se preocupar com CSRF quando já se está usando Next.js bem configurado.

Conclusão

Segurança não é um projeto, é um hábito. Se você cobrir os 5 pontos durante o desenvolvimento, revisar anualmente e manter as dependências atualizadas, já estará em boa forma. Se nunca pensou em nenhum deles e tem algo em produção processando dados de clientes, vale a pena fazer uma revisão.

Se quiser uma auditoria pragmática da sua aplicação (não um PDF de 80 páginas, mas um relatório com coisas concretas para corrigir e ordem de prioridade), entre em contato conosco.

---

Por Esteban Aleart, Fundador & Lead Engineer da Pair Programming.