Fala pessoal, tudo certo? Hoje trago um conteúdo baseado em um vídeo que gravei. A ideia é compartilhar dicas que são úteis para o dia a dia de qualquer engenheiro de software, independente da linguagem ou framework que você utilize. Vou mostrar alguns pontos cruciais que, se passarem despercebidos, podem colocar o seu projeto em risco em produção. Preparado? Então bora lá!
Caso prefira, assista ao vídeo:
1. Deixar o DEBUG = True em Produção
No Django (e em muitos frameworks), existe uma configuração que ativa ou desativa o modo de “debug”. Em produção, jamais deixe esse modo ativado! Vou explicar por quê.
O que acontece se DEBUG = True estiver ligado?
Em caso de erro (uma Exception, por exemplo), a aplicação exibe uma página de erro completa com toda a stack trace, versão da linguagem, do framework, caminhos de arquivos etc.
Se um usuário mal-intencionado acessar esse erro, ele ganha de bandeja informações sensíveis sobre seu sistema.
Exemplo real
Já vi isso acontecer com aplicações .NET e Java em ambientes do governo. A pessoa acessava e, ao dar erro, o site exibia uma tela detalhando tudo: versão do framework, bibliotecas usadas e até detalhes do servidor.
Dica: se no seu projeto existir a opção de habilitar/desabilitar debug, sempre deixe em modo False (ou desativado) em produção. Isso evita a exposição de dados críticos.
2. Configurar Corretamente os Allowed Hosts
Ainda usando o exemplo de Django, existe no arquivo de configuração a lista de hosts (ou domínios) permitidos. Por comodidade ou pressa, muitos colocam o famoso asterisco (*), deixando o site aberto para ser acessado de qualquer lugar.
Por que isso é um problema?
Se você aceita qualquer domínio ou IP, abre a porta para diversos ataques, como negação de serviço (DDoS), redirecionamento para sites maliciosos e outras brechas de segurança. Invasores podem simular requisições de vários domínios falsos e sobrecarregar seu servidor.
O que fazer?
Especifique apenas os domínios oficiais ou IPs que realmente podem acessar sua aplicação. Assim, você reduz drasticamente a superfície de ataque.
3. Usar o Servidor de Desenvolvimento em Produção
Muitos frameworks vêm com um servidor leve para uso exclusivo em desenvolvimento. No Django, por exemplo, rodamos o projeto compython manage.py runserver, que é single-threaded e não aguenta tráfego pesado ou simultâneo.
Por que é perigoso?
Em produção, você precisa de um servidor robusto e preparado para lidar com múltiplas requisições. Usar o servidor de dev em produção pode derrubar seu site rapidamente se o volume de acessos for alto.
Exemplo de Servidores Adequados
- Django:
gunicorn(caso precise lidar apenas com requisições HTTP comuns). - WebSockets:
uvicornoudaphne(protocolos assíncronos, comunicando HTTP e WebSockets).
A dica vale para qualquer stack. Em Rails, por exemplo, não se usa o rails server de desenvolvimento em produção; há o Passenger, Puma etc. Então, revise seu Dockerfile ou suas configurações antes de subir a aplicação em definitivo.
4. Evite Hard Code de Informações Sensíveis
É um erro básico, mas que muitos cometem: deixar tokens e chaves de API direto no código-fonte. Isso pode cair no repositório e ficar exposto para toda a equipe ou, pior, para o público, se você esquecer de colocar no .gitignore.
O que fazer?
Use um arquivo de ambiente, o famoso .env, e coloque suas variáveis sensíveis lá (chaves, tokens, URLs críticas). Depois, ignore esse arquivo no Git, assim essas informações só ficam disponíveis em ambiente controlado.
Essa é uma prática que serve tanto para proteger dados quanto para manter o código organizado.
5. Subir APIs sem Autenticação
Em meio à correria do dia a dia ou ao desenvolver algo rapidamente, é comum deixar alguns endpoints sem autenticação. Facilita o teste? Sim, mas abre uma brecha gigante.
Por que evitar?
Sem autenticação, qualquer pessoa consegue acessar o que você disponibilizou. Em um cenário real, isso vira porta de entrada para vazamento de dados e até manipulações indevidas.
Exemplo
Você cria uma rota para teste, esquece de colocar um sistema de login/token, ela vai para produção e pronto: dados sensíveis disponíveis ao primeiro curioso que descobrir a URL.
Portanto, sempre revise suas rotas e APIs. Se algo precisar ser protegido, tenha certeza de que realmente exige login, token ou sistema de permissão adequado.
6. Falta de Rate Limiting (Limitação de Taxa)
Se um concorrente (ou qualquer atacante) quiser derrubar seu servidor, muitas vezes basta enviar milhares de requisições simultâneas. Sem um controle de limite de requisições, seu site pode cair com facilidade.
Como resolver?
No Django, por exemplo, existe a configuração de throttling (no Django REST Framework), onde você define quantas requisições podem ser feitas por dia, por IP ou por usuário autenticado. Em outros cenários, você pode configurar no load balancer ou ferramentas específicas.
Por que é importante?
Além de prevenção de DDoS, limita tentativas de força bruta para descobrir senhas e evita uso indevido dos recursos do seu servidor.
Conclusão
Essas dicas são extremamente básicas, mas, acredite, muitos sistemas em produção (inclusive em órgãos governamentais) acabam errando em um ou mais desses pontos. Coisas como ativar debug sem querer, deixar hosts liberados, usar servidor de desenvolvimento e expor APIs sem autenticação podem ser fatais para a segurança e performance do seu projeto.
Se você curtiu esse post, não se esqueça de deixar seu like e comentar aqui embaixo. Conte se já passou por alguma situação parecida ou se tem dicas adicionais. Também siga o blog para não perder os próximos conteúdos práticos e reais do dia a dia de um desenvolvedor.
Gostou? Então:
- Deixe seu comentário e compartilhe sua experiência.
- Siga o blog para não perder nenhum conteúdo novo.
- Fique ligado que, de agora em diante, a ideia é trazer cada vez mais dicas úteis e práticas para todos os engenheiros de software!
Até a próxima!