HTTPS-скрипты: как правильно подключать JS и внешние ресурсы через HTTPS

Вы только что развернули сайт на HTTPS, гордо смотрите на зелёный замочек в браузере — и вдруг он пропадает. Или хуже: Chrome тихо блокирует половину скриптов, и вы час ищете, почему не работает jQuery. Причина почти всегда одна: где-то в коде затесался http:// вместо https://.

Содержание: показать

Подключение внешних скриптов через HTTPS — это не просто «добавьте букву s». Это целый пласт вопросов: mixed content, Subresource Integrity, Content Security Policy, доверенные источники. В этой статье разберём всё по порядку: от базового script src https до защиты от вредоносных CDN и XSS-атак.

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

Что такое HTTPS-скрипты

HTTPS-скрипт — это любой JavaScript-файл или внешний ресурс, загружаемый по протоколу HTTPS (HyperText Transfer Protocol Secure). В отличие от обычного HTTP, HTTPS шифрует трафик между сервером и браузером с помощью TLS, что исключает перехват и подмену данных в пути.

Разница между HTTP и HTTPS для скриптов критична:

HTTP: данные передаются в открытом виде. Любой, кто находится между сервером и клиентом (провайдер, точка доступа Wi-Fi, промежуточный прокси), может прочитать или модифицировать содержимое файла.
HTTPS: трафик зашифрован. Перехватить и подменить содержимое скрипта без обнаружения невозможно.

Когда браузер загружает страницу по HTTPS, он ожидает, что все ресурсы на ней тоже загружаются по HTTPS. Это называется принципом безопасного контекста. Нарушение этого принципа ведёт к проблемам с mixed content — о них ниже.

Зачем это важно практически? Представьте: ваш сайт подключает jQuery с http://cdn.example.com/jquery.js. Злоумышленник на уровне сети подменяет этот файл — и в него внедряется код, крадущий данные форм. Пользователь ничего не замечает, ваш сервер чист, но данные утекают. Это не теоретическая угроза — атаки типа MITM (Man-in-the-Middle) реальны и задокументированы.

Почему нельзя использовать HTTP-скрипты на HTTPS-сайте

Mixed content — это ситуация, когда страница загружена по HTTPS, но часть ресурсов (скрипты, стили, изображения) запрашивается по HTTP. Браузеры реагируют на это по-разному в зависимости от типа ресурса.

Для скриптов и стилей — активный mixed content — современные браузеры блокируют загрузку полностью и без предупреждения пользователю. Вы просто получаете ошибку в консоли:

Mixed Content: The page at 'https://yoursite.com' was loaded over HTTPS,
but requested an insecure script 'http://cdn.example.com/jquery.js'.
This request has been blocked; the content must be served over HTTPS.

Три главные угрозы HTTP-скриптов:

MITM-атака (Man-in-the-Middle). Атакующий перехватывает HTTP-трафик и подменяет содержимое скрипта на вредоносный код. Особенно актуально в публичных Wi-Fi сетях.
Атака на цепочку поставок (Supply Chain Attack). Если CDN, с которого вы грузите скрипт по HTTP, взломан — все сайты, использующие его, автоматически раздают малварь.
SEO и доверие. Google понижает в выдаче сайты с mixed content. Браузеры показывают предупреждение «Небезопасно» вместо замочка. Конверсия падает.

Как подключить JS через HTTPS

Базовый синтаксис подключения внешнего скрипта через HTTPS — это тег <script> с атрибутом src, указывающим на HTTPS-ресурс. Это и есть то, что называют script src https в контексте веб-разработки:

<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%20src%3D%22https%3A%2F%2Fcdn.example.com%2Fscript.js%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />

Казалось бы, всё просто. Но есть нюансы, которые регулярно вызывают проблемы.

Протокол-независимые URL (устаревший подход)

<!-- Не делайте так — это устаревший паттерн -->
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%20src%3D%22%2F%2Fcdn.example.com%2Fscript.js%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />

