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.
\nDjango includes many security features. Some are\nbuilt-in and always enabled. Others are optional because they aren’t always\nappropriate, or because they’re inconvenient for development. For example,\nforcing HTTPS may not be suitable for all websites, and it’s impractical for\nlocal development.
\nPerformance optimizations are another category of trade-offs with convenience.\nFor instance, caching is useful in production, less so for local development.\nError reporting needs are also widely different.
\nThe following checklist includes settings that:
\nmust be set properly for Django to provide the expected level of security;
are expected to be different in each environment;
habilitar funciones de seguridad opcionales;
habilitar optimizaciones de rendimiento;
provide error reporting.
Many of these settings are sensitive and should be treated as confidential. If\nyou’re releasing the source code for your project, a common practice is to\npublish suitable settings for development, and to use a private settings\nmodule for production.
\nmanage.py check --deployLink to this heading#Some of the checks described below can be automated using the check\n--deploy option. Be sure to run it against your production settings file as\ndescribed in the option’s documentation.
SECRET_KEYLink to this heading#The secret key must be a large random value and it must be kept secret.
\nAsegúrese de que la clave utilizada en producción no se use en ningún otro lugar y evite enviarla al control de código fuente. Esto reduce la cantidad de vectores desde los cuales un atacante puede adquirir la clave.
\nEn lugar de codificar la clave secreta en su módulo de configuración, considere cargarla desde una variable de entorno:
\nimport os\n\nSECRET_KEY = os.environ["SECRET_KEY"]\nor from a file:
\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 to this heading#You must never enable debug in production.
\nYou’re certainly developing your project with DEBUG = True,\nsince this enables handy features like full tracebacks in your browser.
For a production environment, though, this is a really bad idea, because it\nleaks lots of information about your project: excerpts of your source code,\nlocal variables, settings, libraries used, etc.
\nALLOWED_HOSTSLink to this heading#When DEBUG = False, Django doesn’t work at all without a\nsuitable value for ALLOWED_HOSTS.
This setting is required to protect your site against some CSRF attacks. If\nyou use a wildcard, you must perform your own validation of the Host HTTP\nheader, or otherwise ensure that you aren’t vulnerable to this category of\nattacks.
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 to this heading#If you’re using a cache, connection parameters may be different in development\nand in production. Django defaults to per-process local-memory caching which may not be desirable.
\nCache servers often have weak authentication. Make sure they only accept\nconnections from your application servers.
\nDATABASESLink to this heading#Database connection parameters are probably different in development and in\nproduction.
\nDatabase passwords are very sensitive. You should protect them exactly like\nSECRET_KEY.
For maximum security, make sure database servers only accept connections from\nyour application servers.
\nIf you haven’t set up backups for your database, do it right now!
\nSTATIC_ROOT and STATIC_URLLink to this heading#Static files are automatically served by the development server. In\nproduction, you must define a STATIC_ROOT directory where\ncollectstatic will copy them.
See How to manage static files (e.g. images, JavaScript, CSS) for more information.
\nMEDIA_ROOT and MEDIA_URLLink to this heading#Media files are uploaded by your users. They’re untrusted! Make sure your web\nserver never attempts to interpret them. For instance, if a user uploads a\n.php file, the web server shouldn’t execute it.
Now is a good time to check your backup strategy for these files.
\nAny website which allows users to log in should enforce site-wide HTTPS to\navoid transmitting access tokens in clear. In Django, access tokens include\nthe login/password, the session cookie, and password reset tokens. (You can’t\ndo much to protect password reset tokens if you’re sending them by email.)
\nProtecting sensitive areas such as the user account or the admin isn’t\nsufficient, because the same session cookie is used for HTTP and HTTPS. Your\nweb server must redirect all HTTP traffic to HTTPS, and only transmit HTTPS\nrequests to Django.
\nOnce you’ve set up HTTPS, enable the following settings.
\n\n\nSetting DEBUG = False disables several features that are\nonly useful in development. In addition, you can tune the following settings.
Consider using cached sessions to improve\nperformance.
\nIf using database-backed sessions, regularly clear old sessions to avoid storing unnecessary data.
\nCONN_MAX_AGELink to this heading#Enabling persistent database connections can result in a nice speed-up when\nconnecting to the database accounts for a significant part of the request\nprocessing time.
\nThis helps a lot on virtualized hosts with limited network performance.
\nTEMPLATESLink to this heading#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.
By the time you push your code to production, it’s hopefully robust, but you\ncan’t rule out unexpected errors. Thankfully, Django can capture errors and\nnotify you accordingly.
\nLOGGINGLink to this heading#Review your logging configuration before putting your website in production,\nand check that it works as expected as soon as you have received some traffic.
\nSee Logging for details on logging.
\nADMINS and MANAGERSLink to this heading#ADMINS will be notified of 500 errors by email.
MANAGERS will be notified of 404 errors.\nIGNORABLE_404_URLS can help filter out spurious reports.
See How to manage error reporting for details on error reporting by 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.