Как решается проблема с CORS в браузере
Что проверяют
Понимаете ли вы, что чинится это на сервере, и знаете ли рабочие варианты для разработки и прода.
Как отвечать
Сначала суть: политика одного источника не даёт коду страницы читать ответ с другого источника. CORS это способ серверу разрешить такое чтение. Значит починка всегда на стороне сервера или инфраструктуры, а не в коде фронтенда.
Правильное решение: заголовки на сервере.
Access-Control-Allow-Originс конкретным источником;- обработка предварительного запроса
OPTIONSдля всего, что выходит за рамки простого запроса, сAllow-MethodsиAllow-Headers; - при передаче куки или заголовка авторизации нужен
Access-Control-Allow-Credentials: true, и тогда звёздочку использовать нельзя, требуется точный источник; Access-Control-Expose-Headers, если коду нужны свои заголовки ответа.
В разработке: прокси в сборщике. Vite и webpack умеют проксировать запросы к API через свой адрес, и браузер видит один источник. Настройки CORS при этом не нужны вовсе.
В проде: один источник через обратный прокси. API размещают по пути вроде /api того же домена. Тогда кросс-доменных запросов нет в принципе, а заодно упрощается работа с куками, которые не приходится делать межсайтовыми. Это самый надёжный вариант, если он доступен.
Чего делать нельзя:
- отключать проверки флагом браузера: это работает только у вас и скрывает настоящую проблему;
- ставить звёздочку вместе с учётными данными: браузер такое сочетание отвергнет;
- пропускать запросы через публичные прокси-сервисы.
И понимание, которое отличает уверенный ответ: CORS ничего не защищает, он снимает ограничение. Запрос обычно доходит до сервера и выполняется, браузер блокирует лишь чтение ответа. Поэтому для POST это значит, что данные могли записаться. От подделки запросов защищает атрибут куки SameSite и токены форм, а не CORS.
Где спотыкаются
Пытаются починить CORS в коде фронтенда.
Ставят звёздочку при передаче куки.
Забывают обработать предварительный запрос.
Считают, что заблокированный запрос не дошёл до сервера.