Когда-то это был «умный» способ: браузер подставлял протокол страницы. Но сегодня, когда HTTP постепенно исчезает, явный https:// предпочтительнее — он устраняет любую двусмысленность.

CDN как источник скриптов

Content Delivery Network (CDN) — это сеть серверов по всему миру, которая отдаёт статические файлы ближайшего к пользователю узла. Использовать CDN для публичных библиотек — нормальная практика, но только с HTTPS и проверкой целостности.

Доверенные публичные CDN для JS-библиотек:

cdnjs.cloudflare.com — Cloudflare CDN
cdn.jsdelivr.net — популярный open-source CDN
unpkg.com — npm-пакеты через CDN
code.jquery.com — официальный jQuery CDN

Правило: доверяйте только официальным CDN самих библиотек или известным провайдерам. Никаких «скачал и залил на свой сервер» для внешних зависимостей.

HTTPS link script: подключение внешних библиотек

Подключение внешних библиотек через https link script — повседневная задача frontend-разработчика. Вот правильные примеры для самых популярных библиотек.

jQuery

<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%0A%20%20src%3D%22https%3A%2F%2Fcode.jquery.com%2Fjquery-3.7.1.min.js%22%0A%20%20integrity%3D%22sha256-%2FJqT3SQfawRcv%2FBIHPThkBvs0OEvtFFmqPF%2FlYI%2FCxo%3D%22%0A%20%20crossorigin%3D%22anonymous%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />

Bootstrap (CSS + JS)

<!-- CSS -->
<link
  href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css"
  rel="stylesheet"
  integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN"
  crossorigin="anonymous">

<!-- JS -->
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%0A%20%20src%3D%22https%3A%2F%2Fcdn.jsdelivr.net%2Fnpm%2Fbootstrap%405.3.2%2Fdist%2Fjs%2Fbootstrap.bundle.min.js%22%0A%20%20integrity%3D%22sha384-C6RzsynM9kWDrMNeT87bh95OGNyZPhcTNXj1NW7RuBCsyN%2Fo0jlpcV8Qyq46cDfL%22%0A%20%20crossorigin%3D%22anonymous%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />

Alpine.js

<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%0A%20%20defer%0A%20%20src%3D%22https%3A%2F%2Fcdn.jsdelivr.net%2Fnpm%2Falpinejs%403.x.x%2Fdist%2Fcdn.min.js%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />

Обратите внимание на атрибуты integrity и crossorigin в примерах с jQuery и Bootstrap — это Subresource Integrity, о котором поговорим в следующем разделе.

Проверка безопасности скриптов: Subresource Integrity (SRI)

SRI (Subresource Integrity) — механизм безопасности, позволяющий браузеру проверить, что загруженный файл не был изменён. Работает на основе криптографического хеша: вы указываете ожидаемый хеш файла, браузер вычисляет хеш загруженного файла и сравнивает. Если не совпадает — файл не выполняется.

<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%0A%20%20src%3D%22https%3A%2F%2Fcdn.example.com%2Fscript.js%22%0A%20%20integrity%3D%22sha384-oqVuAfXRKap7fdgcCY5uykM6%2BR9GqQ8K%2Fuxy9rx7HNQlGYl1kPzQho1wx4JwY8wC%22%0A%20%20crossorigin%3D%22anonymous%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />

Атрибуты:

integrity — алгоритм хеширования и хеш в формате алгоритм-base64hash. Поддерживаются sha256, sha384, sha512.
crossorigin="anonymous" — обязателен при использовании SRI для кросс-доменных ресурсов. Без него браузер не сможет проверить хеш.

Как получить SRI-хеш

# Вариант 1: через openssl
curl -s https://cdn.example.com/script.js | \
  openssl dgst -sha384 -binary | \
  openssl base64 -A

# Вариант 2: через онлайн-инструмент
# https://www.srihash.org/

Большинство крупных CDN (cdnjs, jsdelivr) показывают SRI-хеши прямо в интерфейсе при копировании тега подключения. Всегда используйте их.

