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