Безопасность форм в Django: что ломается под нагрузкой

Где безопасность форм встречается с нагрузкой

Django из коробки даёт три уровня защиты форм: CSRF-middleware, серверная валидация через классы форм и опциональный rate limiting (с Django 4.x — через сторонние пакеты, с кешем в качестве бэкенда). Каждый из них зависит от разделяемого ресурса — сессионного хранилища, кеша или базы данных. Под нагрузкой именно эти ресурсы становятся узким местом, и защита начинает вести себя не так, как задумано: CSRF-проверка отклоняет легитимные запросы, валидация не успевает отработать до таймаута, а rate limiter пропускает лишнее или блокирует всех подряд.

Материал написан для Django 4.2 LTS и Django 5.x. Поведение в более ранних версиях может отличаться — особенно в части хранения CSRF-токенов.

CSRF под нагрузкой: почему легитимные запросы получают 403

CSRF-middleware в Django работает по схеме «сравни токен из cookie с токеном из POST-тела (или заголовка)». Сам по себе алгоритм сравнения дешёвый. Проблема не в нём, а в сессионном бэкенде, который хранит маску для токена.

Сценарий: сессии в базе данных

По умолчанию Django хранит сессии в таблице django_session. Каждая проверка CSRF-токена при использовании сессионного бэкенда (django.contrib.sessions.backends.db) — это запрос к базе. При 300 одновременных отправках форм база получает 300 дополнительных SELECT-запросов только на чтение сессий. Если пул соединений исчерпан, middleware не может прочитать сессию, токен не совпадает, пользователь получает 403 Forbidden.

Характерный признак: в логах появляется Forbidden (CSRF cookie not set.) или Forbidden (CSRF token missing or incorrect.) — при том, что cookie в браузере есть и форма отправлена корректно.

Сценарий: сессии в кеше, кеш переполнен

Переход на django.contrib.sessions.backends.cache снимает давление с базы, но добавляет новый риск. Memcached и Redis с политикой вытеснения (eviction) могут удалить сессию до истечения её TTL. Пользователь отправляет форму, middleware лезет в кеш, сессии нет — 403. Под нагрузкой вытеснение происходит чаще, и процент ложных 403 растёт нелинейно.

Проблема не в том, что CSRF-защита слабая. Проблема в том, что она молча деградирует: вместо внятной ошибки «сессионное хранилище недоступно» пользователь видит «запрос отклонён», а разработчик — стандартный 403 без контекста.

Что мерить и на что смотреть

• Процент 403-ответов на эндпоинтах с формами — если он растёт вместе с RPS, дело не в атаке, а в хранилище.
• Количество eviction-событий в Memcached (stats → evictions) или Redis (INFO stats → evicted_keys).
• Время ответа сессионного бэкенда: добавьте логирование в кастомный session engine или используйте django-debug-toolbar в staging.
• Размер пула соединений к базе (если сессии в БД) — сравните CONN_MAX_AGE и фактическое число воркеров.

Валидация форм: чем дороже clean(), тем хуже масштабирование

Серверная валидация через метод clean() и clean_<field>() выполняется синхронно в том же потоке, что обрабатывает запрос. Если внутри валидации есть обращение к базе — проверка уникальности, запрос к связанной модели, — каждая отправка формы занимает поток на время запроса к БД.

Пример: проверка уникальности email при регистрации

Типичный clean_email() делает User.objects.filter(email=value).exists(). При 200 одновременных регистрациях это 200 запросов к таблице пользователей. Если индекс на email есть — терпимо. Если нет (а в стандартной модели auth_user индекс на email не создаётся автоматически) — sequential scan на таблице в миллион строк, и воркеры начинают копиться.

Ситуация усугубляется, если валидация вызывает внешний сервис: проверку капчи, антифрод-API, геолокацию. Таймаут внешнего сервиса в 2 секунды при 100 RPS означает 200 занятых потоков — это больше, чем типичный Gunicorn-пул.

Границы и что ломается

Отдельная ловушка — ModelForm с unique=True на поле модели. Django автоматически добавляет проверку уникальности в validate_unique(), и разработчик может даже не знать, что при каждом сабмите формы выполняется запрос к базе. Под нагрузкой это становится сюрпризом.

