Что такое Content Security Policy и зачем она нужна — что думаете?
 

Давайте поговорим подробнее про Content Security Policy (CSP) — что это вообще такое и почему веб-разработчикам, администраторам сайтов и всем, кто связан с вебом, стоит серьезно на это обратить внимание. CSP — один из самых крутых и в то же время несложных в реализации способов защититься от кросс-сайтовых скриптовых атак (XSS) и других «гадостей», которые пытаются исполниться прямо в браузере пользователя.

Что такое Content Security Policy и как она работает
Content Security Policy — это специальный HTTP-заголовок, который сервер отправляет браузеру вместе со страницей. В этом заголовке описываются правила, кому и что разрешено грузиться и исполняться на сайте. Это может касаться скриптов, стилей, изображений, шрифтов, медиа-файлов и т.д. По сути, CSP — это белый список источников контента, которые браузер должен строго соблюдать. Если в коде или на странице появляется что-то, что не попадает в этот список, браузер просто не позволит этому элементу загрузиться или выполниться.

Зачем вообще это нужно и кто в выигрыше
Любой сайт, особенно если у него есть динамический контент, форму для ввода, комментарии или вообще любой пользовательский ввод, потенциально подвержен XSS-атакам. Сложно угадать, откуда прилетит вредоносный скрипт, и зачастую хакеры находят лазейки, чтобы впарить на страницу свой JS-код и украсть куки, поковыряться в сессии, заменить контент и доставлять много неприятностей. CSP помогает свести это к минимуму, давая строгие рамки для браузера и запрещая что-то, что не соответствует заданной политике.

Где-то это особенно полезно?
- На блогах и форумах с пользовательским контентом (комментарии, посты).
- Интернет-магазинах с большим количеством разных плагинов и внешних сервисов — сюда часто подгружаются рекламные скрипты, виджеты и прочее. CSP поможет их контролировать.
- SaaS-приложениях, где логика идет на стороне клиента, а ввод данных активно используется.
- Собственных проектах или CMS — на уровне админки, чтобы ограничить потенциал вредоносных вставок.
- Больших корпоративных порталах, где много сторонних библиотек и интеграций — CSP помогает не допустить проблем с безопасностью.

Подробный разбор директив
- script-src — тут выбираем, откуда разрешены скрипты. Например, можно запрещать inline-скрипты и event handler (onclick и т.п.). Это сразу мониторит одну из главных проблем — XSS. Если нужно разрешить inline, вместо unsafe-inline лучше использовать nonce или hash.
- style-src — тоже самое, только для CSS. Можно запретить инлайновые стили и давать доступ только к нужным CDN.
- img-src — ограничивает загрузку изображений. С помощью этого можно убрать трекинговые пиксели с посторонних сайтов.
- font-src — шрифты не всегда безопасны, особенно когда идут с неизвестных CDN, можно ограничиться проверенными доменами.
- connect-src — ограничивает Ajax-запросы, WebSocket-соединения, часто забываемая, а полезная директива.
- report-uri или report-to — сюда отправляются отчёты при срабатывании CSP, помогает быстро увидеть, где что сломалось или пытались что-то впихнуть запрещённое.

Практические примеры использования CSP
1. Разрешаем скрипты только с собственного домена и CDN, полный запрет на unsafe-inline. Это помогает снять кучу потенциальных XSS.
2. Отключаем загрузку изображений с любых доменов, кроме своего и доверенных партнеров — полезно для защиты от сторонней рекламы и трекинга.
3. Используем nonce для разрешения конкретных inline-скриптов, чтобы не заваливать весь сайт unsafe-inline, это даёт гибкость.
4. Вводим директиву report-uri с URL, который будет собирать репорты — так видим реальные попытки нарушить CSP и можем оперативно реагировать.

Типичные ошибки и как их избежать
- Добавление unsafe-inline и * (звёздочка) в качестве разрешения почти убивает весь смысл CSP. Это типа закрывать двери, но оставлять окно открытым.
- Раскатывание строгой политики сразу на боевом производственном сайте без адекватного тестирования приводит к поломке функционала: скрипты не выполняются, стили ломаются, кнопки перестают работать. Всегда сначала пробуйте в режиме report-only, чтобы понять, что и как ломается.
- Забывают учитывать особенности браузеров и конфликт версий CSP (например, некоторые старые браузеры плохо поддерживают некоторые директивы).
- Не анализируют репорты, приходящие через report-uri, хотя это кладезь информации о возможных атаках и ошибках политики.
- Конфигурация CSP в режиме “всё или ничего”. Иногда стоит начать с менее строгого варианта и постепенно наращивать ограничение по мере уверенности.
- Плохо документируют настройки CSP, из-за чего в команде возникают непонимания и ошибка при обновлении.

Чек-лист перед внедрением CSP
- Убедитесь, что все используемые внешние ресурсы занесены в политику.
- Включите режим report-only и собирайте данные несколько недель.
- Проанализируйте отчёты и подкорректируйте политику.
- Проверяйте работу сайта на разных браузерах, особенно старых.
- Постепенно снимайте report-only и переводите CSP в блокирующий режим.
- Обновляйте политику CSP при добавлении новых внешних ресурсов или изменений.
- Следите за поведением отчетов и возможными попытками обхода.

Инструменты, которые помогут с CSP
- CSP Evaluator от Google — отличный сканер и анализатор политики, показывает слабые места.
- DevTools в браузерах (Chrome, Firefox) — смотреть вкладки Console и Security, там видно, что именно заблокировано или нарушено.
- Online генераторы CSP — позволяют составить политику с нуля или подправить существующую.
- Report URI и аналогичные сервисы — собирают данные о нарушениях в реальном времени с вашей площадки.

FAQ
- Можно ли использовать CSP с любым фреймворком?
Да, большинство популярных фреймворков (React, Vue, Angular) отлично работают с CSP, но важно правильно конфигурировать nonce/hashes для inline-скриптов, которые иногда подсунутся по умолчанию.
- Что делать, если CSP ломает сайт?
Включайте report-only режим и постепенно изучайте отчёты. Переделывайте политику, минуя unsafe-inline, в идеале используя nonce. Временно можно расслабить ограничения, но только чтобы вернуть работоспособность, а потом уж исправлять.
- Насколько CSP защищает от XSS?
CSP — один из самых мощных инструментов для ограничения возможностей XSS. Конечно, лучше всего сочетать CSP с другими методами (валидация входных данных, escaping), но без CSP защита получается намного слабее.
- Нужно ли постоянно обновлять политику?
Да, при добавлении новых скриптов, шрифтов или подключении внешних сервисов надо править CSP. Иначе браузер будет блокировать новые ресурсы, и сайт сломается.
- Можно ли обойти CSP?
Теоретически в редких случаях — да, если есть серьезные уязвимости, но CSP существенно повышает стоимость атаки и часто помогает избежать большинства скриптовых инъекций.
- Как проверить, что CSP действительно работает?
Легко! Посмотрите в консоли браузера — если есть ошибки, значит что-то пыталось загрузиться, но политики помешали. Также изучайте отчеты с report-uri.

Так что, кто использует CSP и как у вас с этим? Делитесь опытом, новыми идеями и лайфхаками! Хотелось бы понять, насколько люди тут реально внедряют политику и какие проблемы с ней столкнулись. Для меня CSP — старая добрая штука, которая реально спасает нервы и пользователей от неприятных историй с XSS. Впрочем, у неё тоже свои подводные камни, особенно по части настройки и поддержки. Будет интересно почитать ваши кейсы!