Как настроить Content Security Policy сайта по шагам

Content Security Policy ограничивает источники ресурсов страницы. Подготовьте правила, проверьте совместимость в режиме отчётов и затем включайте блокировку.

Что должно получиться

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

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

Начните на тестовой площадке с представительным набором сценариев. Для существующего проекта сначала узнайте, есть ли уже действующая политика на уровне приложения, сервера или промежуточного узла. Новое правило не обязательно заменит старое: несколько политик могут применяться одновременно.

Из чего это складывается

Как это сделать по шагам

1. Соберите действующие настройки. Проверьте заголовки HTML-документов и наличие политики в разметке. Выясните, какие уровни инфраструктуры добавляют правила. Сохраните исходное состояние до изменений.
2. Опишите нужные сценарии и ресурсы. Пройдите публичные страницы, вход, формы, редактор и другие важные части. Запишите, какие источники используются и для какой функции они нужны. Не копируйте весь список наблюдений в разрешения без разбора.
3. Составьте проект политики. Выберите директивы и допустимые источники по реальным потребностям. Отдельно продумайте встроенный код, динамические загрузки и правила, которые не относятся к обычной загрузке файлов.
4. Проверьте новую политику в режиме отчётов. Передайте её через Content-Security-Policy-Report-Only и настройте сбор нарушений. Этот режим не включает блокировку новой политикой, но не отменяет уже действующие ограничения.
5. Разберите сообщения и исправьте причины. Сопоставьте нарушение со сценарием и нужным ресурсом. Исправьте разметку, способ подключения или обоснованно уточните правило. Не расширяйте разрешения автоматически по каждому сообщению.
6. Включите проверенную блокирующую политику. После проверки сценариев примените согласованную настройку через Content-Security-Policy. Повторно проверьте фактический ответ и работу сайта, сохранив возможность возврата к предыдущей проверенной версии.
7. Поддерживайте результат. Включите проверку CSP в выпуск обновлений, особенно при добавлении компонентов и внешних ресурсов. Сохраняйте основание каждого существенного разрешения и отслеживайте новые нарушения.

Какие правила выбирать по задаче

Политика состоит из директив, разделённых точкой с запятой. У директив различаются назначение и синтаксис. Например, img-src относится к изображениям, script-src — к скриптам, style-src — к стилям, connect-src — к соответствующим соединениям из кода страницы.

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

Учебный фрагмент img-src 'self'; object-src 'none' показывает два разных ограничения: изображения с собственного источника и запрет соответствующих встроенных объектов. Это не готовая политика защиты всего сайта и не список разрешений для ваших скриптов. Полный набор строится по задачам конкретного приложения.

Значение 'self' связано с источником документа. Отдельный поддомен или внешний узел загрузки не следует считать автоматически тем же источником. Если файл действительно нужен с другого места, укажите это осознанно и проверьте назначение ресурса. Широкое разрешение всех источников может обесценить задуманное ограничение.

Зачем начинать с режима отчётов

Новая строгая политика может затронуть поведение, которое не видно на главной странице: появление диалога, отправку формы, просмотр встроенного материала или загрузку файла после действия пользователя. Режим отчётов помогает обнаружить такие случаи до включения блокировки именно этой политикой.

Для получения отчётов нужно настроить место их приёма. В современной схеме Reporting-Endpoints определяет адрес точки приёма, а report-to в политике выбирает её имя. Совместимость механизмов отчётности различается между браузерами; проверяйте её для используемой схемы. Один заголовок без рабочего приёма ещё не даёт вам наблюдаемый журнал нарушений.

Отчёты могут содержать адрес страницы и сведения о заблокированном ресурсе. Заранее определите подходящую точку приёма и состав собираемых данных. Не направляйте их в случайный внешний сервис только ради появления красивого списка. Сообщения браузера также полезно связывать с конкретным сценарием и временем проверки.

Content-Security-Policy-Report-Only передаётся HTTP-заголовком ответа. Размещение его как обычного meta в HTML не создаёт такой режим. Для некоторых блокирующих политик meta применяется с ограничениями, поэтому не считайте его полной заменой заголовка.

Как разобраться со встроенным кодом

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

Для разрешённых элементов script и style могут использоваться nonce или хеши. Nonce должен быть непредсказуемым и формироваться заново для каждого ответа с документом; значение в заголовке и нужном элементе должно совпадать. Его нельзя механически проставлять во все попавшие в страницу элементы, включая недоверенное содержимое.

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

Встроенные обработчики событий и другие способы выполнения тоже нужно разобрать отдельно. Разрешение конкретного script через nonce не следует трактовать как разрешение любого обработчика в атрибутах. Для существующей CMS составьте перечень используемых механизмов и выберите поддерживаемый способ их изменения.

Что учитывать при нескольких политиках

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

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

Устраните случайное дублирование настроек на понятном ответственном уровне, сохранив необходимые ограничения. После изменения смотрите фактический ответ документа снаружи. Настройка в одном файле не подтверждает, что другой слой инфраструктуры не добавил собственные правила.

Как проверить совместимость

• Откройте разные типы страниц, включая материалы со встроенными файлами и динамическими блоками.
• Проверьте вход, выход, отправку формы и понятное отображение ошибки.
• Пройдите действия, которые загружают ресурсы после первого открытия страницы.
• Сравните поведение в нужных браузерах и режимах авторизации.
• Убедитесь, что сообщения о нарушениях действительно приходят в выбранное место и относятся к текущей версии политики.
• После включения блокировки повторите те же сценарии и проверьте фактические заголовки.

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

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

• Копировать чужую политику без перечня собственных ресурсов и сценариев.
• Проверять только главную страницу и забывать действия после её загрузки.
• Разрешать всё, что попало в отчёт, не понимая назначения.
• Считать режим отчётов уже работающей блокировкой новой политики.
• Использовать постоянный nonce или добавлять его ко всему встроенному коду без разбора.
• Пытаться ослабить прежнее правило добавлением второго, не проверив совместное действие политик.

Для связанных задач пригодятся разбор CORS, ошибки в консоли браузера и проверка выпуска изменений. Задание на подготовку и проверку CSP можно разместить в разделе «Разработка», указав используемые компоненты и важные сценарии.

Целостность подключаемого файла дополнительно проверяет Subresource Integrity; согласуйте её с политикой загрузки ресурсов.

Вопросы и ответы

CSP полностью защищает сайт от внедрения кода?

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

Режим Report-Only блокирует ресурсы?

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

Можно ли настроить отчёты через meta?

Заголовок Content-Security-Policy-Report-Only не поддерживается внутри meta. Для отчётного режима нужна соответствующая доставка заголовка ответа и рабочая конфигурация приёма сообщений. Блокирующие варианты через meta тоже имеют ограничения.

Почему нельзя просто разрешить все источники?

Такое расширение может убрать смысл ограничения, ради которого вы вводите политику. Сначала определите нужный ресурс и его функцию. Исправляйте способ подключения или добавляйте обоснованное разрешение, затем повторно проверяйте сценарий.

Нужно ли менять nonce?

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

Чем CSP отличается от CORS?

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

Почему разрешающая новая политика не сняла запрет?

Может одновременно действовать другая блокирующая политика. Проверьте заголовки и настройки всех уровней доставки. Результат должен соответствовать применяемым ограничениям вместе; новая строка не служит автоматической заменой всех прежних правил.