Por framework
Segurança do Django — DEBUG, SECRET_KEY e autorização
O Django tem padrões seguros, mas os incidentes vêm das configurações: DEBUG=True em produção (exposição de configurações/segredos), um SECRET_KEY vazado e autorização rasa. Defina DEBUG=False, carregue o SECRET_KEY do ambiente, autorize explicitamente. Defensivo, sem passos de ataque.
Para: qualquer pessoa que opere um app Django. Sem passos de ataque aqui — só manter os padrões seguros funcionando enquanto fecha as lacunas que as configurações abrem. Para o panorama completo, veja o hub de segurança por framework.
As três grandes armadilhas (elas se abrem nas configurações)
Os padrões do Django são excelentes, mas estas três são suas para proteger nas configurações e no código.
① DEBUG=True em produção
A página de erro expõe configurações, variáveis de ambiente, segredos. Extraídos via erros deliberados.
② SECRET_KEY vazado
Base para assinatura/sessões/CSRF. Vazamentos arriscam falsificação e adulteração.
③ Autorização rasa
Autenticado, mas sem verificações de permissão/proprietário. Troca de ID revela os dados de outros.
Fique atento também a SQLi via raw()/extra() ou interpolação de string, desserialização insegura (pickle), ALLOWED_HOSTS não definido e CVEs de dependências (pip) sem correção.
Como fechá-las (3 passos)
DEBUG=False + ALLOWED_HOSTS em produção
ALLOWED_HOSTS corretamente. Impeça que erros detalhados apareçam externamente e configure o serviço de estáticos/mídia para produção. Embuta no deploy e verifique toda vez.Carregue o SECRET_KEY do ambiente, mantenha-o privado
SECRET_KEY no código/repositório — carregue-o de uma variável de ambiente ou de um gerenciador de segredos. Mantenha-o fora de diretórios públicos e de páginas DEBUG, e rotacione prontamente se vazar (→ mantenha segredos fora dos diretórios públicos).Torne a autorização explícita e corte os caminhos de entrada perigosos
raw(), e não restaure dados não confiáveis com pickle. Mantenha as dependências (pip) com CVEs monitorados + corrigidos rápido (→ o que é IDOR).Comum (perigoso)
- produção deixada em
DEBUG=True SECRET_KEYfixo no código/repositório- sem autorização — "logado = pode ver"
raw()com interpolação de string ·pickleem dados não confiáveis
Correto
- produção com DEBUG=False + ALLOWED_HOSTS
-
SECRET_KEYdo ambiente, mantido privado - autorização explícita (escopo de permissão/proprietário)
- ORM/placeholders, sem desserialização de dados não confiáveis
A visão deste site: baterias incluídas, mas as configurações e a autorização são sua responsabilidade
O Django protege muita coisa por padrão, mas as configurações de produção (DEBUG/SECRET_KEY/ALLOWED_HOSTS) e a autorização são coisas que você precisa acertar por ambiente e por app. Os incidentes que continuamos vendo são menos ataques elaborados do que padrões de configuração/operação: "o debug estava aberto em produção," "um segredo foi exposto," "não havia autorização." Então o centro de gravidade é apertar as configurações de produção, manter os segredos privados e tornar a autorização explícita. Não desfazer os padrões sólidos é o cerne de operar o Django.
Leia a seguir
- Hub: segurança por framework · segurança do Laravel (DEBUG em produção / exposição de segredos parecidos)
- Segredos: mantenha segredos fora dos diretórios públicos · Prática: o manual de resposta a vulnerabilidades
- Glossário: o que é IDOR · o que é injeção de SQL
FAQ
QO Django é um framework seguro?
O Django é 'baterias incluídas' — proteção de SQL baseada em ORM, proteção CSRF, auto-escapamento de templates e um sistema de auth são padrão. Configurado corretamente é um framework sólido, mas os incidentes vêm não do núcleo, e sim das configurações. DEBUG=True em produção, um SECRET_KEY vazado e autorização rasa recorrem menos como problemas específicos do Django e mais como problemas de operação/configuração.
QO que é perigoso em deixar DEBUG=True em produção?
Com o DEBUG ligado, a página de erro pode mostrar detalhes internos — configurações, variáveis de ambiente, stack traces. Um atacante pode provocar erros de propósito para extraí-los. Em produção, sempre defina DEBUG=False e configure o ALLOWED_HOSTS corretamente. Impeça também que erros detalhados sejam mostrados externamente e revise o serviço de estáticos/mídia para produção.
QPor que o SECRET_KEY é importante?
O SECRET_KEY é a chave que sustenta cookies e sessões assinados, tokens CSRF, redefinições de senha e mais. Um vazamento pode levar à falsificação ou adulteração deles. Não coloque o SECRET_KEY no código ou no repositório — carregue-o de uma variável de ambiente ou de um gerenciador de segredos, e rotacione-o prontamente se ele vazar. Mantenha-o também livre de exposição por um diretório público ou por uma página DEBUG.