CORS по-прежнему остаётся слепым пятном для разработчиков

CORS по-прежнему остаётся слепым пятном для разработчиков

Широко распространённое непонимание CORS приводит к небезопасным реализациям. На примере уязвимости Zoom видно, как неправильное использование кросс-доменных запросов привело к тому, что любой сайт в интернете мог управлять локальным сервером Zoom. Вместо установки правильных заголовков Access-Control-Allow-Origin для https://zoom.us команда Zoom реализовала обход через загрузку данных в изображениях, предположительно из-за неполного понимания механики браузерной безопасности.

Автор статьи указывает на системную проблему: многие разработчики копируют небезопасные примеры с Stack Overflow, не разбираясь в самом-основах. Сложность здесь не в CORS как таковом, а в общей культуре. Правильное решение требует трёх шагов: установить Access-Control-Allow-Origin с конкретным доменом, использовать Content Security Policy для блокировки iframe и избежать предоставления привилегированного доступа всем сайтам подряд.

Ключевые факты

  • Zoom использовал обход CORS через изображения, открыв уязвимость для внешних сайтов
  • Правильная реализация требует заголовка Access-Control-Allow-Origin с конкретным доменом, а не открытого доступа
  • Непонимание CORS встречается одинаково часто и у опытных, и у начинающих разработчиков
  • Копирование примеров из Stack Overflow без анализа безопасности усугубляет проблему
  • Локальный веб-сервер не должен предоставлять привилегированные функции всем сайтам в интернете

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

Почему это важно

CORS существует как контрольный механизм браузера против вредоносных скриптов. Когда разработчик не понимает его работу, он либо отключает защиту полностью, либо ищет обходы. Результат всегда одинаков: расширение поверхности атаки. На примере Zoom уязвимость позволила бы любому сайту открывать видеоконференции с произвольными участниками, не спрашивая пользователя.

Ред. Браузер всеми силами защищает пользователя, а разработчик всеми силами эту защиту обходит. Кто из них в итоге враг (вопрос риторический).

Кому это важно

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

Ред. Хорошая новость: непонимание CORS объединяет джунов и сеньоров. Плохая: ровно по той же причине.

Как это применить

При реализации кросс-доменных запросов явно указывайте domain в Access-Control-Allow-Origin, не используйте wildcard. Если на localhost запускается веб-сервер для интеграции с браузером, снабдите его самоподписанным сертификатом и правильными CORS-заголовками. Проверьте пример кода перед копированием из Stack Overflow: если видите Access-Control-Allow-Origin: *, остановитесь.

Ред. Вся инструкция сводится к «не копируйте звёздочку со Stack Overflow». Если бы это работало, статью не пришлось бы переиздавать семь лет подряд.

Можно ли доверять

Статья опубликована в 2019 году, но проблема остаётся актуальной. Автор опирается на открытый отчёт об уязвимости Zoom и стандартное поведение браузеров. Рекомендации соответствуют спецификации и практике: используйте Access-Control-Allow-Origin с конкретным доменом и Content Security Policy для защиты от фреймирования.

Ред. Статья 2019 года всё ещё актуальна. В безопасности это называют «вечнозелёный материал», а в индустрии (вежливо умалчивают).

Риски и подводные камни

Риск маскировки проблемы через обходы: если что-то не работает из-за CORS, соблазн большой переписать код, чтобы избежать проверок браузера. Также часто встречается смешивание CORS и Content Security Policy, они решают разные задачи. Наконец, даже если CORS настроен верно, остаются вопросы UX: автоматическое открытие нативных приложений без явного согласия пользователя остаётся потенциальной проблемой.

Ред. Соблазн переписать код, чтобы обойти проверку браузера, и есть та самая дорожка, которая привела Zoom к заголовку этой статьи.

«Developers just want to get their code to work, and bypassing the same-origin policy entirely might get it to work, but when someone finds out what you've done you'll get problems like Zoom has now.»

— Foster Ellis, автор статьи