Мониторинг сайтов · 5 мин · обновлено 2026-11-02

CSP connect-src блокирует запрос: как отличить политику от сбоя API

API отвечает отдельно, но страница не получает данные? Проверяем connect-src, источник политики и конфликт заголовков, затем подтверждаем исправление в браузере.

Если Console сообщает, что действующая CSP connect-src заблокировала запрос, браузер запрещает странице соединение с указанным адресом. Начните с политики документа, запускающего запрос: успешный ответ API через curl не отменяет этот запрет и сам по себе не доказывает исправность интерфейса.

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

1. Подтвердите, что блокирует именно connect-src

Откройте DevTools до воспроизведения сбоя: в Network включите сохранение журнала, затем повторите безопасное действие, например загрузку каталога. В Console найдите сообщение с адресом и директивой connect-src; одного Failed to fetch недостаточно.

Сохраните для разбора:

URL страницы и запроса без секретных параметров;
время, браузер и действие, после которого появилась ошибка;
название нарушенной директивы и текст политики;
Initiator — какой скрипт начал запрос;
наличие HTTP-ответа и перенаправлений в Network.

При запрете до отправки сервер не получит основной запрос. Однако отсутствие строки в access log ещё не доказывает CSP: сначала проверьте правильность журнала и сопоставьте событие с Console.

connect-src управляет, в частности, fetch, XMLHttpRequest, WebSocket и EventSource. Если директивы нет, используется default-src, поэтому запрет возможен и без слова connect-src в заголовке. Это поведение описано в справочнике MDN.

2. Найдите политику страницы, а не только ответ API

В Network выберите HTML-документ, из которого выполняется запрос, и посмотрите Response Headers → Content-Security-Policy. Для кода внутри iframe проверяйте его документ. Также проверьте HTML на meta http-equiv="Content-Security-Policy".

Report-Only не блокирует запрос

Content-Security-Policy-Report-Only сообщает о нарушениях, но сам не запрещает соединение. Если видите только такое предупреждение, ищите действующую CSP или другую причину сбоя; обычный CSP и Report-Only могут присутствовать одновременно. MDN объясняет различие режимов.

Второй заголовок не расширяет первый

Приложение, веб-сервер и CDN могут добавлять отдельные политики. Браузер применяет их совместно: запрос должен пройти каждую действующую политику, включая заданную через meta. Например, дополнительное разрешение API не поможет, пока другая политика содержит connect-src 'none'. Это разобрано в разделе спецификации CSP о нескольких политиках.

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

3. Сверьте адрес и внесите узкое исправление

Предположим, страница https://shop.example обращается к https://api.shop.example/catalog. Для connect-src 'self' это другой origin: различаются имена хостов. Схема и порт также имеют значение.

Сначала проверьте, нужен ли этот адрес. Ошибка сборки может подставить тестовый API, старый домен или неправильный порт; разрешать такой URL в политике не следует.

Если внешний API действительно предусмотрен архитектурой, фрагмент существующей политики может выглядеть так:

connect-src 'self' https://api.shop.example;

Это учебный пример для указанной пары адресов, а не замена всей CSP. Сохраните остальные директивы, а в список соединений добавьте только проверенный источник; не расширяйте default-src ради одного запроса и не ставьте * вместо разбора.

Если запрос перенаправляется, изучите конечный адрес и причину редиректа. Для WebSocket проверьте точный wss://-адрес: не рассчитывайте, что 'self' одинаково разрешит его во всех браузерах. Отключение защиты браузера не подходит для проверки исправления у посетителей.

4. Отделите следующую ошибку от прежней

После устранения CSP-запрета может проявиться другая проблема:

Ошибка CORS или отказ OPTIONS. Проверьте разрешение origin, метода и заголовков на стороне API. Добавление Access-Control-Allow-Origin не меняет CSP страницы.
HTTP 401, 403 или 5xx. У запроса появился ответ; исследуйте авторизацию, права либо серверную ошибку по его содержимому и логам.
DNS, TLS или тайм-аут. Проверяйте сетевое соединение с конкретным адресом.
CORP/COEP в Console. Это отдельные ограничения использования ответа; пригодится разбор ERR_BLOCKED_BY_RESPONSE.

Сравнение с curl полезно как независимая проверка доступности, но curl не выполняет политику загруженной страницы. Не переносите в диагностические команды чужие Cookie и Authorization и не повторяйте оплату или создание заказа ради теста.

5. Примите исправление по результату в браузере

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

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

Web-Puls помогает отдельно контролировать доступность публичного URL, но HTTP-мониторинг не заменяет браузерную проверку CSP. Границы таких проверок разобраны в руководстве по мониторингу API.

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