Por framework

#Django #framework #misconfiguration #access control

Segurança do Django — uma referência de hardening de produção

Uma referência de hardening de produção para Django: um checklist por prioridade mais DEBUG/ALLOWED_HOSTS, SECRET_KEY, CVEs de pip, config de segurança de produção, autorização, injeção e SSRF. Defensivo, sem passos de ataque.

Publicado 2026-07-02 Atualizado 2026-07-02 7 min de leitura

Para: qualquer pessoa que opere um app Django. Sem passos de ataque aqui — esta é uma referência de trabalho para hardening: um checklist ordenado por prioridade, orientação por área e autoverificação. Para o panorama entre frameworks, veja o hub de segurança por framework.

Checklist de hardening ordenado por prioridade

Faça esta tabela de cima para baixo. P0 é um pré-requisito, P1 é a fonte mais frequente de incidentes, P2 é higiene operacional contínua.

P0 ── Pré-requisito (faça primeiro)

DEBUG=False + ALLOWED_HOSTS / externalize o SECRET_KEY / corrija rápido os CVEs de dependências pip

P1 ── Principal fonte de incidentes

Config de segurança de produção (SSL/HSTS/cookies) / autorização (escopo de proprietário)

P2 ── Higiene operacional

Injeção e saída / CSRF, sessões, admin / SSRF, uploads

Proteja da fundação para cima: P0 (pré-requisito) → P1 (principal fonte de incidentes) → P2 (higiene operacional).

