CORS: почему запрос работает в curl, а в браузере нет

Если запрос работает в curl, а браузер сообщает CORS, сравните не только адрес: проверьте Origin, credentials, предварительный OPTIONS и разрешение чтения основного ответа. Успех одного HTTP-клиента не проверяет условия доступа браузерного скрипта. Исправление зависит от этапа отказа и не требует автоматически отключать авторизацию.

Что означает разница между клиентами

В браузере код страницы работает в контексте своего источника. MDN о CORS описывает согласование доступа к ответам между разными источниками. Другой HTTP-клиент может успешно получить ответ, не воспроизводя контекст браузерного скрипта и его ограничения.

Также сами запросы могут различаться: заголовками, режимом учётных данных, маршрутом и обработкой переходов. Поэтому сначала сохраните фактические условия. Фраза «по тому же URL всё работает» не означает, что сравниваются одинаковые операции.

Две возможные фазы

Preflight на MDN описан как автоматически выполняемый браузером OPTIONS, который согласует будущий метод и заголовки. Он нужен не для каждого запроса. Отсутствие такого обращения само по себе не является ошибкой или доказательством отключённой защиты.

Если необходимая предварительная проверка не пройдена, основной запрос может не быть отправлен. В другой ситуации сервер уже обработал основной запрос, но браузер не предоставляет ответ вызывающему коду. Эти случаи имеют разные последствия и следующие действия.

Учебная матрица наблюдений

Таблица относится к условному разрешённому клиенту и API. Это не результат обращения к сервисам пользователя. Код ответа и заголовки нужно подтверждать в собственной согласованной тестовой процедуре.

Сначала прочитайте точную причину

В руководстве MDN по ошибкам CORS рекомендуется установить конкретный проблемный запрос и сообщение консоли. Разные формулировки нельзя сводить к одному отсутствующему заголовку. Иногда доступ намеренно не разрешён и это не ошибка конфигурации.

Сопоставьте сеть, сообщения браузера и допустимые серверные наблюдения. Не считайте общее сообщение JavaScript полной диагностикой того, что произошло на сервере. Для чувствительного действия отдельно выясните, было ли оно выполнено, прежде чем повторять его.

Origin не является правом пользователя

CORS определяет условия предоставления ответа вызывающему браузерному коду. Проверка личности, роли и допустимости операции остаётся задачей API. Нельзя считать, что известный Origin сам подтверждает пользователя или что отсутствие браузерной блокировки заменяет авторизацию.

Разрешайте только согласованные источники для нужной функции. Не отражайте произвольное значение Origin как доверенное без проверки политики. И не убирайте защиту основного действия только для того, чтобы предварительный запрос выглядел успешным.

Как разбирать credentials

Для запросов с учётными данными звёздочка в Access-Control-Allow-Origin несовместима с таким режимом. Если данные действительно нужны, согласуют явный разрешённый источник и соответствующий ответ. Отключение credentials может убрать симптом, но одновременно изменить смысл запроса.

Проверьте, почему режим вообще выбран и что клиент должен передать. Политика CORS и правила передачи конкретных данных не являются одной настройкой. Успешное согласование не следует представлять как гарантию, что любые cookie или права доступны в любом браузерном контексте.

Заголовок разрешённого источника должен присутствовать в нужном фактическом ответе, а не только в успешном ответе другого маршрута. Страница ошибки, ответ промежуточного слоя или редирект могут потребовать отдельного разбора. Не распространяйте один удачный пример на все варианты.

Предварительный ответ тоже имеет контракт

Согласуйте разрешённые методы и заголовки, не превращая OPTIONS в произвольный допуск любых операций. Его назначение отличается от выполнения самого действия. Правила основного запроса продолжают действовать независимо от того, что политика предварительно разрешила браузеру попытаться отправить.

Проверяйте повторное состояние клиента и возможное кеширование предварительного результата. Если настройки изменились, один старый сценарий может ещё не отражать новый путь. Не выводите универсальное время обновления по одному браузеру; сохраните условия проверки.

Приёмка исправления CORS

1. Зафиксируйте Origin, метод, заголовки, credentials и фактический маршрут браузерного запроса.
2. Установите, требовался ли preflight и прошёл ли он.
3. Отдельно проверьте отправку основного запроса и доступ к его ответу.
4. Прочитайте точное сообщение браузера и подтверждённую серверную причину.
5. Согласуйте разрешённые источники и обработку ошибок без отключения авторизации.
6. Проверьте разрешённый сценарий и контрольный отказ в своей тестовой среде.

Не исправляйте рабочую систему установкой расширения, отключающего ограничения браузера. Такое изменение не настраивает API для пользователей. Здесь не выполнялись реальные запросы к проектам и изменения политики; описан порядок приёмки владельцем с нужными полномочиями.

Как передать задачу

Для аудита API подготовьте безопасную последовательность наблюдений без токенов и личных данных. В API-интеграции задайте ожидаемый клиентский контекст. Для доработки укажите конкретную фазу и критерий результата.

Исправленный сценарий позволяет согласованному клиенту выполнить допустимую операцию и прочитать нужный ответ, сохраняя ограничения для остальных. Одного успешного curl или исчезнувшей строки консоли для такого вывода недостаточно.