The Internet is a hostile environment. Before deploying your Django project,
you should take some time to review your settings, with security, performance,
and operations in mind.

Django includes many security features. Some are
built-in and always enabled. Others are optional because they aren’t always
appropriate, or because they’re inconvenient for development. For example,
forcing HTTPS may not be suitable for all websites, and it’s impractical for
local development.

Performance optimizations are another category of trade-offs with convenience.
For instance, caching is useful in production, less so for local development.
Error reporting needs are also widely different.

The following checklist includes settings that:

must be set properly for Django to provide the expected level of security;

are expected to be different in each environment;

enable optional security features;

enable performance optimizations;

provide error reporting.

Many of these settings are sensitive and should be treated as confidential. If
you’re releasing the source code for your project, a common practice is to
publish suitable settings for development, and to use a private settings
module for production.

This setting is required to protect your site against some CSRF attacks. If
you use a wildcard, you must perform your own validation of the Host HTTP
header, or otherwise ensure that you aren’t vulnerable to this category of
attacks.

You should also configure the Web server that sits in front of Django to
validate the host. It should respond with a static error page or ignore
requests for incorrect hosts instead of forwarding the request to Django. This
way you’ll avoid spurious errors in your Django logs (or emails if you have
error reporting configured that way). For example, on nginx you might setup a
default server to return “444 No Response” on an unrecognized host:

Any website which allows users to log in should enforce site-wide HTTPS to
avoid transmitting access tokens in clear. In Django, access tokens include
the login/password, the session cookie, and password reset tokens. (You can’t
do much to protect password reset tokens if you’re sending them by email.)

Protecting sensitive areas such as the user account or the admin isn’t
sufficient, because the same session cookie is used for HTTP and HTTPS. Your
web server must redirect all HTTP traffic to HTTPS, and only transmit HTTPS
requests to Django.

Django includes default views and templates for several HTTP error codes. You
may want to override the default templates by creating the following templates
in your root template directory: 404.html, 500.html, 403.html, and
400.html. The default error views that use these
templates should suffice for 99% of Web applications, but you can
customize them as well.