Defaults.Exposed › Исправления › Content-Security-Policy (CSP)

Как исправить Content-Security-Policy (CSP)

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

Главное для вашего бизнеса: Если ваш сайт когда-нибудь подменят, вредоносный код может считывать платёжные и учётные данные ваших клиентов прямо с вашей же оплаты, пока всё выглядит совершенно нормально, — оставляя вас с оспариваниями платежей, претензиями о мошенничестве, подлежащей отчёту утечкой данных и проваленной проверкой, которой службы безопасности более крупных клиентов пользуются, чтобы застопорить или убить сделку.

Во что это может вам обойтись

Скрытый код проскальзывает на одну из ваших страниц и тихо копирует каждый номер карты и пароль, который ваши клиенты вводят при оплате, отправляя это злоумышленнику, пока сайт выглядит совершенно нормально, — вы узнаёте только когда приходят жалобы о мошенничестве.
Мошенник подсаживает фальшивую форму «оплатить здесь» на ваш настоящий сайт, перехватывающую платежи на свой счёт; клиенты думают, что заплатили вам, винят вас, когда товар не приходит, и требуют деньги назад.
Служба безопасности более крупного клиента сканирует ваш сайт, видит, что эта базовая защита отключена, и помечает её — стопоря или лишая вас контракта, пока вы не докажете, что это исправлено.
Утечка, прослеженная до отсутствующего стандартного механизма защиты, становится инцидентом, подлежащим отчёту: вопросы регулятора, уведомления клиентов и репутационный удар, обходящийся куда дороже бесплатного исправления.

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

Что это простыми словами

Когда кто-то заходит на ваш сайт, его браузер скачивает вашу страницу и выполняет любой код, что на ней есть, — скрипты, которые раскрывают меню, заставляют кнопки работать, отправлять формы оплаты и так далее. По умолчанию браузер доверяет всему этому. У него нет способа узнать, какой код действительно ваш, а какой подсунул кто-то другой.

Политика безопасности контента (часто сокращаемая до CSP) — это короткий список правил, который ваш сайт прикрепляет к каждой странице, говоря браузеру: «выполняй код только из этих одобренных мной источников и отказывай всему остальному». Это разница между ночным клубом, пускающим кого угодно, и тем, у которого на двери список гостей.

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

Чем это может вам обойтись

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

Невидимый скиммер на оплате. Злоумышленник проскальзывает несколько строк кода на вашу страницу оплаты через уязвимый плагин или скомпрометированный сторонний скрипт. Каждый номер карты, имя и CVV, которые вводят клиенты, копируются и отправляются злоумышленнику в реальном времени. Ваш сайт выглядит и работает идеально; замок на месте. Вы обнаруживаете это спустя недели, когда ваш платёжный провайдер звонит о кластере жалоб о мошенничестве, ведущих обратно к вашему магазину. Теперь вы лицом к лицу с оспариваниями платежей, принудительным аудитом безопасности, возможной потерей права обработки карт и утечкой, о которой вы, возможно, обязаны сообщить по закону.
Фальшивая форма оплаты. Мошенник внедряет убедительное поле «оплатить здесь» на ваш настоящий сайт. Клиенты вводят данные, доверяя вашему бренду; деньги и данные идут злоумышленнику. Клиенты винят вас — и не зря, ведь это случилось на вашем сайте.
Потерянный контракт. Служба безопасности более крупного клиента запускает автоматическое сканирование вашего сайта в рамках проверки поставщика. Отсутствующая политика безопасности контента сразу всплывает как пробел высокой серьёзности. Для проверяющего из закупок или безопасности этот один отсутствующий механизм защиты читается как «этот поставщик не делает базовых вещей» — и сделка буксует, пока они просят устранения, или тихо уходит к конкуренту, прошедшему проверку.
Утечка, подлежащая отчёту. Когда утечку данных прослеживают до отсутствующего стандартного бесплатного механизма защиты, она перестаёт быть невезением и начинает выглядеть халатностью. Это меняет вопросы регулятора, обязанность уведомить клиентов и стоимость — и штраф, и репутационный ущерб, который держится долго после закрытия инцидента.
Скомпрометированное объявление или виджет. Многие сайты загружают код от сторонних лиц — рекламные сети, шрифты, чат поддержки, аналитику. Если хоть один из них взломан, вредоносный код едет прямиком на ваши страницы. Политика безопасности контента ограничивает радиус поражения, разрешая только конкретные доверенные вами внешние источники, так что взлом одного поставщика не становится автоматически вашим.

