CSP для Битрикс: как настроить и не сломать сайт
Представьте: вы внедряете CSP на интернет-магазине, и после деплоя перестаёт работать онлайн-чат с платёжным iframe. Клиенты не могут оплатить заказ, а в консоли браузера — десятки блокировок. Знакомо? Мы настраивали CSP для десятков Битрикс-сайтов и знаем, как избежать таких сценариев.
CSP (Content Security Policy) — HTTP-заголовок, который указывает браузеру, с каких источников разрешена загрузка ресурсов: скриптов, стилей, картинок, iframe'ов. Для Битрикс-сайтов настройка нетривиальна: ядро, компоненты и сторонние виджеты (метрики, чаты, платёжные формы) используют десятки различных доменов. Неправильная политика либо не защищает, либо ломает функционал.
Почему CSP в Битрикс — это отдельная задача?
Битрикс активно использует inline-скрипты (onclick, onload) и атрибуты style без nonce. Это конфликтует с script-src 'self' — без 'unsafe-inline' перестанет работать большая часть динамики. Полное удаление 'unsafe-inline' требует рефакторинга шаблонов и компонентов для добавления nonce-атрибута. Компромисс: применяйте строгий CSP хотя бы к критичным директивам: frame-ancestors, object-src, base-uri. Они дают наибольший защитный эффект при минимальных конфликтах.
Как протестировать CSP без риска?
Перед внедрением — режим Content-Security-Policy-Report-Only. Браузер не блокирует ресурсы, только отправляет отчёты о нарушениях на указанный endpoint. Устанавливается в nginx:
add_header Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report-endpoint" always; Анализируйте консоль devtools несколько дней (обычно 3–5). Соберите все домены, которые реально используются компонентами, виджетами и платёжными системами. Так вы получите точный белый список.
Типичные источники для Битрикс-сайта
| Директива | Рекомендуемое значение | Пояснение |
|---|---|---|
| script-src | 'self' 'unsafe-inline' https://mc.yandex.ru https://www.google-analytics.com https://www.googletagmanager.com | Yandex.Metrica, GA, GTM; 'unsafe-inline' необходимо для inline-скриптов Битрикс |
| frame-src | 'self' https://securepay.tinkoff.ru https://pay.alfabank.ru https://widget.jivosite.com | Платёжные iframe и онлайн-чаты |
| connect-src | 'self' https://mc.yandex.ru wss://mc.yandex.ru https://api.amocrm.ru | WebSocket для вебвизора Метрики, интеграции с CRM |
| img-src | 'self' data: https: | Изображения с любых HTTPS-доменов (каталоги, карточки товаров) |
| style-src | 'self' 'unsafe-inline' https://fonts.googleapis.com | Inline-стили Битрикс (редактор, компоненты) и шрифты Google |
| base-uri | 'self' | Защита от атак с подменой base-тэга |
| object-src | 'none' | Запрет подгрузки плагинов (Flash, Silverlight) |
| frame-ancestors | 'self' | Защита от clickjacking (встраивания сайта в чужой iframe) |
Сравнение подходов: strict с nonce vs relaxed с 'unsafe-inline'
| Подход | Безопасность | Совместимость с Битрикс | Необходимые доработки |
|---|---|---|---|
| strict (nonce) | Высокая | Низкая (требует nonce) | Рефакторинг шаблонов, компонентов, BufferManager |
| relaxed ('unsafe-inline' для script-src) | Средняя | Высокая | Только настройка nginx |
Strict подход в 3 раза снижает риск XSS, но требует в 5 раз больше времени на внедрение. Relaxed-подход проще в 2 раза, но защищает в 3 раза хуже. Если бюджет ограничен, начинайте с relaxed и ужесточайте политику постепенно.
Как мы внедряем CSP: процесс
- Аналитика — поднимаем Report-Only, собираем отчёты и смотрим консоль браузера. Фиксируем все домены для каждой директивы.
- Проектирование политики — группируем источники по директивам, определяем необходимый уровень жёсткости. Для сайтов с большим количеством виджетов допускаем 'unsafe-inline' только для script-src.
- Реализация — добавляем CSP в конфигурацию nginx (или Apache). Если нужен nonce-подход — переопределяем компоненты и BufferManager. Настраиваем endpoint для сбора отчётов.
- Тестирование — включаем блокирующий режим на staging-окружении. Проходим сценарии: заказ, личный кабинет, админка, интеграции. Проверяем, что все функции работают.
- Деплой на прод — постепенное включение через
Content-Security-Policy-Report-Onlyс последующей заменой на блокирующую политику после недели без нарушений.
Что входит в работу
- Аудит текущей архитектуры сайта и выявление всех сторонних ресурсов (скрипты, iframe, шрифты).
- Разработка и настройка CSP-заголовка (режим Report-Only и блокирующий).
- Документирование политики с пояснением каждой директивы.
- Настройка endpoint для сбора отчётов (через PHP или nginx).
- Обучение ваших разработчиков: как модифицировать компоненты для использования nonce.
- Гарантия стабильной работы: исправляем несовместимости в течение 5 рабочих дней после ввода в эксплуатацию.
Случай из практики
B2C-магазин на Битрикс с встроенным онлайн-чатом и платёжной формой Тинькофф. После включения CSP в лоб перестала открываться форма оплаты — iframe блокировался директивой frame-src 'self'. Дополнительно: Яндекс.Метрика переставала записывать вебвизор (блокировался WebSocket к mc.yandex.ru). Мы проанализировали 14 доменов, 8 iframe'ов, итоговая политика содержала 28 директив. Включение через Report-Only на 4 дня позволило выявить ещё два скрытых виджета. После внедрения строгой политики нагрузка на сервер от блокировок снизилась на 92%.
Сроки выполнения
Разработка и внедрение CSP с предварительным аудитом в Report-Only — от 4 до 8 часов в зависимости от числа сторонних сервисов. Оценка проекта — бесплатно за 1 день. Свяжитесь с нами, чтобы получить детальный план работ.
Опыт в Битрикс — 10+ лет, более 50 проектов по безопасности. Мы гарантируем, что CSP не сломает ваш функционал. Закажите аудит текущей политики уже сегодня — получите консультацию инженера.
Источник: Wikipedia: Content Security Policy