Что такое CORS ошибка

CORS расшифровывается как Cross-Origin Resource Sharing. Это механизм браузера, который решает, может ли JavaScript на одной странице прочитать ответ, полученный с другого origin.

Важно сказать именно про доступ к ответу, а не только про отправку запроса. Для части запросов браузер может отправить запрос на сервер, получить ответ, а потом заблокировать доступ к нему в JavaScript, если сервер не дал разрешение. Для запросов с preflight браузер сначала делает OPTIONS и может не отправить основной запрос вообще.

Короткая формулировка для интервью:

CORS ошибка значит, что браузер не дал моему frontend-коду использовать ответ с другого origin. Сервер должен явно разрешить origin, метод, нужные заголовки и credentials через CORS заголовки. Если этого нет, проблему чинят на сервере или proxy, а не магическим флагом в React.

Origin состоит из трех частей: схема, host и порт. Если отличается хотя бы одна часть, для браузера это другой origin.

https://app.example.com        -> origin: https + app.example.com + 443
https://api.example.com        -> другой host
http://app.example.com         -> другая схема
https://app.example.com:3000   -> другой порт

Поэтому frontend на http://localhost:3000 и API на http://localhost:8080 тоже находятся на разных origin. Из-за этого локально легко получить CORS ошибку, хотя оба сервиса запущены на одном компьютере.

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

Для более сложного запроса браузер сначала отправляет preflight:

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

Здесь preflight вероятен из-за PATCH, Content-Type: application/json и Authorization. Сервер должен ответить на OPTIONS так, чтобы браузер увидел разрешенные method и headers. Если gateway возвращает 404, 403 или редирект на login для OPTIONS, основной PATCH не уйдет.

На интервью полезно описать не только определение, но и порядок диагностики. Так ваш ответ звучит как реальный опыт разработки.

Вам не нужно помнить все детали спецификации наизусть. Важно понимать, какие заголовки влияют на поведение браузера и какой баг они создают в UI.

Если вы контролируете сервер, он должен вернуть CORS заголовки под ваш сценарий. Конкретный код зависит от backend-стека, но идея такая:

app.use(cors({
  origin: "https://app.example.com",
  credentials: true,
  methods: ["GET", "POST", "PATCH", "DELETE"],
  allowedHeaders: ["Content-Type", "Authorization"],
}));

Этот пример не нужно копировать вслепую. В продакшене важно разрешать только доверенные origin, не открывать приватное API через * без причины и отдельно проверить preflight. Если включаете cookies, клиенту нужен credentials: "include", а серверу нужны корректные cookie-атрибуты и CSRF защита. Если API внешний и вы не можете менять его настройки, нормальный путь такой: свой backend, BFF или proxy. Он делает запрос сервер-сервер и отдает фронтенду данные с вашего origin.

В сильном ответе вы показываете границу ответственности. Frontend может увидеть ошибку, проверить Network, понять preflight, настроить credentials и не добавлять лишние headers. Но разрешение на чтение ответа выдает сервер.

Еще важно не продавать CORS как защиту API. CORS не отменяет авторизацию, проверку прав и CSRF защиту. Если запрос меняет состояние и использует cookies, сервер должен сам проверять пользователя, CSRF token или другой признак намерения. Часть cross-origin запросов может дойти до сервера даже тогда, когда браузер потом не даст прочитать ответ.