Rate limiting: защита, которая мешает себе

Django не включает встроенный rate limiter для форм. Обычно используют django-ratelimit или аналоги, опирающиеся на кеш-бэкенд. Здесь возникает парадокс: механизм, призванный снизить нагрузку, сам создаёт нагрузку на кеш.

Гонка при инкременте счётчика

Типичная реализация: прочитать текущее значение ключа, увеличить, записать обратно. Если операция не атомарная (а в Memcached атомарный инкремент есть, но не все обёртки его используют), при 300 одновременных запросах часть инкрементов теряется. Результат — rate limiter пропускает больше запросов, чем настроен.

С Redis ситуация лучше: команда INCR атомарна. Но если приложение ходит в Redis через тот же пул, что и сессии, — одно замедление бьёт по всему.

Проверьте, какой бэкенд использует ваш rate limiter и как именно он инкрементирует счётчик. Документация конкретного пакета — единственный надёжный источник: поведение различается между версиями.

Как диагностировать до продакшена

1. Нагрузочный тест именно на формы. Не на главную страницу и не на API — на POST-эндпоинты с CSRF, с cookie, с телом запроса. Инструменты: Locust, k6, wrk. Тест без валидного CSRF-токена бесполезен: вы меряете скорость отказа, а не работу.
2. Мониторинг 403 с разбивкой по причине. Стандартный CsrfViewMiddleware пишет причину в request.META['CSRF_FAILURE_REASON'] (Django 4.x+). Логируйте её — это отличит атаку от деградации хранилища.
3. Отдельный мониторинг сессионного бэкенда. Время ответа кеша или базы на операции чтения/записи сессий — отдельная метрика, не смешанная с остальными запросами.
4. Профилирование clean()-методов. django-silk или cProfile покажут, сколько времени занимает валидация каждого поля. Ищите запросы к базе и внешние вызовы.
5. Тест на вытеснение сессий. Заполните кеш до предела и отправьте формы — увидите реальный процент ложных 403.

Снижение рисков: что реально помогает

Для CSRF

• Используйте cookie-based CSRF-токены (CSRF_USE_SESSIONS = False, значение по умолчанию). В этом режиме токен хранится в cookie, а не в сессии, и проверка не зависит от сессионного бэкенда вообще. Это самое дешёвое изменение с самым большим эффектом.
• Если сессии нужны для CSRF (например, из-за политики безопасности), переведите сессии на Redis с отдельным пулом соединений и без политики вытеснения (настройка maxmemory-policy noeviction). При переполнении Redis вернёт ошибку записи — и вы узнаете о проблеме, а не потеряете сессии молча.

Для валидации

• Индексы на всех полях, по которым валидация делает запросы. Звучит очевидно, но auth_user.email — классический пример пропущенного индекса.
• Внешние вызовы — в фоновую задачу. Проверку капчи можно выполнить после принятия формы, отложив окончательное подтверждение. Валидация формы при этом проходит мгновенно, а результат проверки приходит через Celery или аналог.
• Таймауты на все внешние вызовы внутри clean(). Без явного таймаута requests.post() может висеть минутами, блокируя воркер.

Для rate limiting

• Атомарные операции: убедитесь, что ваш пакет использует INCR Redis, а не read-modify-write.
• Отдельный кеш-бэкенд для rate limiter. Django позволяет настроить несколько кешей в CACHES — не разделяйте хранилище с сессиями.

Сноска. Eviction (вытеснение) — удаление записей из кеша при достижении лимита памяти. Политика вытеснения определяет, какие записи удаляются первыми: давно не использованные (LRU), случайные, с ближайшим TTL и так далее. В контексте сессий вытеснение означает потерю пользовательских данных без предупреждения.

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

Начните с простого: проверьте значение CSRF_USE_SESSIONS в вашем проекте. Если оно True и у вас нет на это веской причины — переключите на False. Затем добавьте в нагрузочные тесты POST-запросы с валидными CSRF-токенами и отслеживайте процент 403-ответов при росте RPS. Это даст картину того, насколько ваши формы устойчивы — до того, как это проверят пользователи или злоумышленники.

Тема инвалидации и ротации CSRF-токенов при масштабировании на несколько серверов — отдельный разбор, здесь мы её не затрагиваем.