ANTICHAT - Что такое Content Security Policy и зачем она нужна

Content Security Policy (CSP) — это такая штука, от которой реально стоит знать всем, кто хоть как-то замешан в веб-разработке или поддержке сайтов. Если объяснять простым языком, то CSP — это своего рода набор правил, который веб-сервер шлёт браузеру, чтобы сказать: "Эй, вот разрешённые источники, с которых можно загружать скрипты, стили, картинки и прочий контент, а всё остальное — стоп". Это помогает отпилить кучу проблем с безопасностью, особенно с XSS-атками, когда в страницы внедряют вредоносный код.

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

Что такое Content Security Policy и как он работает

Вкратце, CSP — это заголовок или специальный тег meta, который отсылается вместе с веб-страницей. В нём прописываются политики по типам ресурсов: откуда можно грузить скрипты, где брать шрифты, стили, картинки, iframe и так далее. Браузер, получив этот заголовок, не выполнит ничего, что противоречит этим правилам. Например, если вы скажете, что скрипты разрешены только с вашего домена, то сторонний скрипт с подозрительного источника просто не запустится.

Политика может включать множество директив, вот самые распространённые:

- script-src — с каких источников разрешено загружать JavaScript;
- style-src — откуда брать CSS;
- img-src — с каких доменов загружаются изображения;
- connect-src — куда можно отправлять сетевые запросы (AJAX, WebSocket);
- font-src — откуда загружать шрифты;
- frame-src — какие сайты разрешено вставлять в iframe.

CSP можно настроить с разной степенью жёсткости: от мягкой, которая просто отслеживает нарушения, но не блокирует их (режим report-only), до настоящей бронебойной защиты.

Кому и где нужна CSP

- Веб-приложения с пользовательским контентом: форумы, соцсети, комментарии. Там, где юзеры могут что-то вставлять — всегда опасность XSS. CSP тут помогает защитить всех.
- Интернет-магазины и сервисы с оплатой, чтобы уменьшить риск кражи данных.
- Админки и панели управления, где особенно ценна безопасность.
- Корпоративные порталы, где важна защита от утечек.
- CMS, где много плагинов и сторонних тем, часто непонятно, какой скрипт что грузит.

Плюсы использования CSP

- Значительно снижает риски XSS.
- Помогает выявлять и блокировать нежелательные подключения.
- Может служить дополнением к другим мерам безопасности (HTTPS, Subresource Integrity).
- Позволяет комплексно контролировать политику загрузки ресурсов.

Однако надо понимать, что CSP — не панацея, и неправильная настройка может просто сломать функционал сайта.

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

1. Попросту запретить все скрипты, кроме родных

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

Это значит: разрешены только скрипты с вашего же домена, любые внешние будут заблокированы. Для простых сайтов это логично, но если у вас есть сторонние виджеты, карты или аналитика — подумаете дважды.

2. Разрешаем скрипты с нескольких источников

Content-Security-Policy: script-src 'self' https://cdn.example.com https://ajax.googleapis.com;

То есть скрипты можно грузить с собственного домена и ещё с двух доверенных CDN. Все остальные — в мусор.

3. Использование nonce или hash для inline-скриптов

Если у вас на странице inline-скрипты, CSP по умолчанию их блокирует. Чтобы разрешить, нужно либо добавлять хеш-суммы этих скриптов, либо динамически генерировать nonce (уникальный ключ для каждой страницы) и прописывать его и в CSP, и в теги script.

4. Пример политики для магазина с аналитикой и шрифтами Google:

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.google-analytics.com; style-src 'self' https://fonts.googleapis.com; font-src https://fonts.gstatic.com; img-src 'self' data: https:;

Как не надо делать: основные ошибки при работе с CSP

- Писать слишком расслабленную политику с кучей "unsafe-inline" и "unsafe-eval". Это снимает весь смысл CSP, потому что разрешается выполнение непроверенного кода.
- Игнорировать inline-скрипты. Если их много — лучше рефакторить код и убирать инлайны, чем ломать политику, добавляя unsafe-inline.
- Не тестировать на разных браузерах. Внезапно что-то ломается только в Firefox или Safari.
- Писать политику и сразу же её жестко внедрять без режима report-only. Лучше сначала посмотреть, что и как будет блокироваться, чтобы не угробить сайт.
- Не использовать отчёты (report-uri или report-to), чтобы отслеживать нарушения CSP.

Чек-лист перед внедрением CSP

- Проверьте, с каких доменов грузятся все ваши скрипты и ресурсы.
- Убедитесь, что inline-скрипты минимизированы или заменены на внешние.
- Настройте режим report-only, чтобы понять, что будет блокироваться.
- Добавьте директивы для всех нужных типов ресурсов, не забывайте про шрифты, стили, connect-src.
- Проверьте работу сайта в разных браузерах.
- Используйте механизм отчётов, чтобы мониторить нарушения.
- После успешного тестирования переходите на жёсткий режим.
- Постоянно актуализируйте политику, если добавляете новые виджеты, скрипты и т.д.

Часто задаваемые вопросы по CSP

Вопрос: Что делать, если после включения CSP ломается сайт?

Ответ: Скорее всего в вашей политике запрещены inline-скрипты или внешние ресурсы, которые нужны сайту. Попробуйте включить режим report-only, посмотрите в консоли браузера, какие именно ресурсы блокируются, и скорректируйте политику.

Вопрос: Может ли CSP защитить от всех видов атак?

Нет, CSP помогает с XSS и некоторыми другими векторами, но не гарантирует 100% безопасность. Всегда нужна комплексная защита: HTTPS, проверка данных, безопасный код, обновления.

Вопрос: Как понять, какие домены включать в политику?

Нужно проанализировать ваш сайт, посмотреть, откуда подгружаются скрипты, стили, шрифты и так далее. Обычно браузер в консоли выдаст предупреждения, если что-то блокируется в report-only режиме.

Вопрос: Нужно ли использовать CSP на личном блоге?

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

Вопрос: Какие есть инструменты для генерации CSP?

Есть несколько онлайн-генераторов, например, https://cspvalidator.org/, а ещё в Chrome и Firefox есть расширения и встроенные средства для диагностики CSP.

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