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

Текст:
Привет, ребята! Чувствую, тема Content Security Policy (CSP) на форуме в последнее время часто всплывает, а вопросов по ней всё равно много. Давайте разберём более подробно, что это такое, зачем оно нужно, и как с ним работать, чтобы не спалиться и не напрячь пользователей.

---

Что такое Content Security Policy (CSP)?

Content Security Policy — это своего рода директивы безопасности, которые сервер отправляет браузеру в виде специальных HTTP-заголовков (реже через HTML-мета-тег). В итоге браузер знает, какие именно ресурсы можно грузить и исполнять на странице, а какие нет. Главная цель — снизить риск таких атак, как XSS (межсайтовый скриптинг), когда злоумышленник пытается внедрить на сайт вредоносный код.

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

---

Как работает CSP — принципы

CSP задаётся через заголовок Content-Security-Policy. В этом заголовке можно прописать кучу правил вроде:

- Откуда можно грузить скрипты (script-src)
- Откуда можно брать стили (style-src)
- Откуда можно загружать картинки (img-src)
- Разрешённые шрифты (font-src)
- Разрешённые AJAX-запросы (connect-src)
- Где можно брать медиа-контент (media-src)
- Можно ли использовать inline-скрипты и стили (unsafe-inline — очень опасно, лучше забыть)

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

---

Где и зачем применять CSP

Пожалуй, CSP полезна практически везде. Особенно, если у вас:

- Сайт с возможностью пользователя загружать контент (комменты, посты, файлы)
- Админка, личный кабинет, где важна безопасность
- Использование внешних сторонних скриптов — например, рекламы, аналитики, виджетов
- Маркетплейсы, форумы, социальные сети — там, где много разных юзеров и последствий от взлома больше

Пример: на обычном блоге с комментами, если не стоит CSP, кто-то может вставить скрипт, и при заходе других пользователей тот скрипт исполнится и украдёт куки или отправит личные данные куда надо. CSP помогает свести такие риски к минимуму.

---

Практические примеры CSP

1. Простой базовый пример: разрешаем грузить скрипты только с собственного домена и разрешаем стили с того же домена

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

2. Немного сложнее — разрешаем загрузку картинок с собственного домена и из Google Fonts, плюс разрешаем загрузку шрифтов с того же Google Fonts:

Content-Security-Policy:
script-src 'self';
style-src 'self' fonts.googleapis.com;
img-src 'self';
font-src fonts.gstatic.com;

3. Если используете внешний аналитический скрипт (например, Google Analytics), придётся его явно разрешить:

Content-Security-Policy:
script-src 'self' www.google-analytics.com;
connect-src www.google-analytics.com;

---

Типичный чек-лист перед внедрением CSP

- Проверьте, какие внешние источники скриптов и стилей реально используете
- Откажитесь от inline-скриптов и стилей, если можно, или используйте nonce/hashes
- Протестируйте свой сайт с CSP в режиме report-only — чтобы ошибки не вырубили пользователей
- Подключите сбор логов нарушений (CSP report-uri) на сервер, чтобы мониторить нарушения
- Отфильтруйте сторонние скрипты, уберите лишние
- Постепенно ужесточайте правила, чтобы не сломать функционал
- Не забывайте, что CSP — это не панацея, а дополнение к другим мерам безопасности

---

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

- Использование unsafe-inline без необходимости — этим вы в итоге полностью нивелируете смысл CSP
- Неучёт всех внешних доменов, откуда загружаются ресурсы — из-за чего страница ломается или ресурсы не грузятся
- Копирование шаблонов с чужих сайтов без адаптации под свои нужды
- Внедрение слишком жёсткой политики сразу, без тестирования, что вызовет сломанный функционал
- Игнорирование отчётов об ошибках — они очень помогают понять, что мешает
- Доверие «*» (всем доменам) или blob:, data:, которые часто применяют «для скорости» — так CSP теряет смысл

---

FAQ

— Можно ли отключить CSP для мобильных приложений?
Если у вас веб-приложение в WebView, обычно CSP тоже работает. Для мобильных нативных приложений это не актуально, но если там встраивается веб-интерфейс — тогда лучше сделать CSP корректно.

— Что делать, если у меня много сторонних скриптов?
Попробуйте пересмотреть, нужны ли все. Для тех, что точно нужны, добавьте домены в правила CSP. Если есть inline-скрипты, попробуйте заменить их на внешние или использовать nonce/hashes. В крайнем случае можно временно разрешить unsafe-inline, но это стоит считать временным решением.

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

— Как узнать, откуда реально грузятся все ресурсы?
Используйте встроенный в браузер инструментарий разработчика: вкладка Network подскажет источники. Ещё помогает временно поставить CSP в режиме report-only, чтобы увидеть, что блокируется.

— CSP плоха для SEO?
Никак не влияет, если настроена правильно. Главное — не блокировать нормальный функционал и ресурсы, которые нужны для сайта.

---

Если кто настроил CSP на своем сайте, поделитесь опытом! Какие подводные камни встретились? Удалось ли отказаться от inline-скриптов? Как мониторите нарушения?

Всем мира и мало багов!