Описание проблемы: invalid csrf token в Битрикс
Ошибка «Error: invalid csrf token» в Битрикс и Bitrix24 проявляется неожиданно: пользователь работает в системе, и вдруг сессия обрывается, появляется ошибка валидации CSRF-токена, и система требует повторной авторизации. Это особенно неприятно, когда пользователь заполнял форму или работал в CRM.
CSRF-токен в Битрикс привязан к сессии пользователя. Если сессия «теряется» или токен, сформированный при загрузке страницы, не совпадает с токеном при отправке запроса — система расценивает это как потенциальную атаку и сбрасывает авторизацию. Разберём основные причины этого поведения.
Причина 1: Дублирование куки PHPSESSID на поддоменах
Одна из наиболее частых причин — дублирование кук PHPSESSID. Это происходит, когда у вас есть несколько доменов или поддоменов: например, site.ru и crm.site.ru, работающих на разных установках Битрикс, или когда многосайтовость реализована на подпапках.
В такой конфигурации браузер может получать два cookie с именем PHPSESSID — один с доменом site.ru, другой с доменом .site.ru (с точкой, то есть применяемый ко всем поддоменам). При следующем запросе браузер отправляет оба cookie, и PHP «путается» — принимает не ту сессию, токен не совпадает, авторизация сбрасывается.
Проверьте ситуацию: откройте DevTools браузера (F12), вкладку Application → Cookies и посмотрите, нет ли дублирующихся записей PHPSESSID с разными значениями доменов.
Решение — если на каждой установке Битрикс работает только один сайт или многосайтовость реализована только на подпапках, удалите доменное имя из настроек сайта в поле «Доменное имя». Подробнее в документации Битрикс:
Причина 2: Проблемы с балансировщиком нагрузки
Если ваш Битрикс работает за балансировщиком нагрузки (Load Balancer) или в кластерной конфигурации с несколькими серверами, сессии пользователя могут «гулять» между серверами. Страница загрузилась на сервере A (создалась сессия с токеном), а POST-запрос с формой ушёл на сервер B, где этой сессии нет — токен не совпадает.
Симптом: ошибка CSRF возникает непредсказуемо, не у всех пользователей, и воспроизвести её сложно.
Решение: настройте sticky sessions (прилипчивые сессии) на балансировщике, чтобы все запросы от одного пользователя шли на один и тот же backend-сервер. Либо вынесите хранение сессий в общее хранилище (Redis, база данных) — см. раздел ниже.
Причина 3: Кеширование nginx/apache сессионных данных
В некоторых конфигурациях nginx настроен агрессивно кешировать ответы, включая страницы, содержащие CSRF-токены. В результате браузер получает страницу с устаревшим токеном из кеша, отправляет его на сервер, где текущий токен уже другой — ошибка.
Проверьте конфигурацию nginx на наличие кеширования динамических страниц. Для страниц с авторизацией кеширование должно быть отключено:
fastcgi_cache_bypass $cookie_PHPSESSID; fastcgi_no_cache $cookie_PHPSESSID;
Эти директивы указывают nginx не использовать кеш и не сохранять ответ в кеш, если в запросе присутствует cookie PHPSESSID (то есть для авторизованных пользователей).
Решение 1: Удалить доменное имя из настроек сайта
Самое простое решение при одиночном сайте — убрать явное указание домена в настройках, чтобы Битрикс не устанавливал cookie с доменным атрибутом. Это предотвращает распространение куки на поддомены.
Путь: Настройки → Настройки продукта → Сайты → [ваш сайт] → поле «Доменное имя» — очистить или оставить только основной домен без поддоменов.
Решение 2: Настроить cookie domain явно
Если многосайтовость нужна, явно задайте домен для куки в файле конфигурации Битрикс. В файле /bitrix/.settings.php или через административную панель в настройках сессий укажите точный домен (без точки в начале), чтобы cookie не распространялся на поддомены:
// В /bitrix/.settings.php
'session' => array(
'value' => array(
'mode' => 'default',
'handlers' => array(
'general' => array(
'type' => 'file',
),
),
),
),
Для управления доменом cookie используйте параметр session.cookie_domain в php.ini или через ini_set() до старта сессии:
ini_set('session.cookie_domain', 'site.ru'); // Без точки — только для этого домена
Решение 3: Перенести сессии в базу данных
Для кластерных конфигураций и случаев, когда сессии нестабильны в файловой системе, Битрикс поддерживает хранение сессий в базе данных. Это решает проблему «гуляющих» сессий между серверами.
Настройка производится в файле /bitrix/.settings.php:
'session' => array(
'value' => array(
'mode' => 'separated',
'handlers' => array(
'kernel' => array(
'type' => 'database',
),
'general' => array(
'type' => 'file',
),
),
),
),
В режиме separated критичные данные сессии (авторизация, CSRF-токен) хранятся в БД, а некритичные — в файловой системе. Это даёт баланс между надёжностью и производительностью.
Как воспроизвести и диагностировать проблему
- Откройте браузер в режиме инкогнито, войдите в систему.
- Откройте DevTools (F12) → вкладка Network, включите запись запросов.
- Выполните действие, которое вызывает ошибку CSRF.
- Найдите запрос, вернувший ошибку, и проверьте заголовки — особенно значения cookie в запросе и ответе.
- Если в запросе видны два разных значения
PHPSESSID— причина в дублировании кук. - Проверьте логи Битрикс:
/bitrix/modules/main/exception.phpи логи PHP-ошибок на сервере — там могут быть дополнительные подсказки.
