Почему CORS не блокирует скрипт с CDNJS?

Почему CORS не блокирует загрузку скриптов с CDNJS

Проблема CORS (Cross-Origin Resource Sharing) возникает при выполнении междоменных HTTP-запросов через браузерные API (например, fetch() или XMLHttpRequest). Однако загрузка <script> тегов с внешних ресурсов, таких как CDNJS, работает без CORS-ошибок благодаря фундаментальному различию в механизмах безопасности браузеров.

Ключевое различие: "Same-Origin Policy" для скриптов и CORS

1. Поведение тега <script>

Тег <script src="..."> является одним из исключений политики Same-Origin Policy (SOP). Его основное назначение — загружать и выполнять код JavaScript с любых доменов. Это исторически необходимо для использования общедоступных библиотек (jQuery, React, Vue) и виджетов (социальные кнопки, карты).

<!-- Этот скрипт загрузится и выполнится без CORS-проверок -->
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>

2. Как работает CORS для скриптов?

CORS активируется только при:

• Использовании XMLHttpRequest или Fetch API для кросс-доменных запросов.
• Попытке доступа к ответу скрипта через JavaScript (например, если бы вы пытались загрузить его код как текст).

Для тега <script> CORB/ CORS не применяется, потому что:

• Скрипт автоматически выполняется при загрузке.
• Код из внешнего источника полностью доверяется и получает те же права, что и код с основного домена.

// ЭТО вызовет CORS-ошибку (если сервер не разрешает):
fetch('https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js')
  .then(response => response.text())
  .then(code => console.log(code)); // Блокируется политикой CORS

// А тег <script> такой проверки не проходит — он просто загружает и выполняет код.

Технические детали и нюансы

Атрибут crossorigin

В современных браузерах можно использовать атрибут crossorigin для загрузки скриптов с проверкой CORS. Это нужно для:

• Отлова ошибок загрузки в window.onerror.
• Использования строгого режима CORS (например, когда нужны учетные данные).

<!-- С этим атрибутом браузер отправит Origin и проверит CORS-заголовки -->
<script 
  src="https://cdnjs.cloudflare.com/ajax/libs/react/18.2.0/react.production.min.js"
  crossorigin="anonymous">
</script>

• crossorigin="anonymous": Запрос без кук/учетных данных, но с заголовком Origin. Сервер должен ответить Access-Control-Allow-Origin: *.
• crossorigin="use-credentials": С куками и учетными данными.

Зачем CDNJS настраивает CORS-заголовки?

Хотя <script> работает без CORS, CDNJS добавляет заголовки:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, OPTIONS

Причины:

• Позволяет разработчикам использовать скрипты с атрибутом crossorigin.
• Поддержка альтернативных способов загрузки (динамическое создание скриптов, Service Workers).
• Соответствие современным стандартам безопасности.

Безопасность и риски

Главный риск: компрометация CDN

Поскольку внешний скрипт выполняется с правами основного домена:

• Если CDNJS будет скомпрометирован, злоумышленник может внедрить вредоносный код в миллионы сайтов.
• MITM-атаки могут подменить скрипт при незашифрованном соединении (HTTP).

Меры защиты:

• Использовать Subresource Integrity (SRI) — хеши для проверки целостности скрипта.
• Настройка Content Security Policy (CSP) для whitelist'а доверенных источников.

<!-- Пример с SRI и CORS -->
<script 
  src="https://cdnjs.cloudflare.com/ajax/libs/vue/3.2.47/vue.global.min.js"
  integrity="sha512-..."
  crossorigin="anonymous">
</script>

Практические рекомендации

1. Для публичных библиотек используйте <script> без CORS проблем.
2. Если нужен доступ к коду скрипта (например, для кастомной загрузки) — потребуется CORS от сервера или прокси.
3. Всегда включайте SRI при использовании CDN в продакшене.
4. Настройте CSP для ограничения источников скриптов.

Заключение

CORS не блокирует скрипты с CDNJS, потому что:

• Тег <script> освобожден от Same-Origin Policy для загрузки и выполнения.
• CORS регулирует доступ к ответам междоменных запросов через JavaScript API.
• CDNJS настраивает CORS-заголовки "на будущее" и для продвинутых сценариев.

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