Перейти к содержимому
>_ITDITDПлатформа веб-безопасности

По фреймворкам

#Django#framework#misconfiguration#access control

Безопасность Django — DEBUG, SECRET_KEY и авторизация

У Django безопасные значения по умолчанию, но инциденты приходят из настроек: DEBUG=True в проде (раскрытие настроек/секретов), утёкший SECRET_KEY и слабая авторизация. Поставьте DEBUG=False, загружайте SECRET_KEY из окружения, авторизуйте явно. Защитно, без шагов атаки.

Опубликовано 2026-07-02 Обновлено 2026-07-02 3 мин чтения

Для: всех, кто ведёт приложение на Django. Здесь нет шагов атаки — только как сохранить работу безопасных значений по умолчанию, закрывая пробелы, которые открывают настройки. Полную картину смотрите на хабе безопасности по фреймворкам.

Большая тройка ловушек (открываются в настройках)

Значения по умолчанию Django превосходны, но эти три вещи вам защищать в настройках и коде.

① DEBUG=True в проде

Страница ошибки раскрывает настройки, переменные окружения, секреты. Извлекается намеренными ошибками.

② Утёкший SECRET_KEY

Основа подписи/сессий/CSRF. Утечка грозит подделкой и подменой.

③ Слабая авторизация

Аутентифицирован, но нет проверок permission/владельца. Подмена ID раскрывает чужие данные.

Три дыры, самых частых в Django — все за пределами значений по умолчанию/настроек.

Также следите за SQLi через raw()/extra() или интерполяцию строк, небезопасной десериализацией (pickle), незаданным ALLOWED_HOSTS и незакрытыми CVE зависимостей (pip).

Как их закрыть (3 шага)

1

DEBUG=False + ALLOWED_HOSTS в проде

Убедитесь, что в проде DEBUG=False, и корректно задайте ALLOWED_HOSTS. Не давайте показывать подробные ошибки наружу и настройте отдачу static/media для прода. Встройте это в деплой и проверяйте каждый раз.
2

Загружайте SECRET_KEY из окружения, храните приватно

Не кладите SECRET_KEY в код/репозиторий — загружайте из переменной окружения или менеджера секретов. Держите его вне публичных каталогов и страниц DEBUG и оперативно ротируйте, если он утёк (→ держите секреты вне публичных каталогов).
3

Сделайте авторизацию явной и обрежьте опасные пути ввода

Не останавливайтесь на входе (аутентификации); делайте авторизацию по permission/владельцу явной. Используйте ORM/плейсхолдеры и избегайте интерполяции строк в raw(), а также не восстанавливайте недоверенные данные через pickle. Держите зависимости (pip) под мониторингом CVE + быстро закрытыми (→ что такое IDOR).

Частое (опасное)

  • в проде оставлен DEBUG=True
  • SECRET_KEY зашит в код/репозиторий
  • нет авторизации — «залогинен = можно смотреть»
  • интерполяция строк в raw() · pickle на недоверенных данных

Правильно

  • в проде DEBUG=False + ALLOWED_HOSTS
  • SECRET_KEY из окружения, хранится приватно
  • явная авторизация (область permission/владельца)
  • ORM/плейсхолдеры, без десериализации недоверенных данных

Взгляд этого сайта: батарейки в комплекте, но настройки и авторизация на вас

Django многое защищает по умолчанию, но настройки прода (DEBUG/SECRET_KEY/ALLOWED_HOSTS) и авторизацию вы должны выстроить верно под каждое окружение и приложение. Инциденты, которые мы видим снова и снова, — не изощрённые атаки, а паттерны настроек/эксплуатации: «отладка была открыта в проде», «секрет раскрылся», «не было авторизации». Поэтому центр тяжести — сузить настройки прода, держать секреты приватными и делать авторизацию явной. Не сломать надёжные значения по умолчанию — вот суть эксплуатации Django.

Читать дальше

FAQ

QDjango — безопасный фреймворк?
A

Django идёт «с батарейками» — защита SQL на основе ORM, защита от CSRF, авто-экранирование в шаблонах и система auth стандартны. При корректной настройке это надёжный фреймворк, но инциденты приходят не из ядра, а из настроек. DEBUG=True в проде, утёкший SECRET_KEY и слабая авторизация повторяются не столько как специфичные для Django проблемы, сколько как проблемы эксплуатации/настроек.

QЧем опасно оставить DEBUG=True в проде?
A

При включённом DEBUG страница ошибки может показать подробные внутренности — настройки, переменные окружения, трассировки стека. Атакующий может намеренно вызывать ошибки, чтобы их извлечь. В проде всегда ставьте DEBUG=False и корректно настраивайте ALLOWED_HOSTS. Также не давайте показывать подробные ошибки наружу и пересмотрите отдачу static/media для прода.

QПочему важен SECRET_KEY?
A

SECRET_KEY — ключ, на котором держатся подписанные cookie и сессии, CSRF-токены, сброс паролей и другое. Утечка может привести к подделке или подмене всего этого. Не кладите SECRET_KEY в код или репозиторий — загружайте из переменной окружения или менеджера секретов и оперативно ротируйте, если он утёк. А также не давайте ему раскрыться через публичный каталог или страницу DEBUG.