Что это на самом деле (детали)

Политика безопасности контента доставляется как один HTTP-заголовок ответа — строка, которую ваш веб-сервер отправляет с каждой страницей. Его значение — набор директив, каждая из которых называет тип контента и источники, разрешённые для него. Например:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

Простыми словами это гласит: по умолчанию загружать что-либо только с моего сайта; выполнять скрипты только с моего сайта; не разрешать плагины старого стиля; и не позволять другим сайтам встраивать мой в рамку.

Как выглядит «хорошо». Наша проверка не просто ищет наличие заголовка — она читает политику директива за директивой и оценивает, насколько она реально сильна, как сделал бы проверяющий безопасности. Сильная политика:

Задаёт ограничительную базу (default-src 'self') и расширяет её только для конкретных доверенных сторонних сервисов, которыми вы действительно пользуетесь.
Избегает лазеек. Она не использует 'unsafe-inline' или 'unsafe-eval' для скриптов и не использует подстановочные (*) или голые схемные источники (вроде https:) для скриптов — они фактически снова открывают дверь, что политика призвана закрыть. Где встроенные скрипты действительно нужны, она использует nonce или хэш, чтобы выполнялся только ваш конкретный одобренный код.
Запирает встраивание в рамки через frame-ancestors 'self' (это также блокирует атаку «встрой свой сайт, чтобы обмануть клиентов») и отключает устаревшие плагины через object-src 'none'.
Принуждает, а не только отчитывается. Заголовок Content-Security-Policy-Report-Only только наблюдает; он даёт ноль защиты во время выполнения. Наша проверка даёт ему малую долю зачёта и никогда не записывает как прохождение. Вы защищены, только когда политика принуждает.

Политика, которая существует, но опирается на 'unsafe-inline', 'unsafe-eval' или подстановочные знаки, всё равно получит низкую оценку — потому что на практике она даёт мало реальной защиты. Цель — тугая политика, а не любая политика.

Как это исправить (бесплатно, ~1–2 часа)

Передайте это вашему ИТ-специалисту или тому, кто ведёт ваш сайт, — само исправление полностью бесплатно. Мы берём плату только за мониторинг того, что она остаётся на месте и корректной со временем; включение её ничего не стоит. Причина, по которой это занимает час-два, а не минуты, — аккуратный пробный шаг, не дающий случайно заблокировать части вашего же сайта.

Начните в режиме «только отчёт» — пока не принуждайте. Добавьте заголовок ответа Content-Security-Policy-Report-Only. Он наблюдает и логирует, что было бы заблокировано, ничего фактически не блокируя, так что живой сайт продолжает работать, пока вы выясняете, от чего реально зависит каждая страница. (Важно: режим «только отчёт» сам по себе не даёт посетителям защиты — это лишь безопасный первый шаг.)
Постройте политику из того, что ваш сайт реально использует. Просмотрите отчёты, чтобы найти каждый легитимный источник скриптов, стилей, шрифтов и изображений — ваш собственный домен, вашу аналитику, ваш платёжный провайдер, хост ваших шрифтов, ваш виджет чата — и перечислите их как разрешённые источники. Прочная стартовая точка — default-src 'self' плюс явные записи для доверенных сторонних сервисов, которыми вы реально пользуетесь.
Избегайте лазеек, перечёркивающих весь смысл. Держитесь подальше от 'unsafe-inline' и 'unsafe-eval' для скриптов и избегайте подстановочных источников вроде * и голых схем вроде https: для скриптов — они снова открывают тот самый пробел, что политика призвана закрыть. Где встроенные скрипты неизбежны, используйте nonce или хэш, чтобы выполнялся только ваш конкретный одобренный код.
Заприте встраивание в рамки и плагины. Добавьте frame-ancestors 'self' (это также мешает другим сайтам встраивать ваш, чтобы обмануть клиентов, и удовлетворяет связанную проверку на кликджекинг) и object-src 'none', чтобы блокировать атаки на основе устаревших плагинов.
Переключитесь с «только отчёт» на принуждение. Когда отчёты чисты и сайт работает, смените имя заголовка с Content-Security-Policy-Report-Only на Content-Security-Policy. Это шаг, который реально даёт защиту — политика «только отчёт» сама по себе её не даёт и не пройдёт проверку.

