Content Security Policy на сайте с персональными данными: зачем нужен CSP и как его внедрить

Content Security Policy — это заголовок ответа сервера, в котором перечислено, откуда браузеру разрешено загружать скрипты и куда разрешено отправлять данные со страницы. Для 152-ФЗ он важен по одной причине: персональные данные можно потерять не только из базы — есть отдельный сценарий, когда их перехватывает прямо на странице формы чужой или подменённый скрипт, и снаружи это незаметно. Прямого требования включать CSP в законе нет; это одна из технических мер, которыми оператор выполняет обязанность по статье 19 152-ФЗ.

Проверить бесплатно, какие трекеры срабатывают на вашем сайте до согласия ←

Как работает CSP и что он ограничивает?

Сервер добавляет к ответу заголовок Content-Security-Policy со списком правил. Браузер читает его до того, как выполнить код на странице, и блокирует всё, что в правила не укладывается.

Ключевая идея: решение принимает браузер посетителя, а не ваш сервер. Даже если злоумышленник сумел подставить свой код на страницу, отправить собранное на адрес, которого нет в политике, он не сможет — такое соединение браузер просто не откроет. Оговорка важная: адреса, которые вы разрешили сами, остаются открытыми.

Правила задаются директивами. Тем, у кого на сайте есть формы, важны в первую очередь эти:

Самая ценная директива в контексте персональных данных — connect-src. Скрипт, который собрал содержимое полей, должен куда-то его передать: запросом, отправкой изображения или фоновым сигналом. Если разрешены только ваши собственные адреса, вывод данных наружу перестаёт работать.

Причём тут 152-ФЗ, если про CSP в законе ничего нет?

В законе действительно нет ни слова о заголовках, и это нормально: нормы о защите написаны через результат, а не через технологию.

Часть 1 статьи 19 152-ФЗ обязывает оператора принимать необходимые правовые, организационные и технические меры для защиты персональных данных от неправомерного или случайного доступа, уничтожения, изменения, блокирования, копирования, предоставления, распространения. Конкретный состав мер определяется исходя из уровня защищённости и актуальных угроз: уровни задаёт постановление Правительства №1119, состав мер — приказ ФСТЭК №21. Что из этого приказа реально касается владельца обычного сайта, разобрано в статье «Приказ ФСТЭК №21: что из него касается владельца сайта».

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

Важно не переусердствовать в обратную сторону. Наличие CSP не делает сайт соответствующим 152-ФЗ и не заменяет ни политику обработки, ни согласие, ни уведомление Роскомнадзора. Это одна мера против одной угрозы.

Как данные утекают прямо со страницы?

Сценарий, против которого работает CSP, устроен буднично.

Шаг 1. На страницу попадает чужой код. Вариантов немного: уязвимость, позволяющая вставить скрипт; взлом сервера сторонней библиотеки, которую вы подключаете по ссылке; скомпрометированный аккаунт в системе управления тегами; забытый виджет, у которого сменился владелец.

Шаг 2. Код читает поля формы. Ему доступно всё, что видит страница: имя, телефон, адрес, содержимое корзины, реквизиты оплаты. Ничего взламывать не нужно — скрипт на странице по умолчанию имеет к ним доступ.

Шаг 3. Данные уходят наружу. Обычным запросом на чужой домен или незаметной загрузкой картинки, в адресе которой закодировано содержимое полей.

Заметить это трудно: сайт работает нормально, заказы оформляются, в логах сервера ничего необычного. Признаки чаще приходят снаружи — от клиентов, из публикаций, от исследователей. Как устроено обнаружение, разобрано в статье «Утечка персональных данных: как обнаружить».

CSP разрывает третий шаг — вывод данных наружу. Первый он закрывает лишь частично: скрипт с постороннего домена браузер не исполнит, но код, пришедший из уже разрешённого вами источника, пройдёт. И у этого есть прямое юридическое следствие: если инцидент всё же произошёл, оператор обязан уведомить Роскомнадзор в течение 24 часов, а о результатах внутреннего расследования — в течение 72 часов (часть 3.1 статьи 21 152-ФЗ). Неуведомление квалифицируется отдельно от самой утечки — по части 11 статьи 13.11 КоАП РФ это от 1 000 000 до 3 000 000 ₽ для юридических лиц.

С чего начать внедрение, чтобы не сломать сайт?

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

Правильный порядок — четыре шага.

1. Режим отчётов. Включите заголовок Content-Security-Policy-Report-Only с базовым набором правил и адресом для сбора отчётов. Браузер ничего не блокирует, но сообщает, что заблокировал бы.
2. Сбор картины. Одна-две недели — и у вас есть фактический список доменов, которые использует сайт. Почти всегда он длиннее, чем ожидали: шрифты, видео, виджеты отзывов, пиксели рекламных кабинетов.
3. Чистка списка. Прежде чем разрешать источник, спросите, нужен ли он вообще. Лишний сторонний скрипт — это и риск для данных, и лишняя строка в вашей cookie-политике. Как составить реестр сервисов, разобрано в статье «Cookie-политика: как её составить».
4. Боевой режим по частям. Переводите в блокирующий режим не всю политику разом, а по директивам: сначала object-src и frame-ancestors, потом form-action и base-uri, в последнюю очередь script-src и connect-src.

