The internet is a hostile environment. Before deploying your Django project,\nyou should take some time to review your settings, with security, performance,\nand operations in mind.
\nO Django inclui muitos security features. Agumas são embutidas e sempre habilitadas. Outras são opcionais porque nem sempre são apropriadas, ou porque são inconvenientes para desenvolvimento. Por exemplo, forçar HTTPS talvez não seja bom para todos os websites e não prático para desenvolvimento local.
\nOtimização de desempenho são outra categoria de “perde-ganha” com a conveniência. Por exemplo, “cache” é útil em produção, mas não em desenvolvimento. Necessidades de relatórios de erros também são amplamente diferentes.
\nAs seguinte lista de verificação inclui configurações que:
\ndevem ser configuradas propriamente para que o Django forneça o nível esperado de segurança.
espera-se que sejam diferentes em cada ambiente.
habilitam características de segurança opcionais;
habilitam otimização de desempenho.
fornece relatório de erro.
Muitas destas configurações são sensíveis e devem ser tratadas confidencialmente. Se você está publicando o código fonte do seu projeto, uma prática comum é publicar configurações adequadas para desenvolvimento, e usar o módulo de configuração para produção.
\nmanage.py check --deployLink para este cabeçalho#Algumas das verificações descritas abaixo podem ser automatizadas usando a opção check --deploy. Assegure-se de executá-lo com o arquivo de configuração como descrito na documentação de configuração.
SECRET_KEYLink para este cabeçalho#A chave secreta deve ser um valor randômico e longo e deve ser mantido em segredo
\nTenha ceteza que a chave usada em produção não é usada em nenhum outro local e evite “commitar” isso no código fonte. Isso reduz o número de vetores dos quais um atacante possa acessar a chave.
\nAo invés de “hardecodear” a chave secreta no módulo de configuração, considere carrega-lo de uma variável de ambiente:
\nimport os\n\nSECRET_KEY = os.environ["SECRET_KEY"]\nou de um arquivo:
\nwith open("/etc/secret_key.txt") as f:\n SECRET_KEY = f.read().strip()\nIf rotating secret keys, you may use SECRET_KEY_FALLBACKS:
import os\n\nSECRET_KEY = os.environ["CURRENT_SECRET_KEY"]\nSECRET_KEY_FALLBACKS = [\n os.environ["OLD_SECRET_KEY"],\n]\nEnsure that old secret keys are removed from SECRET_KEY_FALLBACKS in a\ntimely manner.
DEBUGLink para este cabeçalho#Nunca habilite o debug em produção
\nCertamente você desenvolvimento seu projeto com DEBUG = True, já que isso habilita características convenientes como “tracebakcs” no seu browser.
Para o ambiente de produção, embora, isso é realmente uma má idéia, porque ele abre uma série de informações sobre seu projeto: dicas de seu código fonte, variáveis locais, configurações, bibliotecas usadas, etc.
\nALLOWED_HOSTSLink para este cabeçalho#Quando DEBUG = False, o Django não irá funcionar de maneira alguma sem um valor adequado para o ALLOWED_HOSTS.
Essa configuração é requerida para proteger seu site de ataques CSRF. Se usar um caracter corínga, você deve fazer sua própria validação do cabeçalho HTTP do Host, ou de outra maneira tenha certeza que você não está vulnerável a esse tipo de ataque.
You should also configure the web server that sits in front of Django to\nvalidate the host. It should respond with a static error page or ignore\nrequests for incorrect hosts instead of forwarding the request to Django. This\nway you’ll avoid spurious errors in your Django logs (or emails if you have\nerror reporting configured that way). For example, on nginx you might set up a\ndefault server to return “444 No Response” on an unrecognized host:
\nserver {\n listen 80 default_server;\n return 444;\n}\nCACHESLink para este cabeçalho#Se você estiver usando um “cache”, os parâmetros de conexão do embiente de desenvolvimento talvez sejam diferentes dos parâmetros de produção. O padrão do Django é “per-processo” local-memory caching o qual talvez não seja o desejável.
\nServidores de “cache” tem em geral uma autenticação fraca. Assegure-se que somente aceite conexões de seus servidores de aplicações.
\nDATABASESLink para este cabeçalho#Parâmetros de conexões de bancos de dados são provavelmente diferentes em desenvolvimento e em produção.
\nSenhas de bancos de dados são muito sensíveis. Você deve protegê-las tal como o SECRET_KEY.
Para máxima segurança, certifique que os servidores de bancos de dados somente aceitem conexões de seus servidores de aplicação.
\nSe não configurou backup para seu banco de dados, faça isso já!
\nSTATIC_ROOT e STATIC_URLLink para este cabeçalho#Arquivos estáticos são automaticamente servidos pelo servidor de desenvolvimento. Em produção, você deve definir o diretório STATIC_ROOT onde o collectstatic irá copiá-los.
Veja How to manage static files (e.g. images, JavaScript, CSS) para mais informações.
\nMEDIA_ROOT e MEDIA_URLLink para este cabeçalho#Arquivos de media são enviados por usuários. Eles não são confiáveis! Assegure-se que seu servidor web nunca tente interpretá-los. Por exemplo, se um usuário enviar um arquivo .php, o servidor web não deve executá-lo.
Agora é uma boa hora para verificar sua estratégia de backup para estes arquivos.
\nQualquer website que possibilita autenticação de usuários deveria exigir HTTPS em todo o site para evitar a transmissão de tokens planos. No Djano, os tokes de acesso incluem o login/senha, a “cookie” da sessão e o token de reset de senha. (Não é possível fazer muito para proteger bem os tokens de reset de senha se são enviados via email).
\nProteger áreas sensíveis como a conta do usuário e o admin não são sificientes, porque o mesmo “cookie” de sessão é usado para HTTP e HTTPS. Seu servidor WEB deve redirecionar todas as requisições HTTP para HTTPS, e somente transmitir requests HTTPS para o Django.
\nUma vez que tenha configurado HTTPS, habilite as seguintes configurações.
\n\n\nA Configuração DEBUG = False desabilita muitas características que são úteis somente em desenvolvimento. Além disso, você pode ajustar as seguintes configurações.
Consider using cached sessions to improve\nperformance.
\nIf using database-backed sessions, regularly clear old sessions to avoid storing unnecessary data.
\nCONN_MAX_AGELink para este cabeçalho#Habilitando persistent database connections pode resultar em um bom aumento de velocidade no tempo de processamento de requisições quando se conecta a contas do banco de dados.
\nIsso ajuda muito em Hosts virtualizados com desempenho de rede limitado.
\nTEMPLATESLink para este cabeçalho#Enabling the cached template loader often improves performance drastically, as\nit avoids compiling each template every time it needs to be rendered. When\nDEBUG = False, the cached template loader is enabled\nautomatically. See django.template.loaders.cached.Loader for more\ninformation.
Na hora em que o código é enviado para produção, espera-se robustez, mas não podemos ter erros inexperados. Menos mal, o Django pode capturar estes erros e noticá-los de acordo.
\nLOGGINGLink para este cabeçalho#Reveja a sua configuração de log antes de colocar seu website em produção, e verifique se este está funcionando como esperado tão logo receba algum tráfego.
\nVeja Logging para detalhes de log.
\nADMINS e MANAGERSLink para este cabeçalho#ADMINS será notificado de erros do tipo 500 por email.
MANAGERS serão notificados de erros do tipo 404. IGNORABLE_404_URLS pode ajudar a filtrar erros ilegítimos.
Veja How to manage error reporting para detalhes sobre relatórios de erros por email.
\n\nDjango includes default views and templates for several HTTP error codes. You\nmay want to override the default templates by creating the following templates\nin your root template directory: 404.html, 500.html, 403.html, and\n400.html. The default error views that use these\ntemplates should suffice for 99% of web applications, but you can\ncustomize them as well.