Практическое руководство · безопасность

Заголовки безопасности сайта и CSP: проверка и внедрение

Практическая настройка CSP, HSTS, Referrer-Policy и защиты от встраивания с безопасным тестовым периодом.

CSP не заменяет экранирование пользовательского ввода и проверку доступа. HSTS с includeSubDomains и preload нельзя включать без аудита всех поддоменов.
Практический план

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

01. Снимите текущие ответы сервера

Этап проверки: снимите текущие ответы сервера.

  • Для главной, авторизации, личного кабинета и API зафиксируйте фактические заголовки успешных ответов и ошибок.
  • Составьте карту CDN, внешних шрифтов, платёжных iframe, аналитики и загрузок, от которых зависит работа страниц.
  • Разделите заголовки приложения, обратного прокси и CDN, чтобы исключить взаимное перезаписывание настроек.
  • Результат: понятна исходная политика и точки, где её реально можно изменить.

02. Настройте запрет ненужного встраивания

Этап проверки: настройте запрет ненужного встраивания.

  • Оцените необходимость iframe для кабинета, внешних виджетов и административной части сайта.
  • Применяйте директиву frame-ancestors в CSP для современных браузеров и проверяйте доступ допустимых партнёров.
  • Для локальных требований совместимости проверьте X-Frame-Options, не создавая противоречащих настроек.
  • Результат: чувствительные страницы нельзя бесконтрольно встраивать в посторонние сайты.

03. Вводите CSP через наблюдение

Этап проверки: вводите CSP через наблюдение.

  • Начните с Content-Security-Policy-Report-Only и собирайте нарушения без блокирования работы пользователей.
  • Просмотрите источники script-src, style-src, img-src, connect-src и случаи использования inline-кода на реальных маршрутах.
  • Заменяйте широкие разрешения точными источниками, nonce или hash там, где архитектура приложения это допускает.
  • Результат: политика соответствует фактическим зависимостям, а не случайному набору wildcard.

04. Проверьте HTTPS и передачу данных

Этап проверки: проверьте HTTPS и передачу данных.

  • Включайте HSTS только после проверки всего соответствующего HTTPS-контура и сроков сертификатов.
  • Настройте Referrer-Policy с учётом внешних переходов и потребности приложения передавать адрес источника.
  • Подберите разумные настройки Permissions-Policy и X-Content-Type-Options для поддерживаемых браузеров.
  • Результат: браузер ограничивает лишние полномочия без поломки прикладных сценариев.

05. Испытайте бизнес-критичные маршруты

Этап проверки: испытайте бизнес-критичные маршруты.

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

06. Поддерживайте политику при изменениях

Этап проверки: поддерживайте политику при изменениях.

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

Редакционный материал, октябрь 2026 года. Проверяйте применимость методов к вашей конфигурации и действующим требованиям.