Mixed content: как найти HTTP-ресурсы на HTTPS-странице

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

Проблема часто появляется после переезда сайта на HTTPS, подключения старого шаблона, вставки внешнего виджета или восстановления базы из резервной копии. В адресной строке при этом может отображаться защищённое соединение, но отдельные функции страницы перестают работать, а в консоли возникают сообщения Mixed Content.

Что именно происходит

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

Поведение зависит от типа ресурса. Для части пассивного контента браузер может попытаться заменить схему http:// на https://. Такой автоматический переход не означает, что источник исправлен: сервер может не поддерживать HTTPS, возвращать ошибку или отдавать другой файл. Активный контент, способный изменить страницу, обычно блокируется.

Диагностический алгоритм

1. Воспроизведите проблему в чистой сессии

Откройте страницу в приватном окне актуального браузера. Это уменьшает влияние кэша, расширений и ранее зарегистрированного service worker. Проверьте не только главную страницу, но и шаблоны, где подключаются отдельные компоненты: карточку товара, форму, статью, страницу поиска.

2. Изучите сообщения Console

Откройте инструменты разработчика, перейдите в Console и перезагрузите страницу. Браузер обычно показывает URL HTTPS-документа, небезопасный HTTP-адрес и результат: запрос заблокирован либо автоматически обновлён. Скопируйте полный URL и название инициатора запроса.

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

3. Подтвердите запрос во вкладке Network

Включите сохранение журнала, очистите список и обновите страницу. Найдите ресурс по имени или домену. Полезно проверить:

• исходный и конечный URL с учётом перенаправлений;
• статус ответа и тип ресурса;
• поле Initiator — файл или участок разметки, создавший запрос;
• был ли URL автоматически преобразован браузером в HTTPS;
• возвращает ли HTTPS-версия ожидаемый контент, а не страницу ошибки.

4. Найдите источник адреса

Поиск строки http:// в исходном HTML — только начало. Адрес может находиться в CSS, JavaScript, JSON-конфигурации, атрибутах srcset, inline-стилях, данных CMS, шаблоне виджета или ответе API. Смотрите Initiator и цепочку вызовов: они точнее указывают место появления запроса.

Не каждый HTTP-адрес в коде создаёт mixed content. Например, ссылка <a href="http://example.com"> обычно ведёт на другую страницу и не загружает подресурс в текущий документ. Диагноз должен опираться на реальный сетевой запрос.

5. Проверьте HTTPS-источник до замены

Откройте предполагаемый HTTPS-URL отдельно и убедитесь, что сервер отвечает без циклических редиректов и возвращает правильный файл. Простая массовая замена http:// на https:// опасна: внешний хост может не поддерживать TLS, а пути и версии файлов могут различаться.

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

6. Повторите проверку после изменения

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

Проверяемые критерии исправления

1. В Console после полной перезагрузки нет сообщений Mixed Content.
2. Network не содержит HTTP-запросов подресурсов, инициированных HTTPS-страницей.
3. Нет ресурсов, которые работают только благодаря автоматическому обновлению схемы браузером.
4. Все новые HTTPS-URL отвечают ожидаемым статусом и MIME-типом.
5. Скрипты, стили, формы, шрифты, изображения и встроенные блоки работают после замены.
6. Проверены разные шаблоны страниц и состояния, а не только один URL.

Типовые ошибки

Исправление только видимой разметки

HTTP-адрес удаляют из HTML, но оставляют его в подключаемом CSS, динамическом JavaScript или данных CMS. Браузер продолжает создавать небезопасный запрос после загрузки страницы или действия пользователя.

Надежда на редирект

Перенаправление с HTTP на HTTPS не всегда спасает ситуацию: браузер может заблокировать запрос до получения редиректа. В разметке следует сразу указывать конечный защищённый URL.

Использование относительной схемы

Запись //cdn.example.com/file.js наследует схему документа и обычно работает на HTTPS, но скрывает явное требование к защищённому источнику. Для внешних ресурсов понятнее указывать полный https://-адрес, а для ресурсов того же сайта — корневой относительный путь вроде /assets/app.js.

Маскировка предупреждений политикой CSP

Директива upgrade-insecure-requests может заставить браузер обновлять HTTP-запросы до HTTPS. Это полезный дополнительный барьер, но не замена исправлению исходных URL. Она не создаёт поддержку HTTPS на внешнем сервере и может превратить предупреждение в ошибку загрузки.

Границы метода

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

Отсутствие mixed content также не подтверждает корректность SSL-сертификата, безопасность JavaScript, правильность CSP или остальных заголовков. Это самостоятельные области диагностики. Для системного контроля полезно сочетать ручную проверку браузером с обходом набора публичных URL.

Итог

Рабочая диагностика строится вокруг фактических запросов: воспроизвести страницу, прочитать Console, подтвердить ресурс в Network, найти инициатор, проверить HTTPS-источник и повторно протестировать разные сценарии. Цель — не спрятать предупреждение, а исключить загрузку подресурсов по незащищённому HTTP.

Дополнительные практические материалы собраны в блоге SiteVisor. Для первичного обзора публичной страницы можно использовать проверку без доступа к CMS.