По фреймворкам
Безопасность Django — справочник по продакшн-хардингу
Справочник по продакшн-хардингу Django: приоритетный чек-лист плюс DEBUG/ALLOWED_HOSTS, SECRET_KEY, CVE pip, продакшн-настройки безопасности, авторизация, инъекции и SSRF. Защитно, без шагов атаки.
Для: всех, кто ведёт приложение на Django. Здесь нет шагов атаки — это рабочий справочник по хардингу: приоритетный чек-лист, руководство по областям и самопроверка. Полную картину по фреймворкам смотрите на хабе безопасности по фреймворкам.
Приоритетный чек-лист хардинга
Проходите эту таблицу сверху вниз. P0 — предпосылка, P1 — самый частый источник инцидентов, P2 — постоянная эксплуатационная гигиена.
P0 ── Предпосылка (сначала это)
DEBUG=False + ALLOWED_HOSTS / вынос SECRET_KEY наружу / быстрое закрытие CVE зависимостей pip
P1 ── Главный источник инцидентов
Продакшн-настройки безопасности (SSL/HSTS/cookie) / авторизация (область владельца)
P2 ── Эксплуатационная гигиена
Инъекции и вывод / CSRF, сессии, admin / SSRF, загрузки
| Приоритет | Мера | Конкретика (Django) |
|---|---|---|
| P0 | DEBUG/ALLOWED_HOSTS | В продакшене DEBUG=False + задан ALLOWED_HOSTS. Не раскрывайте детальные ошибки |
| P0 | SECRET_KEY | Из окружения, не в коде/репозитории. Ротация при утечке |
| P0 | CVE зависимостей pip | Мониторьте через pip-audit / osv-scanner; судите по запущенной версии, быстро закрывайте |
| P1 | Продакшн-настройки безопасности | SECURE_SSL_REDIRECT, SECURE_HSTS_SECONDS, SESSION_COOKIE_SECURE, CSRF_COOKIE_SECURE, SECURE_CONTENT_TYPE_NOSNIFF |
| P1 | Явная авторизация | Требуется вход + разрешения + filter(user=request.user) для области владельца |
| P2 | Инъекции/вывод | Привязывайте через ORM. Избегайте интерполяции в raw()/extra(). Не передавайте ввод в mark_safe/` |
| P2 | CSRF/сессии/admin | Не отключайте CSRF (по умолчанию). Ограничьте доступность admin |
| P2 | SSRF/загрузки | Список разрешённых для серверных запросов + блокировка внутренних IP. Проверяйте загрузки, храните вне публичной зоны |
1. DEBUG и ALLOWED_HOSTS (P0)
- Обеспечьте
DEBUG=Falseв продакшене. При включении страница ошибки раскрывает настройки, переменные окружения и трассировки стека, извлекаемые намеренными ошибками. - Правильно задайте
ALLOWED_HOSTS, чтобы предотвратить работу под неожиданными хостами. Прекратите показ детальных ошибок вовне.
2. SECRET_KEY (P0)
SECRET_KEYлежит в основе подписанных cookie, сессий, токенов CSRF и сброса паролей. Загружайте его из переменной окружения или менеджера секретов, не из кода/репозитория.- Оперативно ротируйте при утечке. Держите его вне публичных каталогов и страниц DEBUG (→ не держите секреты в публичных каталогах).
3. CVE зависимостей pip (P0)
- Машинно мониторьте известные CVE через pip-audit или osv-scanner, судите по запущенной версии и быстро закрывайте (→ мониторинг CVE зависимостей · плейбук реагирования на уязвимости).
- Держите Django и Python на поддерживаемых версиях и не оставляйте EOL-версии.
4. Продакшн-настройки безопасности (P1)
Django настраивает большую часть своей защиты через SecurityMiddleware. Задайте это под продакшн:
SECURE_SSL_REDIRECT(принудительный HTTPS) ·SECURE_HSTS_SECONDS(+INCLUDE_SUBDOMAINS/PRELOAD)SESSION_COOKIE_SECURE/CSRF_COOKIE_SECURE(cookie только по HTTPS)SECURE_CONTENT_TYPE_NOSNIFFи др.- Запустите
manage.py check --deploy, чтобы механически выявить пробелы в них.
5. Авторизация (P1 — главный источник)
Частое (опасное)
- вход требуется, но нет области владельца
- querysets по всему, без фильтрации по ID
- опора на скрытые URL / труднопредсказуемые ID
- забыта проверка разрешений в некоторых представлениях
Правильно
- вход требуется + явные проверки разрешений
- чтения тоже ограничены владельцем (например,
filter(user=request.user)) - проверено на каждом пути чтения/обновления/удаления
- авторизация построена явно, а не оставлена на значения по умолчанию
Смотрите что такое IDOR. Аутентификация и авторизация различны; авторизуйте близко к данным.
6. Инъекции и вывод (P2)
- SQL: привязывайте через ORM. Не стройте запросы через
raw()/extra()или интерполяцию строк (→ что такое SQL-инъекция). - XSS: шаблоны экранируют автоматически по умолчанию. Не передавайте пользовательский ввод в
mark_safe/|safe(→ что такое XSS). - Десериализация: не загружайте недоверенный
pickle(может привести к выполнению кода).
7. CSRF, сессии, admin (P2)
- Не отключайте защиту от CSRF (по умолчанию) (→ что такое CSRF).
- Ограничьте доступность admin (ограничения доступа, смена URL, многофакторная аутентификация). Сохраните защиту от кликджекинга (
X-Frame-Optionsпо умолчанию). - Применяйте secure/httponly/samesite к сессиям и регенерируйте при входе.
8. SSRF, загрузки, заголовки (P2)
- Серверная выборка URL, заданных пользователем, должна ограничивать цели списком разрешённого и блокировать доступ к внутренним IP/метаданным (→ что такое SSRF).
- Проверяйте загрузки (тип/размер) и храните их вне публичной зоны.
- Проверьте заголовки своего сайта через проверку заголовков безопасности.
Проверьте: действительно ли ваш Django укреплён?
Собрать — ещё не конец: работа сделана только после проверки. Это защитные самопроверки против собственной среды.
Механически проверьте пробелы
python manage.py check --deploy и убедитесь, что предупреждения устранены.Продакшн не раскрывает DEBUG
Авторизация держится
Секреты и зависимости
SECRET_KEY нет в репозитории и что pip-audit/osv чист.Взгляд нашего сайта: батарейки в комплекте, но настройки и авторизация на вас
Django защищает многое по умолчанию, но продакшн-настройки (DEBUG/SECRET_KEY/ALLOWED_HOSTS/SSL) и авторизацию вы должны выставить правильно для каждой среды и каждого приложения. Инциденты, которые мы видим снова и снова, — не изощрённые атаки, а паттерны настроек/эксплуатации: «в продакшене был открыт debug», «раскрылся секрет», «не было авторизации». Поэтому центр тяжести — затянуть продакшн-настройки, держать секреты приватными и сделать авторизацию явной. Встроить check --deploy в свой процесс — короткий путь.
Читать дальше
- Хаб: безопасность по фреймворкам · безопасность Laravel (похожая продакшн-DEBUG / утечка секретов)
- Практика: плейбук реагирования на уязвимости · мониторинг CVE зависимостей · не держите секреты в публичных каталогах
- Глоссарий: что такое IDOR · SQL-инъекция · XSS · CSRF · SSRF
- Инструменты: проверка заголовков безопасности
FAQ
QЧто сделать в первую очередь для защиты Django?
Три пункта P0: (1) обеспечьте DEBUG=False в продакшене и правильно задайте ALLOWED_HOSTS; (2) загружайте SECRET_KEY из окружения (не в коде/репозитории) и ротируйте при утечке; (3) машинно мониторьте CVE зависимостей pip и быстро закрывайте, судя по запущенной версии. Дальше переходите к продакшн-настройкам безопасности (SSL/HSTS/cookie) и авторизации. manage.py check --deploy механически выявляет отсутствующие настройки.
QЧем опасно оставить DEBUG=True в продакшене?
При включённом DEBUG страница ошибки может показать детальные внутренности — настройки, переменные окружения, трассировки стека. Атакующий может намеренно вызывать ошибки, чтобы их извлечь. В продакшене всегда ставьте DEBUG=False и правильно настраивайте ALLOWED_HOSTS. Также прекратите показ детальных ошибок вовне и пересмотрите раздачу static/media для продакшена.
QПочему SECRET_KEY важен?
SECRET_KEY лежит в основе подписанных cookie и сессий, токенов CSRF и сброса паролей. Утечка может привести к подделке или подмене этого. Не помещайте его в код или репозиторий — загружайте из переменной окружения или менеджера секретов и оперативно ротируйте при утечке. Также не давайте ему раскрыться через публичный каталог или страницу DEBUG.
QКакие продакшн-настройки безопасности Django проверять?
Связанные с SecurityMiddleware: SECURE_SSL_REDIRECT (принудительный HTTPS), SECURE_HSTS_SECONDS (HSTS), SESSION_COOKIE_SECURE / CSRF_COOKIE_SECURE (secure-cookie), SECURE_CONTENT_TYPE_NOSNIFF и другие, настроенные под продакшн. Запуск manage.py check --deploy механически выявляет пробелы в них.
QКак управлять уязвимостями зависимостей pip?
Машинно мониторьте известные CVE через pip-audit или osv-scanner и быстро закрывайте, судя по запущенной версии. Держите Django и Python на поддерживаемых версиях и не оставляйте EOL-версии. Свежесть зависимостей — более реалистичный фактор инцидентов, чем изощрённые атаки.