Что такое CORS?

🎯 Зачем спрашивают

Проверить базовое понимание браузерной модели безопасности.

Отличает ли кандидат CORS от других механизмов защиты (аутентификация, CSRF, XSS).

Может ли объяснить, на чьей стороне настраивается политика (сервер vs браузер).

Понимает ли кандидат ограничения CORS.

📝 Ответ

Коротко: CORS (Cross-Origin Resource Sharing) — это механизм безопасности в браузерах, который регулирует, какие ресурсы (например, данные из API) можно загружать с других доменов (других источников).

CORS нужно настраивать на сервере, потому что только сервер может корректно указывать браузеру, кому и что разрешено.

Подробнее:

CORS реально работает только в браузере. Сервер ↔ сервер запросы (через curl, Postman, Python, Node.js) не ограничиваются CORS, потому что там нет браузерного окружения.

Почему же тогда всё равно нужно настраивать CORS на сервере?

Браузер доверяет только серверу.

Если бы CORS настраивался только в браузере, то это был бы не контроль, а иллюзия защиты. Пользователь может отключить CORS проверку, изменив настройки браузера.

Поэтому сервер сам должен устанавливать список доменов, которым разрешается делать запросы. Это часть серверной политики безопасности, а не клиентской.

Алгоритм:

Браузер, выполняя запрос к "чужому" домену, спрашивает у сервера разрешение.

Для этого он:

Добавляет заголовок Origin в запрос.

Иногда перед реальным запросом делает так называемый preflight-запрос (метод OPTIONS) с заголовками Access-Control-Request-*.

Сервер в ответе должен указать специальные заголовки (Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers и т. д.).

Эти заголовки — сигнал браузеру:

"Да, я разрешаю доступ с такого-то источника, таким-то методам, таким-то заголовкам".

Если сервер не отвечает нужными заголовками, браузер заблокирует ответ (даже если запрос дошёл до сервера и тот его выполнил!).

💡

Что такое Origin?

Origin (источник) = комбинация протокола, домена и порта

Например:

https://site.com:443 и http://site.com:80 → разные источники.

https://app.site.com и https://api.site.com → тоже разные источники.

По умолчанию браузеры запрещают выполнение запросов с одного сайта (origin) на другой, если это не явно разрешено. Это сделано, чтобы базово защитить пользователей от CSRF- и XSS-атак.

⚖️ Компромиссы

✅ Плюсы	❌ Минусы
Повышает безопасность, снижает риск утечек	Иногда мешает легитимным сценариям (например, интеграции с внешними API)
Гибкая настройка (по методам, заголовкам, источникам)	Может быть сложно настроить правильно (особенно wildcard)
ㅤ	Добавляет задержку из-за preflight-запросов

🔎 Встречные вопросы

Защитит ли CORS от curl или сервер-сервер запросов? (для этого нужны другие механизмы безопасности: аутентификация, авторизация, CSRF-защита).

Что делает заголовок Access-Control-Allow-Credentials и когда его можно использовать?

Почему Access-Control-Allow-Origin: * может быть опасным в связке с credentials: true?

🚩 Красные флаги

🛠 Практика

📚 Источники / ссылки