Ошибка CORS в браузере: что заблокировано и почему правка фронтенда не всегда помогает

Ошибка CORS означает, что браузер не разрешил JavaScript прочитать ответ другого origin по действующей политике сервера. Чаще всего исправление находится в настройке API или доверенного прокси, а не в строке fetch. Сначала запишите origin страницы и origin API, затем найдите запрос во вкладке Network. Проверьте, отправлялся ли OPTIONS, какой заголовок Origin ушёл и какие Access-Control-Allow-* вернул сервер.

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

Что браузер считает другим origin

Origin состоит из схемы, имени хоста и порта. Страницы http://localhost:5173 и http://localhost:3000 находятся на одном компьютере, но имеют разные порты и потому разные origin. Путь не входит в origin: /users и /orders на одном протоколе, хосте и порту остаются same-origin.

Страница: http://localhost:5173
API:      http://localhost:3000

Схема: http = http
Хост: localhost = localhost
Порт: 5173 != 3000
Результат: cross-origin request

Различие любого из трёх компонентов делает запрос cross-origin.

Как читать CORS-ошибку во вкладке Network

Для некоторых cross-origin запросов браузер сначала отправляет preflight методом OPTIONS. Он спрашивает, разрешены ли origin, метод и нестандартные заголовки будущего запроса. Если preflight не прошёл, основной POST или PUT может вообще не уйти. Поэтому смотреть только логи обработчика POST недостаточно.

OPTIONS /api/tasks HTTP/1.1
Origin: http://localhost:5173
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://localhost:5173
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type

Основной запрос уходит только после успешной проверки разрешений, если preflight необходим.

Какие заголовки должен вернуть сервер

Access-Control-Allow-Origin указывает разрешённый origin. Для credentialed-запросов нельзя сочетать cookies и wildcard *: сервер должен вернуть конкретный origin и Access-Control-Allow-Credentials: true. Разрешённые методы и заголовки должны покрывать фактический запрос, особенно на preflight.

fetch('https://api.example.test/profile', {
  credentials: 'include',
})

// Сервер должен ответить, например:
// Access-Control-Allow-Origin: https://app.example.test
// Access-Control-Allow-Credentials: true
// Vary: Origin

Разрешение возвращает владелец API или доверенный прокси, а браузер проверяет его.

Почему no-cors, расширение и случайный прокси не решают проблему

Режим no-cors создаёт непрозрачный ответ: JavaScript не получает нормальный статус, заголовки и тело. Он подходит для узких сценариев вроде отправки некоторых ресурсов, но не превращает закрытый API в доступный. Расширение, отключающее защиту, меняет только ваш браузер и не исправляет приложение для пользователей.

Кто должен исправлять CORS в проекте

Если вы контролируете API, добавьте allowlist origin в backend или API gateway. Если API чужой и не поддерживает браузерные запросы, используйте собственный серверный маршрут, который обращается к нему по официальным условиям. В разработке dev-server proxy может сохранить same-origin для браузера, но продовая архитектура должна иметь такой же понятный маршрут.