Список проверок при развертывании

SECRET_KEY

Ключ секретности должен быть большим случайным значением и должен храниться в секрете.

Убедитесь, что ключ, используемый в продакшене, не используется нигде в другом месте, и избегайте его добавления в контроль версий. Это уменьшает количество векторов, с помощью которых злоумышленник может получить ключ.

Вместо того, чтобы жестко закодировать ключ секретности в модуле настроек, рассмотрите возможность его загрузки из переменной окружения:

import os

SECRET_KEY = os.environ["SECRET_KEY"]

или из файла:

with open("/etc/secret_key.txt") as f:
    SECRET_KEY = f.read().strip()

При вращении ключей секретности вы можете использовать SECRET_KEY_FALLBACKS:

import os

SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
SECRET_KEY_FALLBACKS = [
    os.environ["OLD_SECRET_KEY"],
]

Убедитесь, что старые ключи секретности своевременно удаляются из SECRET_KEY_FALLBACKS.

DEBUG

В продакшене режим отладки должен быть отключен.

Вы, безусловно, разрабатываете проект с включенным DEBUG = True, так как это включает полезные функции, такие как полные трассировки в вашем браузере.

Однако в среде продакшена это очень плохая идея, потому что она раскрывает много информации о вашем проекте: фрагменты исходного кода, локальные переменные, настройки, используемые библиотеки и т.д.

ALLOWED_HOSTS

Когда DEBUG = False, Django вообще не работает без подходящего значения для ALLOWED_HOSTS.

Эта настройка требуется для защиты сайта от некоторых атак CSRF. Если вы используете подстановку, вы должны выполнить собственную проверку заголовка Host HTTP или каким-либо другим способом убедиться, что ваш сайт не уязвим для этого типа атак.

Также следует настроить веб-сервер, расположенный перед Django, для проверки хоста. Он должен отвечать статической страницей ошибки или игнорировать запросы на неправильные хосты, вместо того, чтобы пересылать запрос в Django. Таким образом, вы избежите ложных ошибок в ваших логах Django (или электронных письмах, если у вас настроена система оповещения об ошибках).

Например, в nginx вы можете настроить сервер по умолчанию для возврата «444 Нет ответа» при обнаружении неизвестного хоста:

server {
    listen 80 default_server;
    return 444;
}

CACHES

Если вы используете кэш, параметры подключения могут отличаться в разработке и в продакшене. Django по умолчанию использует кэширование в локальной памяти на уровне процесса, что может быть нежелательным.

Серверы кэширования часто имеют слабую аутентификацию. Убедитесь, что они принимают соединения только от ваших приложений.

DATABASES

Параметры подключения к базе данных, скорее всего, отличаются в разработке и в продакшене.

Пароли баз данных являются очень конфиденциальными. Вы должны защищать их так же, как и SECRET_KEY.

Для максимальной безопасности убедитесь, что серверы баз данных принимают соединения только от ваших приложений.

Если вы еще не настроили резервные копии для базы данных, сделайте это прямо сейчас!

EMAIL_BACKEND и связанные настройки

Если ваш сайт отправляет электронные письма, эти значения должны быть настроены правильно.

По умолчанию Django отправляет электронные письма с адресов webmaster@localhost и root@localhost. Однако некоторые провайдеры электронной почты отклоняют электронные письма с этих адресов. Чтобы использовать другие адреса отправителя, измените настройки DEFAULT_FROM_EMAIL и SERVER_EMAIL.

STATIC_ROOT и STATIC_URL

Статические файлы автоматически обслуживаются сервером разработки. В продакшене вы должны определить директорию STATIC_ROOT, куда collectstatic скопирует их.

См. Инструкцию по управлению статическими файлами (например, изображениями, JavaScript, CSS) для получения дополнительной информации.

MEDIA_ROOT и MEDIA_URL

Файлы медиа загружаются пользователями. Они ненадёжны! Убедитесь, что ваш веб-сервер никогда не пытается интерпретировать их. Например, если пользователь загружает .php файл, веб-сервер не должен его выполнять.

Сейчас самое время проверить вашу стратегию резервного копирования этих файлов.

CSRF_COOKIE_SECURE

Установите это значение в True, чтобы случайно не передать cookie CSRF по HTTP.

SESSION_COOKIE_SECURE

Установите это значение в True, чтобы случайно не передать cookie сессии по HTTP.

Сессии

Для повышения производительности рассмотрите использование кэшированных сессий.

При использовании сессий, поддерживаемых базой данных, регулярно очищайте старые сессии, чтобы избежать хранения ненужных данных.

CONN_MAX_AGE

Включение постоянных подключений к базе данных может заметно ускорить работу, если подключение к базе данных занимает значительную часть времени обработки запроса.

Это особенно полезно на виртуализированных хостах с ограниченной производительностью сети.

TEMPLATES

Включение кэшированного загрузчика шаблонов часто значительно улучшает производительность, так как позволяет избежать компиляции каждого шаблона каждый раз при его рендеринге. При значении DEBUG = False, кэшированный загрузчик шаблонов автоматически включен. Подробнее см. django.template.loaders.cached.Loader.

LOGGING

Перед запуском вашего сайта в производство проверьте конфигурацию логирования и убедитесь, что она работает должным образом после получения некоторого трафика.

Подробности о логировании см. в разделе Логирование.

ADMINS и MANAGERS

ADMINS будут получать уведомления о 500 ошибках по электронной почте.

MANAGERS будут получать уведомления о 404 ошибках. IGNORABLE_404_URLS может помочь отфильтровать ложные сообщения.

Подробные инструкции о отчёте об ошибках по электронной почте см. в разделе Как управлять отчётом об ошибках.

Настройка стандартных представлений об ошибках

Django включает стандартные представления и шаблоны для нескольких кодов HTTP-ошибок. Возможно, вам захочется переопределить стандартные шаблоны, создав следующие шаблоны в корневой папке шаблонов: 404.html, 500.html, 403.html и 400.html. Стандартные представления об ошибках представления об ошибках по умолчанию, которые используют эти шаблоны, подойдут для 99% веб-приложений, но вы также можете настроить их.