Отдельная тема — встроенные скрипты в разметке. Разрешение 'unsafe-inline' обесценивает script-src почти полностью: именно встроенным кодом чаще всего и работает атака. Правильный путь — одноразовые метки nonce или хеши конкретных фрагментов. Это требует правки шаблонов, поэтому и стоит в конце очереди.

Как выглядит минимальная рабочая политика?

Ниже — не готовый ответ для вашего сайта, а каркас, в который подставляются ваши источники. Разберите каждую строку прежде, чем ставить её на сервер.

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' https://mc.yandex.ru;
  connect-src 'self' https://mc.yandex.ru;
  img-src 'self' data: https://mc.yandex.ru;
  style-src 'self';
  font-src 'self';
  frame-src 'self';
  form-action 'self';
  base-uri 'self';
  object-src 'none';
  frame-ancestors 'self';
  report-uri /csp-report

Что здесь важно по смыслу.

• default-src 'self' задаёт закрытое по умолчанию правило: всё, что не разрешено явно, запрещено. Открытые директивы перечисляются после него и только там, где действительно нужны.
• Каждый сторонний домен в списке — это осознанное решение, а не наследство. Счётчик посещаемости в примере стоит и в script-src, и в connect-src, потому что он и загружается, и отправляет данные; одной строки для него недостаточно.
• img-src с data: разрешает встроенные изображения. Это удобно и часто необходимо, но именно этим каналом иногда выводят данные — если ваш сайт без встроенных картинок обходится, лучше не разрешать.
• form-action 'self' стоит проверить отдельно, если формы уходят во внешний сервис заявок: такой адрес придётся добавить явно.
• Адрес в report-uri должен принимать запросы и куда-то их складывать. Точка сбора, которая молча возвращает ошибку, оставляет вас без данных, ради которых всё и затевалось.

Когда отчёты за пару недель перестают приносить новые источники, директивы из этого заголовка начинают переносить в боевой Content-Security-Policy — по одной-две за раз, оставляя остальные в режиме отчётов. Два заголовка в ответе спокойно сосуществуют: боевой применяется, Report-Only продолжает собирать картину.

Какие ошибки встречаются чаще всего?

Политика скопирована из статьи целиком. Чужой список доменов не имеет отношения к вашему сайту: одни сервисы лишние, других не хватает.

'unsafe-inline' и 'unsafe-eval' в script-src. Формально политика есть, фактически она разрешает то, ради запрета чего её и ставят.

Разрешён домен целиком, включая пользовательский контент. Открыв источник, где кто угодно может разместить файл, вы открываете и путь для чужого кода.

Забыли connect-src. Скрипты ограничены, а отправка данных — нет. Канал вывода остаётся открытым.

Нет form-action. Подмена адреса отправки формы — самый короткий путь к данным, и закрывается он одной строкой.

Отчёты никто не читает. Точка сбора настроена, запросы копятся в журнале, в который не заглядывают. Мера без наблюдения перестаёт быть мерой.

Чего CSP не делает?

Об этом честнее сказать прямо, потому что CSP часто продают как универсальное решение.

• Не защищает сервер. Взлом хостинга, украденный пароль от админки, выгрузка из CRM — всё это мимо.
• Не спасает от доверенного источника. Если скомпрометирован сервис, который вы сами разрешили, браузер пропустит его код.
• Не заменяет согласие. Счётчик из белого списка сработает до нажатия кнопки в баннере, если его загрузку не отложили отдельно. Как это делается, разобрано в статье «Блокировка скриптов до согласия».
• Не является обязательным требованием. Ни одна проверка не спросит у вас «где ваш CSP» такими словами. Спросят другое: какие угрозы вы считаете актуальными и какие меры против них приняли.
• Не проверяется нашим сканером. Мы смотрим на то, что видно снаружи с точки зрения 152-ФЗ: политику, формы, согласия и трекеры, которые срабатывают до согласия. Наличие и качество CSP нужно смотреть отдельно — заголовки ответа видны в инструментах разработчика браузера.

Как проверить, что есть у вас сейчас?

1. Откройте сайт, вызовите инструменты разработчика, вкладку сетевых запросов.
2. Кликните по первому запросу — самому документу страницы — и найдите в заголовках ответа Content-Security-Policy.
3. Если заголовка нет, политики нет: мета-тег в разметке работает не для всех директив и точкой опоры служить не может.
4. Если заголовок есть, проверьте его на 'unsafe-inline' и на директивы connect-src и form-action.
5. Отдельно посмотрите список сторонних доменов в сетевых запросах: это и есть ваш реальный периметр.

Параллельно имеет смысл проверить то, что относится к 152-ФЗ и видно снаружи: политику, формы, чекбоксы и трекеры до согласия. Это наш сервис делает автоматически и бесплатно.

→ Проверить сайт на нарушения 152-ФЗ (бесплатно, 30 секунд)

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

• Приказ ФСТЭК №21: что из него касается владельца сайта — откуда берётся состав технических мер
• Утечка персональных данных: как обнаружить и что делать в первые 24 часа — если код всё-таки отработал
• Блокировка скриптов до согласия на cookie — соседняя задача, решается иначе
• Утечка и публичная коммуникация: что говорить клиентам и СМИ — что делать, когда об инциденте узнают снаружи

Источники: статья 19 Федерального закона №152-ФЗ «О персональных данных», постановление Правительства РФ №1119 от 01.11.2012, статья 13.11 КоАП РФ, описание директив CSP в документации MDN.