Как найти причину ошибки CORS и исправить доступ к ресурсу

Ошибка CORS связана с доступом страницы к ресурсу другого источника. Проверьте адреса, предварительную проверку и заголовки фактического ответа сервера.

Что должно получиться

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

Сообщение в консоли — начало диагностики. Оно не всегда означает, что файл отсутствует или сервер полностью недоступен. Иногда ответ дошёл до браузера, но код страницы не получил права его прочитать. В других случаях не прошёл предварительный этап, и основное действие вообще не выполнялось.

Проверяйте собственный проект или среду, с которой имеете право работать. До изменения серверной конфигурации сохраните её текущий вариант и договоритесь, какие страницы должны пользоваться ресурсом. Универсального набора заголовков для любого API нет.

Из чего это складывается

Источник — это сочетание схемы, хоста и порта. Разные поддомены или переход с HTTP на HTTPS уже меняют источник. Путь внутри одного источника сам по себе его не меняет. Сравнивайте реальные адреса, а не только знакомое название домена.

Как это сделать по шагам

1. Воспроизведите один сбой. Откройте нужную страницу и выполните действие, которое вызывает ошибку. Зафиксируйте адрес ресурса и полную причину из консоли. Не смешивайте сообщения от нескольких разных функций.
2. Сравните источники. Проверьте схему, хост и порт страницы и конечного ресурса. Посмотрите перенаправления: обращение могло уйти на другой адрес или на страницу входа.
3. Отделите обычную сетевую проблему. Убедитесь, что ресурс доступен, сертификат исправен и сервер не отвечает страницей аварии. Сообщение о CORS может сопровождать проблему, которую сначала нужно решить на уровне связи или приложения.
4. Найдите предварительную проверку. Если браузер отправляет OPTIONS, проверьте её ответ отдельно. Найдите ожидаемый метод и перечень используемых заголовков.
5. Сверьте разрешения ответа. Проверьте Access-Control-Allow-Origin и, когда нужно, разрешения метода, заголовков и передачи данных сеанса. Сопоставьте их с реальным обращением.
6. Исправьте конкретное несоответствие. В своём сервисе настройте допустимый источник и необходимые действия. Если адрес или параметры клиента неверны, поправьте их. Для чужого API используйте только документированный способ интеграции.
7. Повторите проверку в браузере. Убедитесь, что код прочитал ожидаемые данные и обработал их. Проверьте фактический ответ после изменения, включая промежуточный кеш.
8. Проверьте границу доступа. Разрешённый сценарий должен работать, а посторонний источник не должен получать закрытые данные. Проверьте также отказ авторизации и серверную ошибку.

Какая сторона исправляет ошибку

Разрешение CORS задаёт сервер, который выдаёт ресурс. Добавление Access-Control-Allow-Origin в клиентский JavaScript как исходящего заголовка не даст странице право прочитать ответ. Браузер оценивает заголовок ответа, полученного от нужной стороны.

Если вы управляете и сайтом, и API, определите разрешённые источники заранее. Сервер может сравнивать полученный Origin со своим списком и возвращать соответствующее разрешение. Автоматически отражать любое присланное значение без проверки нельзя считать корректной политикой доступа.

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

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

Что означает Access-Control-Allow-Origin

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

Значение * означает общий доступ в подходящем сценарии без передачи credentials. Оно не подходит как автоматическая починка для закрытого сервиса. При обращении с credentials браузер не принимает * в Access-Control-Allow-Origin: требуется конкретный разрешённый источник.

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

Проверьте отсутствие дублирования. Заголовки иногда добавляют одновременно приложение, веб-сервер и промежуточный сервис. Несколько несовместимых значений Access-Control-Allow-Origin не становятся разрешением от того, что каждое выглядит знакомо. Назначьте понятное место, которое формирует политику.

Как разобрать предварительную проверку

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

В предварительной проверке браузер сообщает планируемый метод и нужные заголовки. Сервер должен разрешить именно используемый сценарий. Для этого служат Access-Control-Allow-Methods и Access-Control-Allow-Headers вместе с разрешением источника.

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

Успешная предварительная проверка ещё не означает успешный ответ основного действия. На его результате также нужны подходящие разрешения CORS. Отдельно смотрите, что происходит при ошибке приложения: иначе полезное сообщение сервера может оказаться недоступно коду страницы.

Cookies, credentials и авторизация

Для обращения к другому источнику с данными сеанса требуется согласование клиента и сервера. Например, у fetch передачей credentials управляет соответствующая настройка. Включать её нужно только там, где она действительно необходима по устройству приложения.

При таком сценарии серверу требуется точное разрешение источника и Access-Control-Allow-Credentials: true. При этом браузерные правила cookies продолжают действовать. Даже корректные CORS-заголовки не гарантируют, что сторонняя cookie будет принята или отправлена.

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

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

Что не исправляет CORS

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

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

Замена библиотеки. Переход с fetch на другую клиентскую библиотеку сам по себе не изменяет политику сервера. Сравните фактически отправляемые параметры, чтобы понять, не добавила ли библиотека другой метод или заголовок.

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

Частые ошибки

• Смотреть только короткое сообщение. Полная причина часто указывает на конкретное несовпадение заголовка, метода или credentials.
• Проверить только OPTIONS. Основной ответ может не содержать нужного разрешения, особенно на ветке ошибки.
• Разрешить все источники ради одного клиента. Сначала определите назначение ресурса и допустимый круг страниц.
• Пропустить перенаправление. Конечный ответ может прийти с другого источника или оказаться HTML-страницей входа.
• Не учитывать кеш. Настройка сервера и полученный браузером ответ могут временно различаться.

Как проверить

• Зафиксированы фактические источники страницы и ресурса, метод и нужные заголовки.
• Причина из консоли сопоставлена с реальным сетевым обменом.
• Предварительная проверка, если она нужна, обрабатывается отдельно и корректно.
• Основной ответ доступен коду в разрешённом сценарии.
• Данные действительно прочитаны и использованы, а не просто исчезло сообщение ошибки.
• Авторизация и обработка отказов сохранились.
• Проверены посторонний источник, серверная ошибка и ответ после кеширования.

Начните с инструкции по чтению ошибок JavaScript. Для связанных случаев пригодятся подключение веб-шрифта и проверка кеширования ресурсов. Задачу по исправлению интеграции можно разместить в разделе Разработка.

Проверьте также настройку Content Security Policy: CSP и CORS ограничивают доступ независимо.

Вопросы и ответы

Почему API работает отдельно, но не на странице?

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

Можно исправить всё только во фронтенде?

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

Нужно всегда разрешать OPTIONS?

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

Почему no-cors не помогает получить JSON?

Ответ opaque недоступен коду для обычного чтения тела и заголовков. Исчезновение прежнего сообщения не означает, что приложение получило данные. Исправьте разрешённый путь доступа вместо смены режима ради внешнего эффекта.

Можно использовать звёздочку с cookies?

При CORS-обращении с credentials значение * в Access-Control-Allow-Origin не подходит. Требуются конкретный разрешённый источник и согласованные настройки передачи данных сеанса. Правила самих cookies при этом тоже продолжают действовать.

Как понять, что исправление закончено?

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

Что передать разработчику для диагностики?

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