Что такое CSP

CSP отвечает на вопрос: какие ресурсы эта страница имеет право использовать. Браузер получает политику вместе с HTML и применяет ее к загрузке скриптов, стилей, изображений, шрифтов, iframe и сетевых соединений.

Короткий ответ может звучать так:

CSP это политика безопасности, которая ограничивает источники ресурсов на странице. Она особенно полезна против XSS, потому что может заблокировать выполнение скрипта, который не пришел из разрешенного источника или не имеет разрешенного nonce/hash.

Важно не сказать лишнего. CSP не делает приложение безопасным автоматически. Если код вставляет пользовательский HTML через innerHTML, проблема все равно остается. CSP просто добавляет дополнительный слой защиты.

Типичная политика задается HTTP-заголовком:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; connect-src 'self' https://api.example.com; object-src 'none'; base-uri 'self'

Здесь default-src 'self' задает базовое ограничение, script-src разрешает JS только с текущего origin и конкретного CDN, connect-src разрешает запросы к своему API, а object-src 'none' закрывает старые встраиваемые объекты.

Практический риск для фронтенда простой. Если забыть connect-src для API, приложение может отрендериться, но данные не загрузятся. Если забыть CDN для шрифтов или картинок, пользователь увидит сломанный интерфейс. Поэтому CSP надо тестировать как часть продукта, а не только как настройку сервера.

Самая частая ловушка, inline-скрипты. Строгая CSP обычно не хочет выполнять произвольный inline-код, потому что именно так часто проявляется XSS. Быстрое, но слабое решение, добавить 'unsafe-inline'. На интервью лучше сказать, что это снижает пользу CSP и должно быть исключением.

Более безопасный вариант для конкретного inline-скрипта, nonce:

<script nonce="r4nd0m-value-from-server">
  window.__APP_CONFIG__ = { apiUrl: "https://api.example.com" };
</script>

И соответствующая часть заголовка:

Content-Security-Policy: script-src 'self' 'nonce-r4nd0m-value-from-server'

В реальном приложении nonce должен быть случайным и новым для каждого HTTP-ответа. Не надо хардкодить его как постоянную строку. Если в inline-скрипт попадает состояние из пользователя или CMS, его нужно безопасно сериализовать и экранировать. Иначе CSP может не спасти от XSS, а UI получит выполнение чужого кода еще до гидратации. Hash работает иначе. Браузер разрешает inline-фрагмент, если его содержимое совпадает с указанным хешем. Это удобно для стабильного кода, но плохо подходит для динамического содержимого.

Хороший ответ не заканчивается списком директив. Покажите, что вы думаете о rollout. Для существующего проекта безопаснее включить Content-Security-Policy-Report-Only, собрать отчеты о нарушениях, уточнить список разрешенных источников и только потом включать блокирующий режим.

Если сразу включить строгую политику, можно получить не уязвимость, а продакшен-инцидент. Не открывается оплата, не грузится карта, не работает чат поддержки, не уходят события аналитики, форма отправляется не туда или не отправляется вообще. Это не значит, что CSP не нужна. Это значит, что ее надо внедрять по шагам.

На стороне фронтенда CSP часто проявляется как странная ошибка в браузерной консоли. Код выглядит правильным, но ресурс заблокирован политикой. Поэтому при отладке нужно смотреть не только Network и логи API, но и сообщения вида "Refused to load" или "Refused to connect".

Сильная формулировка на интервью:

Я воспринимаю CSP как контракт между серверной настройкой и фронтендом. Фронтенд должен знать, какие CDN, API, iframe, шрифты и аналитика реально нужны, иначе политика будет либо слишком слабой, либо будет ломать пользовательские сценарии.

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

Например, API может разрешать CORS для вашего домена, но запрос все равно будет заблокирован, если CSP не разрешает этот API в connect-src. И наоборот: наличие адреса в connect-src не означает, что сервер отдаст ответ с нужными CORS-заголовками.