Что такое CORS

CORS нужен из-за Same-Origin Policy. По умолчанию браузер ограничивает JavaScript страницы. Страница не может свободно читать данные с другого origin. Другой origin появляется, если отличается протокол, домен или порт.

Например, https://app.example.com и https://api.example.com это разные origin. http://localhost:3000 и http://localhost:8080 тоже разные origin.

Хороший короткий ответ звучит так. CORS не делает запрос безопасным сам по себе. Он задает правила, по которым браузер решает, можно ли странице прочитать ответ от другого origin.

При CORS-запросе браузер добавляет заголовок Origin. Сервер должен вернуть подходящие заголовки, например Access-Control-Allow-Origin. Если origin не разрешен, браузер покажет CORS-ошибку и не отдаст ответ вашему JavaScript.

Важная деталь для интервью такая. CORS применяет браузер. Поэтому запрос из curl, Postman или с вашего backend-сервера может работать, а тот же URL из браузера падать с CORS-ошибкой.

Origin: https://app.example.com

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type

Если вы говорите это на интервью, добавьте практический вывод. Источник проблемы обычно в CORS-контракте API, gateway или reverse proxy, а не в синтаксисе fetch.

Не каждый cross-origin запрос сразу отправляется как основной. Для не простых запросов браузер сначала делает preflight, то есть OPTIONS-запрос. Так он спрашивает сервер, разрешены ли метод и заголовки будущего запроса.

Пример запроса, который обычно вызовет preflight:

fetch("https://api.example.com/profile", {
  method: "PATCH",
  headers: {
    "Content-Type": "application/json",
    Authorization: "Bearer token",
  },
  body: JSON.stringify({ name: "Alex" }),
});

Здесь есть метод PATCH, JSON и Authorization. Сервер должен корректно ответить на OPTIONS. Если API возвращает 404, 500 или не добавляет CORS-заголовки на preflight, основной запрос браузер не отправит.

Практический вывод для UI такой. Не переводите форму в успешное состояние до ответа основного запроса. Покажите понятную ошибку, сбросьте loading и дайте повторить действие после исправления причины. Иначе пользователь увидит вечную загрузку или ложный success, хотя данные не сохранились.

В DevTools смотрите не только красную строку в консоли, но и вкладку Network. Иногда ошибка висит на OPTIONS, а не на основном запросе. Иногда основной запрос дошел до сервера, но браузер заблокировал чтение ответа.

Это важно для действий, которые меняют данные. Если POST создал заказ, а фронтенд не прочитал ответ из-за CORS, слепой retry может создать дубль. Безопаснее оставить форму в понятном error state, проверить серверные логи, идемпотентность операции и только потом повторять запрос.

На фронтенде вы управляете только клиентской частью запроса. Например, для cookies нужно явно включить credentials:

fetch("https://api.example.com/me", {
  credentials: "include",
});

Но этого мало. Сервер должен вернуть конкретный Access-Control-Allow-Origin, а не *, и Access-Control-Allow-Credentials: true. Cookies также должны быть настроены с учетом SameSite и Secure, если это cross-site сценарий.

Плохой вариант ответа на интервью такой. Можно просто поставить mode: "no-cors". Так говорить не стоит. Этот режим не дает нормальный JSON-ответ для API. Вы получите opaque response и потеряете возможность обработать статус, тело и ошибки. В UI это часто превращается в вечный loading или общее сообщение о непонятной ошибке. Безопаснее настроить CORS на сервере, gateway или dev-proxy и явно обработать error state на клиенте.

CORS не заменяет авторизацию. Если API отдает приватные данные, сервер обязан проверять сессию, токен, права пользователя и бизнес-правила. CORS только ограничивает, какие страницы в браузере могут прочитать ответ.

CORS также не является полной защитой от CSRF. В некоторых случаях браузер может отправить запрос с cookies, даже если ответ потом нельзя прочитать из JavaScript. Для опасных действий нужны дополнительные меры: SameSite, CSRF-токен, проверка Origin или Referer, а также идемпотентность там, где возможны повторы.

Сильный ответ показывает эту границу. Вы не обещаете, что CORS защищает API от всех атак, и не предлагаете открывать * в продакшене без понимания данных и credentials.