Таблица безопасности способов подключения скриптов:

Тип подключения	Безопасность	Защита от MITM	Защита от компрометации CDN
HTTP	❌ Опасно	❌ Нет	❌ Нет
HTTPS без SRI	⚠️ Базовая	✅ Да	❌ Нет
HTTPS + SRI	✅ Хорошая	✅ Да	✅ Да
Self-hosted + HTTPS + CSP	✅✅ Отличная	✅ Да	✅ Да (нет внешних зависимостей)

HTTPS-скрипты в Lua: пример для OpenResty и Nginx

Тема https script lua актуальна для тех, кто использует OpenResty (Nginx + LuaJIT) для серверной логики — например, для валидации токенов, обращения к внешним API прямо из конфига Nginx или реализации rate limiting.

Для HTTPS-запросов из Lua используется модуль lua-resty-http:

-- Установка через opm
opm get ledgetech/lua-resty-http

Пример HTTPS-запроса к внешнему API из Nginx/OpenResty:

location /api/check {
    content_by_lua_block {
        local http = require "resty.http"
        local httpc = http.new()

        -- Важно: установить таймауты
        httpc:set_timeouts(2000, 5000, 5000)

        local res, err = httpc:request_uri("https://api.example.com/validate", {
            method = "GET",
            headers = {
                ["Authorization"] = "Bearer " .. ngx.var.arg_token,
                ["Content-Type"] = "application/json",
            },
            ssl_verify = true  -- Проверка SSL-сертификата — всегда true!
        })

        if not res then
            ngx.status = 502
            ngx.say("Backend error: " .. (err or "unknown"))
            return
        end

        ngx.status = res.status
        ngx.say(res.body)
    }
}

Критический момент: параметр ssl_verify = true обязателен. Если поставить false — вы отключаете проверку сертификата, и смысл HTTPS теряется. В production никогда не отключайте SSL verify, даже если это кажется удобным решением для локальной отладки.

Для работы SSL verify в OpenResty нужно указать путь к CA-сертификатам:

# В nginx.conf
lua_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
lua_ssl_verify_depth 5;

Типичные ошибки при работе с HTTPS-скриптами

Ошибка 1: HTTP внутри HTTPS-страницы (Mixed Content)

<!-- Неправильно -->
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%20src%3D%22http%3A%2F%2Fcdn.example.com%2Fjquery.min.js%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />

<!-- Правильно -->
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%20src%3D%22https%3A%2F%2Fcdn.example.com%2Fjquery.min.js%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />

Как найти все HTTP-ресурсы на сайте:

# Поиск по исходникам проекта
grep -r "src=\"http://" ./src/
grep -r "href=\"http://" ./src/

# Через браузер: DevTools → Console → фильтр "Mixed Content"
# Через онлайн-инструменты: https://www.whynopadlock.com/

Ошибка 2: Самоподписанные сертификаты на CDN

Использование собственного сервера с самоподписанным сертификатом для раздачи скриптов — распространённая ошибка в корпоративных сетях. Браузер покажет предупреждение или заблокирует ресурс. Решение: настройте нормальный сертификат (Let’s Encrypt) или используйте публичный CDN.

Ошибка 3: Hardcoded HTTP в шаблонах CMS

WordPress, Joomla и другие CMS иногда хранят URL ресурсов в базе данных с http://. После переезда на HTTPS ссылки остаются HTTP:

# WordPress: исправить в базе данных
UPDATE wp_options SET option_value = REPLACE(option_value, 'http://yoursite.com', 'https://yoursite.com');
UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://yoursite.com', 'https://yoursite.com');

# Или через плагин Better Search Replace

Ошибка 4: Неправильный путь src

<!-- Ошибка: двойной слеш или опечатка в домене -->
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%20src%3D%22https%3A%2F%2Fcdn.example.com%2F%2Fscript.js%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%20src%3D%22https%3A%2F%2F%D1%81dn.example.com%2Fscript.js%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />  <!-- кириллическая с! -->