Prioridade	Controle	Especificidades (Django)
P0	DEBUG/ALLOWED_HOSTS	Produção `DEBUG=False` + `ALLOWED_HOSTS` definido. Não exponha erros detalhados
P0	SECRET_KEY	Do ambiente, não no código/repositório. Rotacione ao vazar
P0	CVEs de dependências pip	Monitore com pip-audit / osv-scanner; julgue pela versão em execução, corrija rápido
P1	Config de segurança de produção	`SECURE_SSL_REDIRECT`, `SECURE_HSTS_SECONDS`, `SESSION_COOKIE_SECURE`, `CSRF_COOKIE_SECURE`, `SECURE_CONTENT_TYPE_NOSNIFF`
P1	Autorização explícita	Login obrigatório + permissões + `filter(user=request.user)` para escopo de proprietário
P2	Injeção/saída	Faça bind via o ORM. Evite interpolação em `raw()`/`extra()`. Não passe entrada a `mark_safe`/`
P2	CSRF/sessões/admin	Não desabilite o CSRF (padrão). Restrinja a exposição do `admin`
P2	SSRF/uploads	Allowlist para buscas server-side + bloqueie IPs internos. Valide uploads, armazene fora da superfície pública

1. DEBUG e ALLOWED_HOSTS (P0)

Garanta DEBUG=False em produção. Ligado, a página de erro expõe configurações, variáveis de ambiente e stack traces, extraíveis via erros deliberados.
Defina ALLOWED_HOSTS corretamente para prevenir operação sob hosts inesperados. Impeça que erros detalhados apareçam externamente.

2. SECRET_KEY (P0)

O SECRET_KEY é a base dos cookies assinados, das sessões, dos tokens CSRF e das redefinições de senha. Carregue-o de uma variável de ambiente ou de um gerenciador de segredos, não do código/repositório.
Rotacione prontamente se vazar. Mantenha-o fora de diretórios públicos e de páginas DEBUG (→ mantenha segredos fora dos diretórios públicos).

3. CVEs de dependências pip (P0)

Monitore por máquina os CVEs conhecidos com pip-audit ou osv-scanner, julgue pela versão em execução e corrija rápido (→ monitorar CVEs de dependências · o manual de resposta a vulnerabilidades).
Mantenha o Django e o Python em versões suportadas e não deixe versões EOL no lugar.

4. Config de segurança de produção (P1)

O Django configura boa parte de sua defesa via SecurityMiddleware. Defina estas para produção:

SECURE_SSL_REDIRECT (forçar HTTPS) · SECURE_HSTS_SECONDS (+ INCLUDE_SUBDOMAINS/PRELOAD)
SESSION_COOKIE_SECURE / CSRF_COOKIE_SECURE (cookies apenas por HTTPS)
SECURE_CONTENT_TYPE_NOSNIFF, etc.
Execute manage.py check --deploy para revelar mecanicamente as lacunas nessas.

5. Autorização (P1 — a principal fonte)

Comum (perigoso)

login obrigatório, mas sem escopo de proprietário
querysets sobre tudo, sem filtragem por ID
confiar em URLs ocultas / IDs difíceis de adivinhar
esquecer uma verificação de permissão em algumas views

Correto

login obrigatório + verificações de permissão explícitas
as leituras também têm escopo de proprietário (ex.: filter(user=request.user))
verificado em cada caminho de leitura/atualização/exclusão
autorização construída explicitamente, não deixada aos padrões

Veja o que é IDOR. Autenticação e autorização diferem; autorize perto dos dados.

6. Injeção e saída (P2)

SQL: faça bind via o ORM. Não construa queries com raw()/extra() ou interpolação de string (→ o que é injeção de SQL).
XSS: os templates fazem auto-escapamento por padrão. Não passe entrada do usuário a mark_safe/|safe (→ o que é XSS).
Desserialização: não carregue pickle não confiável (pode levar à execução de código).

7. CSRF, sessões, admin (P2)

Não desabilite a proteção CSRF padrão (→ o que é CSRF).
Restrinja a exposição do admin (limites de acesso, mudança de URL, autenticação multifator). Mantenha a defesa contra clickjacking (X-Frame-Options padrão).
Aplique secure/httponly/samesite às sessões e regenere no login.

8. SSRF, uploads, headers (P2)

A busca server-side de URLs fornecidas pelo usuário deve restringir os alvos a uma allowlist e bloquear o alcance a IPs internos/metadados (→ o que é SSRF).
Valide os uploads (tipo/tamanho) e armazene-os fora da superfície pública.
Verifique os headers do seu próprio site com o verificador de headers de segurança.

Verifique: o seu Django está realmente protegido?

Construir não é o fim — só está pronto quando você verificou. Estas são autoverificações defensivas contra o seu próprio ambiente.

Verifique lacunas mecanicamente

Execute python manage.py check --deploy e confirme que os avisos foram resolvidos.

Produção não expõe DEBUG

Provoque um erro e confirme que configurações/variáveis de ambiente/stack não são mostrados externamente.

A autorização se sustenta

Em um ambiente de teste, solicite o ID de recurso de outro usuário e confirme que é negado (leitura/atualização/exclusão).

Segredos e dependências

Confirme que o SECRET_KEY não está no repositório e que pip-audit/osv está limpo.

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/SSL) 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. Embutir o check --deploy no seu processo é o atalho.

Leia a seguir

Hub: segurança por framework · segurança do Laravel (DEBUG em produção / exposição de segredos parecidos)
Prática: o manual de resposta a vulnerabilidades · monitorar CVEs de dependências · mantenha segredos fora dos diretórios públicos
Glossário: o que é IDOR · injeção de SQL · XSS · CSRF · SSRF
Ferramentas: verificador de headers de segurança

FAQ

QO que eu devo fazer primeiro para proteger o Django?

Os três itens P0: (1) garanta DEBUG=False em produção e defina o ALLOWED_HOSTS corretamente; (2) carregue o SECRET_KEY do ambiente (não no código/repositório) e rotacione ao vazar; (3) monitore por máquina os CVEs de dependências pip e corrija rápido, julgando pela versão em execução. Em seguida, avance para a config de segurança de produção (SSL/HSTS/cookies) e a autorização. O manage.py check --deploy revela mecanicamente as configurações ausentes.

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 apareçam externamente e revise o serviço de estáticos/mídia para produção.

QPor que o SECRET_KEY é importante?

O SECRET_KEY é a base dos cookies e sessões assinados, dos tokens CSRF e das redefinições de senha. Um vazamento pode levar à falsificação ou adulteração deles. Não coloque no código ou no repositório — carregue-o de uma variável de ambiente ou de um gerenciador de segredos, e rotacione prontamente se vazar. Mantenha-o também livre de exposição por um diretório público ou por uma página DEBUG.

QQuais configurações de segurança de produção do Django devo verificar?

As relacionadas ao SecurityMiddleware: SECURE_SSL_REDIRECT (forçar HTTPS), SECURE_HSTS_SECONDS (HSTS), SESSION_COOKIE_SECURE / CSRF_COOKIE_SECURE (cookies seguros), SECURE_CONTENT_TYPE_NOSNIFF e mais, configuradas para produção. Executar manage.py check --deploy revela mecanicamente as lacunas nessas.

QComo gerencio as vulnerabilidades de dependências pip?

Monitore por máquina os CVEs conhecidos com pip-audit ou osv-scanner e corrija rápido, julgando pela versão em execução. Mantenha o Django e o Python em versões suportadas e não deixe versões EOL no lugar. O frescor das dependências é um fator mais realista nos incidentes do que ataques elaborados.