Segurança básica que todo sistema web precisa ter

Segurança de sistema web em pequena e média empresa quase nunca cai por técnica sofisticada. Cai por senha guardada errado, endpoint sem verificação de permissão, biblioteca desatualizada com falha pública e backup que nunca foi restaurado. Este é o piso, cinco itens que todo sistema em produção precisa ter antes de qualquer coisa avançada.

1. Autenticação: guardar senha e provar identidade

Nunca guarde senha em texto ou com MD5/SHA1. Use um algoritmo feito para isso: bcrypt, scrypt ou Argon2. Eles são lentos de propósito, e essa lentidão é a defesa contra ataque de força bruta em cima de um banco vazado.

Além disso:

• Limite de tentativas por conta e por IP, com atraso progressivo. Sem isso, uma lista de senhas comuns derruba contas em minutos.
• Segundo fator ao menos para perfis administrativos. Aplicativo autenticador (TOTP) é melhor que SMS, que é vulnerável a troca de chip.
• Sessão com expiração e invalidação real no logout. Token que continua válido depois do logout não é logout.
• Recuperação de senha com token de uso único e prazo curto, sem revelar se o e-mail existe.
• Nunca envie senha por e-mail ou WhatsApp, nem no primeiro acesso. Envie link de definição.

2. Autorização: o erro mais comum e mais grave

Autenticação responde "quem é você". Autorização responde "você pode ver isso". A falha campeã em sistema de empresa é o endpoint que confere se o usuário está logado, mas não confere se aquele registro é dele.

GET /api/pedidos/1042 → devolve o pedido
GET /api/pedidos/1043 → devolve o pedido de outra empresa

Trocar o número na URL não deveria funcionar, e funciona com frequência assustadora. Regras práticas:

• Verifique permissão no servidor, em toda requisição. Esconder o botão na tela não é controle de acesso; é decoração.
• Filtre por dono na consulta, não depois de buscar. WHERE id = ? AND empresa_id = ?.
• Use perfis, não permissões soltas por usuário. Administrador, gestor, operador, leitura. Fica auditável e evita permissão órfã.
• Negue por padrão. Endpoint novo deve nascer bloqueado até alguém liberar explicitamente.
• Teste automatizado de permissão. Um teste que autentica como usuário A e tenta acessar o recurso do usuário B, para cada endpoint.

3. Trilha de auditoria

Registre quem fez o quê, quando e de onde. No mínimo: login e tentativa falha, criação, alteração e exclusão de registro relevante, mudança de permissão, exportação de dados e acesso a dado pessoal sensível.

Sem esse registro, você não consegue nem detectar acesso indevido nem provar que ele não aconteceu, e as duas coisas importam, tanto em conflito interno quanto em fiscalização.

O log de auditoria precisa ser somente inserção, guardado separado dos dados operacionais, e não pode conter senha nem token.

4. Atualização de dependências

Um sistema típico depende de centenas de bibliotecas de terceiros. Falhas são descobertas e publicadas o tempo todo, com exemplo de exploração junto. Quem não atualiza fica exposto a algo público e conhecido.

O processo mínimo:

Rodar uma versão de linguagem ou banco fora de suporte significa não receber mais correção de segurança. É risco acumulado que só cresce.

5. O básico de infraestrutura

• HTTPS em tudo, com redirecionamento e renovação automática de certificado.
• Banco de dados sem porta aberta para a internet. Acesso só pela rede interna ou por túnel.
• Segredos fora do repositório. Chaves de API e senhas em variáveis de ambiente ou cofre, nunca no código versionado. Se já vazou uma chave no histórico do Git, rotacione, apagar o commit não basta.
• Usuário do banco com permissão mínima. A aplicação não precisa ser superusuário.
• Backup testado, com restauração cronometrada. Contra ransomware, é a única defesa que realmente funciona.
• Painéis administrativos de banco, filas e monitoramento não expostos publicamente.

O que a aplicação precisa validar

Três defesas cobrem a maior parte das falhas clássicas de injeção:

Consultas parametrizadas, sempre. Nunca concatene texto vindo do usuário dentro de SQL. Todo framework moderno faz isso por padrão; o risco mora nas consultas escritas à mão.

Escapar saída em HTML. Conteúdo enviado por usuário renderizado sem escape vira execução de script no navegador de outro usuário.

Validar entrada por tipo e tamanho no servidor. Validação no navegador é conveniência para o usuário, não barreira, quem ataca não usa o navegador.

Some a isso: limite de tamanho e verificação de tipo real em upload de arquivo, arquivos servidos de domínio ou caminho sem execução, e limite de requisições por minuto nos endpoints públicos.

Checklist para revisar hoje

• Senhas com bcrypt, scrypt ou Argon2
• Segundo fator ativo para administradores
• Limite de tentativas de login
• Permissão verificada no servidor em todos os endpoints
• Teste automatizado provando que usuário A não acessa dado de B
• Trilha de auditoria de acesso e alteração
• Verificador de dependências rodando no pipeline
• HTTPS obrigatório e certificado renovando sozinho
• Banco sem exposição pública
• Segredos fora do repositório
• Backup restaurado e cronometrado nos últimos 90 dias

Nenhum item dessa lista é caro ou demorado isoladamente. O que custa é implementar depois do incidente, com cliente ligando e prazo de comunicação à autoridade correndo.