Вы обновили сайт, добавили новый виджет или подключили сторонний сервис — и часть скриптов перестала работать. В консоли браузера появились ошибки CSP. Content Security Policy блокирует то, что не разрешено явно. После обновления в политике могут появиться новые источники, которых нет в правилах. Разберём, как найти причину и настроить CSP так, чтобы ничего не ломалось.
Что такое CSP и почему он блокирует
CSP (Content Security Policy) — это HTTP-заголовок, который указывает браузеру, какие ресурсы разрешено загружать на странице. Он защищает от XSS-атак и других угроз, но при неправильной настройке может блокировать легитимные скрипты, стили, изображения и шрифты.
CSP задаётся через заголовок Content-Security-Policy или через meta-тег. Пример:
Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com
Здесь default-src 'self' означает, что по умолчанию разрешены только ресурсы с того же домена. script-src добавляет https://example.com как разрешённый источник для скриптов. Всё, что не указано, блокируется.
Если после обновления появился новый источник скриптов, которого нет в script-src, он будет заблокирован. Именно поэтому CSP часто ломает сайт после обновлений.
Причина 1: новый источник не добавлен в политику
Самая частая причина. После обновления или добавления виджета появляется новый домен, с которого загружаются скрипты. Если его нет в script-src, браузер блокирует загрузку.
Что проверить:
— откройте консоль браузера;
— найдите ошибки CSP;
— посмотрите, какой источник блокируется;
— проверьте, есть ли он в script-src;
— добавьте его в политику, если он легитимный.
Для проверки текущей политики используйте проверка CSP — инструмент покажет, какие директивы заданы и какие источники разрешены.
Причина 2: inline-скрипты без nonce или hash
Если политика запрещает inline-скрипты (без 'unsafe-inline'), то все скрипты внутри HTML будут заблокированы. Это касается и скриптов, добавленных CMS, плагинами или аналитикой.
Что делать:
— использовать nonce: уникальный токен для каждого запроса;
— использовать hash: хеш содержимого скрипта;
— вынести inline-скрипты во внешние файлы;
— проверить, какие inline-скрипты есть на странице.
Nonce и hash — более безопасные способы, чем 'unsafe-inline'. Но они требуют настройки на стороне сервера и CMS.
Причина 3: конфликт с CDN или прокси
Если сайт работает через CDN или прокси, заголовок CSP может добавляться или изменяться на уровне CDN. Иногда CDN добавляет собственный CSP, который конфликтует с вашим.
Что проверить:
— какой CSP отдаётся браузеру;
— не добавляет ли CDN свой CSP;
— не изменяет ли CDN ваш CSP;
— не дублируется ли заголовок.
Иногда на странице два заголовка CSP, и браузер применяет более строгий. Это может блокировать ресурсы, которые вы разрешили.
Причина 4: обновление CMS или плагина
После обновления CMS или плагина может измениться способ подключения скриптов. Например, плагин начал использовать inline-скрипты или подключать ресурсы с нового домена.
Что проверить:
— какие скрипты блокируются;
— какие плагины их добавляют;
— изменился ли способ подключения;
— есть ли у плагина настройки для CSP.
Иногда проблему можно решить настройками плагина, иногда — добавлением источника в CSP.
Причина 5: отчёты CSP не настроены
Если вы не настроили report-uri или report-to, вы не видите, какие ресурсы блокируются. Ошибки видны только в консоли браузера, и их легко пропустить.
Что сделать:
— настроить report-uri для сбора отчётов;
— использовать режим Content-Security-Policy-Report-Only для тестирования;
— анализировать отчёты и добавлять легитимные источники;
— не переходить в боевой режим, пока отчёты не покажут, что всё в порядке.
Как найти причину
Пошаговая диагностика:
— откройте консоль браузера;
— найдите ошибки CSP;
— определите, какой ресурс блокируется;
— проверьте, есть ли его источник в CSP;
— проверьте, не блокируется ли inline-скрипт;
— проверьте, не добавляет ли CSP CDN;
— проверьте отчёты CSP, если они настроены.
Если нужно проверить политику целиком, используйте проверку CSP. Она покажет текущие директивы и поможет найти проблему.
Как исправить
План действий:
— добавить легитимные источники в script-src;
— настроить nonce или hash для inline-скриптов;
— вынести inline-скрипты во внешние файлы;
— проверить, не добавляет ли CDN свой CSP;
— настроить отчёты CSP;
— протестировать в режиме Report-Only;
— перейти в боевой режим после проверки.
Как проверить результат
Чек-лист:
— в консоли нет ошибок CSP;
— все скрипты загружаются;
— inline-скрипты работают через nonce или hash;
— отчёты CSP не показывают блокировок;
— CSP не конфликтует с CDN;
— сайт работает корректно.
Если нужно проверить сразу несколько параметров — CSP, HSTS, SSL — логично перейти к SEO-аудиту.
Частые ошибки
— отсутствие нового источника в script-src;
— использование 'unsafe-inline' без необходимости;
— отсутствие nonce или hash для inline-скриптов;
— конфликт CSP с CDN;
— отсутствие отчётов CSP;
— переход в боевой режим без тестирования.
FAQ
Почему CSP блокирует скрипты после обновления?
Скорее всего, появился новый источник скриптов, которого нет в script-src. Проверьте консоль браузера и добавьте источник в политику.
Что такое nonce и зачем он нужен?
Nonce — это уникальный токен, который добавляется к inline-скриптам и разрешает их выполнение. Он безопаснее, чем 'unsafe-inline'.
Что такое hash в CSP?
Hash — это хеш содержимого скрипта. Если скрипт совпадает с хешем, он разрешён. Это удобно для статических inline-скриптов.
Может ли CDN добавлять свой CSP?
Да. Некоторые CDN добавляют собственный CSP, который может конфликтовать с вашим. Проверьте, какие заголовки отдаются браузеру.
Что делать, если CSP блокирует аналитику?
Добавьте домены аналитики в script-src и connect-src. Если аналитика использует inline-скрипты, настройте nonce или hash.
Как протестировать CSP без риска?
Используйте Content-Security-Policy-Report-Only. В этом режиме CSP не блокирует ресурсы, а только отправляет отчёты.
Влияет ли CSP на SEO?
Косвенно. Если CSP блокирует важные ресурсы, страница может работать некорректно, что ухудшает пользовательский опыт и может влиять на ранжирование.
Что делать, если CSP блокирует стили?
Проверьте директиву style-src. Добавьте источники стилей или используйте nonce/hash для inline-стилей.
Нужно ли использовать 'unsafe-inline'?
Не рекомендуется. 'unsafe-inline' снижает защиту CSP. Лучше использовать nonce или hash для inline-скриптов и стилей.
Как проверить, что CSP настроен правильно?
Проверьте консоль браузера на ошибки CSP, настройте отчёты и протестируйте в режиме Report-Only. Инструмент проверки CSP покажет текущие директивы.