Где задать заголовок, зависит от вашей платформы:
- Cloudflare: Rules → Transform Rules → Modify Response Header → задайте Content-Security-Policy. (Cloudflare можно использовать и для пробного «только отчёт».)
- Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
- Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
- IIS (web.config): добавьте пользовательский HTTP-заголовок ответа с именем Content-Security-Policy и политикой как значением.
- Google Workspace / Microsoft 365: они ведут вашу почту, а не публичный сайт, так что политика ставится там, где реально хостится ваш сайт (Cloudflare или ваш веб-хост выше), а не в админ-консоли почты.
Перепроверьте свой домен, чтобы убедиться, что политика теперь показывается включённой и принуждающей, без ослабляющих лазеек.

Частые ошибки

Остановка на «только отчёт». Самая частая ошибка: политику добавляют в режиме «только отчёт», все идут дальше, и сайт так и не защищён по-настоящему. Режим «только отчёт» не блокирует ничего. Нужно переключиться на принуждение.
Тянуться к 'unsafe-inline', чтобы «просто заработало». Когда политика блокирует легитимный встроенный скрипт, быстрое исправление — разрешить все встроенные скрипты, — но это снова открывает ту самую дыру, что политика была призвана закрыть. Используйте nonce или хэш.
Использование подстановочного знака. Голая * (или https:) в script-src разрешает скрипты откуда угодно, а значит политика даёт почти никакой реальной защиты и всё равно получит низкую оценку.
Забытые сторонние источники. Принуждение строгой политики без предварительного перечисления легитимных внешних сервисов, которыми вы пользуетесь (аналитика, шрифты, виджеты оплаты), может сломать части вашего же сайта — ровно поэтому и существует пробный шаг «только отчёт».
Установка только на главной странице. Политика должна покрывать каждую страницу, особенно оплаты, входа и аккаунта, — именно их стоит атаковать.
Считать её заменой замку. Политика безопасности контента и HTTPS/HSTS защищают разное. Вам нужны все они; одно не покрывает другое.

Частые вопросы

Я не технический специалист — смогу ли я справиться сам?

Вам не нужно разбираться в деталях. Это настройка, добавляемая тем, кто ведёт ваш сайт или хостинг, а на сервисах вроде Cloudflare она в основном с подсказками. Передайте им раздел «Как это исправить» ниже. Это бесплатно; единственная предосторожность — её стоит развернуть аккуратно, сначала в режиме наблюдения, чтобы случайно не заблокировать части вашего же сайта, что ровно и охватывают шаги.

У меня уже есть замок и SSL-сертификат — разве сайт не безопасен?

Замок защищает доставку вашей страницы; он не следит за тем, что выполняется внутри неё. Если на странице когда-нибудь окажется вредоносный код — через взломанный плагин, скомпрометированное объявление или внедрённое поле, — замок не помешает ему красть данные. Политика безопасности контента — слой, ограничивающий, чему вообще разрешено выполняться. Они защищают разное, и вам нужны обе.

Может ли её включение сломать мой сайт?

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

Мы уже поставили её в режим «только отчёт» — мы защищены?

Нет, и это самое частое ложное чувство безопасности. Режим «только отчёт» наблюдает и логирует, что было бы заблокировано, но не блокирует ничего — посетители получают ноль реальной защиты. Это лишь безопасный первый шаг. Наша проверка даёт режиму «только отчёт» малую долю зачёта настоящей политики и не запишет его как прохождение. Вы защищены, только когда переключитесь в режим принуждения.

Влияет ли это на нашу оценку или это лишь рекомендация?

Влияет на вашу оценку. Проверка политики безопасности контента оцениваемая и ценой до 25 баллов в категории веб-безопасности. Отсутствующая или слабая политика помечается как высокая серьёзность и тянет вашу оценку вниз — и это ровно тот пробел, о котором спрашивает анкета безопасности клиента.

Наш разработчик добавил политику, но оценка всё равно низкая — почему?

Политика может существовать и всё равно быть слабой. Самые частые виновники — лазейки вроде «unsafe-inline» и «unsafe-eval» для скриптов или подстановочные источники (голая *), которые снова открывают тот самый пробел, что политика призвана закрыть. Наша проверка читает политику директива за директивой и снижает оценку за эти слабости — политика, разрешающая что угодно, оценивается немногим лучше, чем её отсутствие. Исправление — ужесточить правила для скриптов, используя nonce или хэши вместо этих лазеек.