Что проверить, если ERR_BLOCKED_BY_RESPONSE появляется только у iframe?

Посмотрите Console и заголовки ответа встраиваемого документа: X-Frame-Options и Content-Security-Policy с директивой frame-ancestors. Эти ограничения относятся к разрешению встраивания; добавление Access-Control-Allow-Origin само по себе их не отменяет. Если чужой сайт намеренно запрещает iframe, используйте обычную ссылку или согласованную интеграцию, а не отключайте защиту браузера.

Можно ли исправить ошибку, добавив mode: no-cors в fetch?

Это не универсальное исправление. При успешном cross-origin запросе в режиме no-cors JavaScript получает непрозрачный ответ и не может прочитать его тело. При этом CORP и COEP всё ещё могут блокировать ресурс. Для чтения данных через fetch согласуйте CORS на сервере и режим запроса; не заменяйте настройку доступа обходом проверки.

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

ERR_BLOCKED_BY_RESPONSE: что делать владельцу сайта

Пошаговая диагностика ERR_BLOCKED_BY_RESPONSE: как найти заблокированный ресурс, проверить политики браузера и исправить заголовки без ослабления защиты.

Ошибка ERR_BLOCKED_BY_RESPONSE означает, что Chromium заблокировал использование ответа из-за невыполненных требований безопасности. Для внешнего ресурса проверьте CORP/COEP и режим запроса; для iframe — также X-Frame-Options и CSP frame-ancestors. Точную причину ищите в Console или Issues: один код ошибки не определяет, какой заголовок нужно исправить.

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

Что именно заблокировал браузер

Это не HTTP-статус вроде 404 или 502. Основной документ может открыться с кодом 200, а браузер отдельно заблокирует скрипт, изображение, шрифт, iframe или другой ресурс. В результате страница выглядит сломанной, хотя сервер формально отвечает.

В Chrome или Chromium откройте DevTools → Network, включите сохранение журнала и перезагрузите страницу. Найдите красный запрос и зафиксируйте:

полный Request URL без токенов и других секретов;
тип ресурса и колонку Initiator;
адрес страницы, которая начала запрос;
HTTP-статус, редиректы и Content-Type;
уточнение ошибки в Console или Issues.

Формулировки наподобие CorpNotSameOrigin, CorpNotSameSite или AfterDefaultedToSameOriginByCoep сразу указывают на CORP/COEP. Ошибка ERR_BLOCKED_BY_CLIENT обычно относится к расширению или фильтру и требует другой диагностики.

Проверьте происхождение страницы и ресурса

Для браузера origin — это сочетание схемы, имени хоста и порта. Поэтому https://site.example и https://cdn.site.example принадлежат разным origin, хотя домены выглядят связанными. Переход с HTTPS на HTTP или нестандартный порт тоже меняет origin.

Сначала ответьте на два вопроса: ресурс действительно должен загружаться с другого origin и он публичный? Если нет, исправьте URL, схему, порт или ошибочный редирект. Если да, разрешение следует настраивать на сервере ресурса с учётом способа загрузки.

Проверьте итоговый ответ, включая цепочку перенаправлений:

curl -I -L https://cdn.example.org/assets/app.js

Смотрите на Location, Content-Type, Cross-Origin-Resource-Policy и Access-Control-Allow-Origin в ответе ресурса, а Cross-Origin-Embedder-Policy — в ответе основного документа. Команда с -I отправляет HEAD и не получает тело: при расхождении с браузером сравните GET, как показано в проверке файла с CDN. Полученный curl ответ характеризует только этот запрос и не подтверждает, что браузер разрешит странице использовать ресурс.

Разберите CORP, COEP и CORS по ролям

CORP ограничивает встраивание ресурса

Заголовок ответа Cross-Origin-Resource-Policy ограничивает использование ресурса при запросах no-cors: только с того же origin, с того же site или с любых origin. Если публичный файл CDN отдаётся с same-origin, браузер заблокирует его использование страницей с другого origin в режиме no-cors. Успешный CORS-запрос — отдельная ветка проверки.

Не меняйте значение на cross-origin автоматически. Оно уместно для действительно публичных ресурсов, но не для личных кабинетов, закрытых API и ответов с данными пользователя.

COEP задаёт правило для документа

Если основной документ отдаёт Cross-Origin-Embedder-Policy: require-corp, внешние ресурсы в режиме no-cors должны явно разрешить встраивание через CORP. Альтернативой может быть CORS-режим запроса, если сервер ресурса корректно разрешает нужный origin.

Перед включением строгой политики полезно проверить все CDN, iframe, виджеты, шрифты и сторонние скрипты через Report-Only. Простое удаление COEP способно скрыть симптом, но одновременно отменить задуманную изоляцию страницы.

CORS решает другую задачу

CORS позволяет серверу сообщить, каким origin разрешено читать ответ при CORS-запросе. CORP, напротив, ограничивает использование ответов для запросов no-cors. Поэтому добавление одного Access-Control-Allow-Origin не всегда исправляет конфликт COEP/CORP, а безусловный wildcard может расширить доступ сильнее, чем требуется.

Если явного указания на CORP/COEP нет, сверьте полный текст ошибки и проверьте MIME-тип и тело ответа. URL скрипта или изображения после редиректа может возвращать HTML-страницу входа либо страницу ошибки. Не смешивайте коды: в списке ошибок Chromium блокировка CORB/ORB обозначена отдельно — ERR_BLOCKED_BY_ORB.

Как исправить ошибку без ослабления защиты

Выберите ветку, которая совпадает с назначением ресурса:

Ресурс должен быть локальным. Верните загрузку на тот же origin и устраните подмену хоста в шаблоне, сборке, reverse proxy или CDN.
Публичная статика должна работать с CDN. Настройте подходящий CORP либо CORS и атрибут crossorigin для конкретного типа загрузки. Проверьте, что правило применяется к итоговому ответу, а не только к первому редиректу.
После включения COEP пропали внешние ресурсы. Составьте список зависимостей и по очереди получите разрешение от каждого их сервера. Если поставщик не поддерживает нужную политику, замените интеграцию или осознанно пересмотрите режим изоляции.
Вместо файла приходит HTML. Исправьте маршрут, авторизацию, редирект и Content-Type; не маскируйте HTML-ошибку заголовком JavaScript или изображения.
Заголовки меняет CDN или proxy. Сравните ответ origin-сервера и публичного адреса, затем уберите дублирующее или более строгое правило в том слое, который его добавляет.

Если страница после CDN загружает только часть CSS, JS или изображений, используйте отдельный чеклист неполной загрузки. Для одного проблемного файла пригодится проверка ресурса через браузер и curl.

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

Откройте Network с отключённым кэшем, выполните полную перезагрузку и убедитесь, что запрос больше не помечен как blocked. Проверьте итоговый URL, ожидаемый Content-Type и фактическое появление ресурса на странице.

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

Внешний мониторинг Web-Puls может регулярно подтверждать, что публичный URL отвечает, и предупредить о его недоступности. Но он не заменяет браузерную проверку CORP/COEP на конкретной странице: финальная приёмка должна включать DevTools и реальный пользовательский сценарий.

Когда передать проблему специалисту

Помощь полезна, если заголовки одновременно формируют приложение, веб-сервер и CDN или ошибка появилась после изменения политики безопасности. Подготовьте адрес страницы и ресурса, время проверки, цепочку редиректов и заголовки ответа; значения Cookie, Authorization и токены удалите.

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