<!-- Всегда проверяйте: открывайте URL отдельно в браузере -->

Опасные источники скриптов

HTTPS — необходимое, но недостаточное условие безопасности. Скрипт может быть загружен по HTTPS, но при этом быть вредоносным. Разберём реальные риски.

Сторонние сайты с неизвестной репутацией. Встречаются советы подключить скрипт с малоизвестных ресурсов. Например, запросы вида https scriptblox com script или https scripts com в поисковиках часто ведут к сомнительным репозиториям скриптов для игр, чит-программам или сервисам автоматизации. Подключать подобное на production-сайт категорически нельзя — вы отдаёте чужому коду полный доступ к DOM вашей страницы, данным пользователей и cookies.

XSS через сторонние скрипты. Если ваш сайт подключает скрипт с домена, который вам не принадлежит — владелец этого домена (или хакер, взломавший его) может в любой момент добавить в скрипт вредоносный код. Это называется атакой на цепочку поставок. Известные примеры: взлом Polyfill.io в 2024 году затронул тысячи сайтов.

Правила работы с внешними скриптами:

Подключайте скрипты только с официальных источников (сайт самой библиотеки, крупный известный CDN).
Для критически важных сайтов — загружайте библиотеки к себе и раздавайте со своего сервера.
Всегда используйте SRI-хеши для внешних ресурсов.
Регулярно проверяйте список внешних зависимостей — особенно в легаси-проектах.
Не доверяйте «быстрым решениям» из малоизвестных источников, даже если они работают по HTTPS.

Best Practices: чеклист безопасного подключения скриптов

Только HTTPS. Абсолютно все внешние ресурсы — только через HTTPS. Без исключений.
SRI для внешних библиотек. Добавляйте атрибуты integrity и crossorigin для всех скриптов с внешних CDN.
Content Security Policy. Настройте CSP-заголовок — он ограничивает, откуда браузер может загружать скрипты.
Минимизируйте внешние зависимости. Каждая внешняя зависимость — потенциальная точка атаки. Нужен ли вам весь Bootstrap ради одного компонента?
Self-hosting для критических скриптов. Платёжные формы, авторизация — никаких внешних CDN. Только свой сервер.
Аудит зависимостей. Регулярно проверяйте список подключённых скриптов. Удаляйте неиспользуемые.
Мониторинг Mixed Content. Настройте автоматическую проверку — например, через Mozilla Observatory.

Content Security Policy (CSP): контроль источников скриптов

CSP — это HTTP-заголовок, который говорит браузеру, откуда разрешено загружать ресурсы. Это мощный инструмент защиты от XSS и несанкционированных скриптов.

Базовый пример в заголовке Nginx:

add_header Content-Security-Policy "script-src 'self' https://trusted.cdn.com https://code.jquery.com" always;

В HTML через мета-тег (менее предпочтительно, но работает):

<meta http-equiv="Content-Security-Policy"
  content="script-src 'self' https://cdn.jsdelivr.net https://code.jquery.com">

Основные директивы CSP для скриптов

# Только свои скрипты + доверенные CDN
Content-Security-Policy: script-src 'self' https://cdn.jsdelivr.net

# Разрешить inline-скрипты (менее безопасно, но иногда нужно)
Content-Security-Policy: script-src 'self' 'unsafe-inline'

# Использовать nonce для inline-скриптов (лучший вариант)
Content-Security-Policy: script-src 'self' 'nonce-СЛУЧАЙНОЕ_ЗНАЧЕНИЕ'
# В HTML:
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%20nonce%3D%22%D0%A1%D0%9B%D0%A3%D0%A7%D0%90%D0%99%D0%9D%D0%9E%D0%95_%D0%97%D0%9D%D0%90%D0%A7%D0%95%D0%9D%D0%98%D0%95%22%3E%2F*%20%D0%BA%D0%BE%D0%B4%20*%2F%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />

# Полная политика для production
Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.jsdelivr.net https://code.jquery.com;
  style-src 'self' https://cdn.jsdelivr.net;
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://api.yoursite.com;
  frame-ancestors 'none';

Режим Report-Only для тестирования

Прежде чем включать CSP в боевом режиме — используйте Content-Security-Policy-Report-Only. Он не блокирует ресурсы, а только логирует нарушения:

Content-Security-Policy-Report-Only: script-src 'self' https://cdn.jsdelivr.net;
  report-uri /csp-report-endpoint

Так вы увидите все скрипты, которые нарушат политику, не сломав сайт.

FAQ

Можно ли использовать HTTP-скрипты на HTTPS-сайте?

Нет. Современные браузеры (Chrome, Firefox, Safari, Edge) блокируют активный mixed content — то есть HTTP-скрипты и стили на HTTPS-страницах. Ресурс просто не загрузится, и вы получите ошибку в консоли. Даже если в каком-то старом браузере скрипт загрузится — это дыра в безопасности, которую нельзя оставлять.

Как проверить безопасность подключённого скрипта?

# 1. Проверить SRI-хеш вручную
curl -s https://cdn.example.com/script.js | openssl dgst -sha384 -binary | openssl base64 -A

# 2. Сканировать сайт через Mozilla Observatory
# https://observatory.mozilla.org/

# 3. Проверить CSP и Mixed Content через Chrome DevTools
# F12 → Console → фильтр "Security"

# 4. Проверить через SSL Labs
# https://www.ssllabs.com/ssltest/

Что делать, если CDN недоступен?

Это классическая проблема зависимости от внешних ресурсов. Три стратегии:

Self-hosting как основной вариант. Для критических библиотек — скачайте и раздавайте со своего сервера. Никакой внешней зависимости.
Fallback в HTML. Подключите скрипт с CDN, и добавьте fallback на случай недоступности:

<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%20src%3D%22https%3A%2F%2Fcdn.jsdelivr.net%2Fnpm%2Fjquery%403.7.1%2Fdist%2Fjquery.min.js%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%3E%0A%20%20if%20(typeof%20jQuery%20%3D%3D%3D%20'undefined')%20%7B%0A%20%20%20%20document.write('%3Cscript%20src%3D%22%2Flocal%2Fjquery.min.js%22%3E%3C%5C%2Fscript%3E')%3B%0A%20%20%7D%0A%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object mce-object-script" width="20" height="20" alt="&lt;script&gt;" />

Service Worker. Для PWA и современных приложений — кэшируйте внешние ресурсы через Service Worker.

Что такое js script script src https в контексте безопасности?

Это просто обозначение подключения JavaScript-файла через тег <script> с атрибутом src, указывающим на HTTPS-ресурс. Стандартная практика подключения внешних библиотек. Ключевое требование — протокол должен быть именно https://, а не http://.

Заключение

HTTPS для скриптов — это не опция, это стандарт. Смешение HTTP-ресурсов на HTTPS-страницах блокируется браузерами, снижает доверие пользователей и открывает векторы для атак. Несколько минут на проверку каждого script src в проекте — это разумная инвестиция в безопасность.

Резюмируем главные правила:

Все скрипты и стили — только через HTTPS.
Внешние библиотеки — с SRI-хешами (integrity + crossorigin).
Контроль источников — через Content Security Policy.
Критический код — self-hosted, не с чужих CDN.
Неизвестные источники скриптов — не доверять, даже если они работают по HTTPS.

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

Проверьте свой проект прямо сейчас — откройте DevTools, вкладку Console, отфильтруйте по «Mixed Content». Если пусто — отлично. Если нет — теперь вы знаете, что делать.

Пишите в комментарии вопросы по CSP и SRI — это тема, где дьявол в деталях, и типичных кейсов хватит на отдельную статью.

Author: Георгий Креативный

Оставайтесь на связи

Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.

Подписаться на IT-Аптеку →

Поделитесь: