Введение
Content Security Policy (CSP) — это реально одна из самых мощных и полезных штуковин, если ты занимаешься разработкой или администрированием веб-сайтов. Проще говоря, это политика безопасности, которую сайт "говорит" браузеру, чтобы тот строго контролировал, откуда можно подгружать и запускать скрипты, стили, шрифты, изображения и прочие ресурсы. Особенно полезна она, чтобы бороться с такими атаками, как XSS (межсайтовый скриптинг), когда злоумышленник пытается вставить в код сайта вредоносный скрипт и навредить пользователям.

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

Что такое CSP на самом деле
Технически это HTTP-заголовок, который сервер шлёт браузеру вместе со страницей. В заголовке прописывается набор разрешений (политик), откуда и что можно загружать — например, скрипты только с вашего домена, стили с доверенных CDN, шрифты с определённых источников и так далее. Если браузер видит ресурс, который не вписывается в эти правила, он просто блокирует загрузку и выполнение. Это резко сокращает возможность для атак.

Как выглядит CSP на практике
Давайте посмотрим пример простого CSP-заголовка:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline';

Здесь мы говорим:
- default-src 'self' — по умолчанию разрешаем загружать всё только с своего собственного домена, чтобы не брать нежелательные ресурсы извне;
- script-src 'self' https://cdn.example.com — скрипты можно брать либо со своего сайта, либо с CDN по указанному адресу;
- style-src 'self' 'unsafe-inline' — стили разрешены со своего сайта, а также допускается inline-стили (хотя это и не очень безопасно, но иногда необходимо для совместимости).

Как видите, можно гибко настроить политику под свои потребности.

Где CSP помогает
- Защита сайтов с пользовательским контентом — чтобы никто не вставил чёртов JavaScript и не начал воровать данные пользователей или делать неправомерные действия.
- Защита админок и личных кабинетов — уменьшается риск серьезных взломов через скрытые скрипты.
- Защита от атак на внешние библиотеки и CDN — если какая-то CDN взломана, можно ограничить загрузку только с доверенных источников.
- Отмена inline-скриптов и стилей — эта практика потом заставляет чистить код и работать официальными, проверенными способами.

Типичные ошибки при работе с CSP
- Лишнее доверие к 'unsafe-inline' и 'unsafe-eval' — это как открыть дверь для атакующих. Лучше обходиться без них или использовать nonce/hashes.
- Забытие о контенте, который грузится динамически — например, теги script создаются через JS, но не учтены в политике, из-за чего ресурсы могут блокироваться и ломаться важные функции.
- Чрезмерные ограничения — если закрутить систему слишком строго, сайт просто перестанет работать нормально, что решается только подробным тестированием.
- Некорректное добавление нескольких источников с ошибками в синтаксисе — браузер будет игнорировать всю политику или принимать её неверно.
- Невнимание к сообщениями в консоли — браузеры часто показывают предупреждения или ошибки CSP, и это важно отслеживать сразу.

Практический пример настройки CSP для простого блога
Допустим, у нас есть блог, где контент загружается на нашем домене и используется Google Fonts плюс скрипты с нашего CDN.

Можно сделать такой заголовок:

Content-Security-Policy: default-src 'self'; script-src 'self' https://mycdn.example.com; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com;

Что мы делаем:
- default-src ограничивает по умолчанию до нашего домена;
- разрешаем скрипты только с домена и CDN;
- стили — с Google Fonts;
- шрифты — с Google Fonts тоже.

Такой вариант уже защищает от загрузки скриптов с подозрительных сайтов, а шрифты и стили официально разрешены.

Чек-лист по внедрению CSP
- Определить, какие ресурсы используются на сайте (скрипты, стили, шрифты, изображения, фреймы).
- Выяснить, с каких доменов они подгружаются.
- Составить базовую политику с default-src и конкретными правилами для script-src, style-src, img-src и font-src.
- Избегать unsafe-inline по возможности, использовать nonce или hash для inline-кода.
- Настроить CSP сначала в режиме "Report Only" для сбора ошибок и тестирования.
- Проверить консоль браузера на предупреждения CSP и исправить проблемы.
- Постепенно переводить CSP в режим блокировки (enforce).
- Не забывать обновлять политику при добавлении новых ресурсов на сайт.
- Добавить CSP-report-uri или report-to, чтобы получать отчёты о нарушениях.

FAQ
Вопрос: CSP — это только для защиты от XSS?
Ответ: Нет, CSP защищает не только от XSS, но и от внедрения любых нежелательных ресурсов — например, подмены стилей, шрифтов, картинок, а также кликджекинга и других опасностей.

Вопрос: Можно ли полностью запретить inline-скрипты?
Ответ: Да, и это рекомендуется делать. Однако если у вас есть инлайновый код, используйте nonce (одноразовые токены) или hash (хэш-сумму), чтобы этот код разрешить.

Вопрос: CSP сильно замедляет сайт?
Ответ: Нет, на производительность CSP почти не влияет, это просто набор правил для браузера. Но если политика слишком сложная, браузеру может немного сложнее её обрабатывать.

Вопрос: Какие браузеры поддерживают CSP?
Ответ: Практически все современные браузеры — Chrome, Firefox, Edge, Safari. Некоторые старые версии могут не поддерживать все директивы, но базовый функционал есть уже давно.

Вопрос: Если CSP сломал сайт, что делать?
Ответ: Переведите CSP в режим "Report Only", изучите предупреждения в консоли и по отчётам, исправьте политику. Главное — внедрять CSP постепенно и с тестированием, не влеплять строгие правила сразу на рабочий ресурс.

Заключение
CSP — это очень полезный инструмент, который помогает жестко контролировать, что именно браузер будет считать допустимыми ресурсами на сайте. Правильно настроенный CSP значительно повышает безопасность, особенно на сайтах с пользовательским контентом. Но его настройка требует внимательности, понимания технических деталей и тестирования. В итоге победа над XSS и другими атаками стоит потраченных усилий. Кто уже юзал CSP — делитесь опытом, подскажите лайфхаки, как не нарываться на грабли!