Django — фреймворк «с батарейками» и в вопросах безопасности: CSRF, экранирование XSS, параметры ORM, заголовок против clickjacking и хеширование паролей идут из коробки. Но в реальных проектах дыры чаще появляются в том, что пишете вы: боевые настройки, проверка прав, парольная политика и лимиты попыток. Этот урок — практический чек-лист по OWASP Top 10. Сами CSRF, XSS и SQL-инъекции разобраны в отдельном уроке.
⚠️ Чек-лист — не инструмент проверки, а напоминание: безопасность зависит не только от настроек, но и от ревью кода.
Встроенная защита
| Риск | Встроенная защита | Что её отключает |
|---|---|---|
| CSRF | CsrfViewMiddleware, {% csrf_token %} | @csrf_exempt |
| XSS | автоэкранирование в шаблонах | фильтр safe, mark_safe |
| SQL-инъекции | параметры ORM | raw()/extra() + f-строка |
| Clickjacking | X-Frame-Options: DENY | @xframe_options_exempt |
| Пароли | хеш + соль (PBKDF2) | хранение пароля в открытом виде |
| Сессия | cookie HttpOnly, SameSite=Lax | ослабление настроек |
Запрос проходит несколько слоёв, но то, какой пользователь имеет доступ к какому объекту, проверяете только вы, во view. И это самый частый риск в OWASP: Broken Access Control.
manage.py check --deploy и SECURE_*
check --deploy проверяет settings.py с точки зрения боевой среды. Каждая находка идёт с кодом security.Wxxx, а --fail-level WARNING превращает предупреждение в ошибку CI. Запускайте команду с боевыми настройками: при DEBUG = True результат обманчив.
python manage.py check --deploy
python manage.py check --deploy --fail-level WARNINGSystem check identified some issues:
WARNINGS:
?: (security.W004) SECURE_HSTS_SECONDS ...
?: (security.W008) SECURE_SSL_REDIRECT ...
?: (security.W012) SESSION_COOKIE_SECURE ...
?: (security.W016) CSRF_COOKIE_SECURE ...
?: (security.W018) You should not have DEBUG set to True in deployment.Типичное исправление:
import os