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 уязвимость позволила бы любому сайту открывать видеоконференции с произвольными участниками, не спрашивая пользователя.
Кому это важно
Любому, кто строит веб-приложения, мобильные приложения с локальными компонентами или интеграции между фронтенд и бэкенд. Особенно критично для команд, работающих над продуктами безопасности или приватности. Проблема универсальна: автор встречал такие ошибки во всех уровнях квалификации и размерах компаний.
Как это применить
При реализации кросс-доменных запросов явно указывайте domain в Access-Control-Allow-Origin, не используйте wildcard. Если на localhost запускается веб-сервер для интеграции с браузером, снабдите его самоподписанным сертификатом и правильными CORS-заголовками. Проверьте пример кода перед копированием из Stack Overflow: если видите Access-Control-Allow-Origin: *, остановитесь.
Можно ли доверять
Статья опубликована в 2019 году, но проблема остаётся актуальной. Автор опирается на открытый отчёт об уязвимости Zoom и стандартное поведение браузеров. Рекомендации соответствуют спецификации и практике: используйте Access-Control-Allow-Origin с конкретным доменом и Content Security Policy для защиты от фреймирования.
Риски и подводные камни
Риск маскировки проблемы через обходы: если что-то не работает из-за CORS, соблазн большой переписать код, чтобы избежать проверок браузера. Также часто встречается смешивание CORS и Content Security Policy, они решают разные задачи. Наконец, даже если CORS настроен верно, остаются вопросы UX: автоматическое открытие нативных приложений без явного согласия пользователя остаётся потенциальной проблемой.
«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, автор статьи