01
Введите Origin приложения
Нужны схема, хост и порт вызывающей страницы, а не URL API. Локальная модель допускает выбранный Origin; реальный GET браузера всегда идёт с Origin этого сайта.
HTTP / Отладка запросов
проверка CORSузнайте, доступен ли ответ браузеру
Вставьте фактический ответ и при необходимости OPTIONS. Сетевой GET запускается только вручную.
проверка CORS
Заголовки фактического ответа
Заголовки OPTIONS (необязательно)
Вставленные заголовки анализируются в браузере без сетевого запроса.
Результат
Вставьте заголовки ответа.
Условия запроса
Этот Origin относится только к локальному анализу. GET использует настоящий Origin страницы.
Вставьте заголовки ответа.
Сервер записал HTTP 200, а fetch сообщает об ошибке? Проверка CORS отделяет HTTP-ответ сервера от права JavaScript прочитать его в браузере.
Чтобы проверить CORS онлайн без отправки запроса, начните с заголовков из DevTools. Укажите Origin приложения, метод и имена заголовков; если нужен preflight, добавьте отдельный ответ OPTIONS.
Зачем нужна проверка CORS
Успех HTTP и разрешение на чтение — разные события.
Статус 200 не гарантирует чтение
Простой GET может дойти до сервера, но без верного Allow-Origin браузер не отдаст ответ скрипту. Проверка CORS не называет HTTP-успех разрешением доступа.
OPTIONS — отдельное доказательство
JSON POST и Authorization могут требовать предварительный запрос. Если есть лишь итоговый ответ, его прохождение неизвестно. Добавьте статус OPTIONS и разрешающие заголовки.
Проверяйте оба этапа доступа
02
Определите необходимость OPTIONS
application/json, Authorization и нестандартные методы могут вызвать предварительный запрос. Достаточно имён заголовков. Без ответа OPTIONS вывод по этому этапу не подтверждён.
03
Экспортируйте свежий отчёт
Изменение данных сразу блокирует копирование старого результата. Автоанализ ждёт 350 мс; после выключения запустите кнопку или Ctrl/Cmd + Enter.
Разберите условия по отдельности
Origin и учётные данные
При credentials: include шаблон Allow-Origin: * запрещён. Точный Origin дополнительно требует Allow-Credentials: true. Заголовок Authorization не равен режиму credentials.
Методы и заголовки
Проверка preflight сопоставляет статус OPTIONS, Allow-Methods и Allow-Headers с нужным методом и именами. Отчёт называет конкретный отказ.
Видимые поля и кэш
Показываются Expose-Headers и Vary: Origin. По единственному ответу нельзя утверждать, что сервер отражает любой Origin.
Реальный GET только по команде
Клик отправляет GET без учётных данных с этой страницы. Даже HTTP 404 может быть доступен скрипту; при отказе fetch скрытый статус неизвестен.
Границы вывода
- Вставленный текст — не живой тест
- CORS-проверщик локально оценивает заданные заголовки. Он не подтверждает текущую конфигурацию API. Если требуется OPTIONS, но ответа нет, этап остаётся непроверенным.
- Origin браузера нельзя подменить
- Проверка CORS в режиме GET не использует Origin вашего приложения и не отправляет POST, Cookie или значения собственных заголовков. Успех при одинаковом происхождении не проверяет CORS.
- Без прокси и сканирования
- Сайт не пересылает произвольные URL через сервер и не перебирает происхождения. Отсутствие Allow-Origin допустимо для ресурса только своего происхождения и само по себе не является уязвимостью.
- Невидимый заголовок может существовать
- Скрипт видит лишь стандартно разрешённые или открытые через Expose-Headers заголовки. Полный обмен изучайте в DevTools или логах сервера.
Вопросы о проверке CORS
Почему запрос завершается ошибкой CORS, хотя сервер ответил успешно?
Сервер может ответить, но браузер не передаст этот ответ JavaScript. Проверьте Allow-Origin фактического ответа и отдельно OPTIONS, если требовался предварительный запрос.
В чём разница между простым запросом и запросом с предварительной проверкой (preflight)?
Простой GET уходит сразу, а затем проверяется возможность чтения ответа. JSON POST и пользовательские заголовки сначала требуют OPTIONS для Origin, метода и имён заголовков.
Отправляет ли проверка заголовков CORS здесь мои данные на сервер?
В локальном режиме вставленные данные не отправляются. Только после выбора браузерного GET и нажатия кнопки браузер запросит указанный URL без учётных данных.
Защищает ли CORS API от вредоносных запросов?
Нет. CORS регулирует чтение ответов JavaScript в браузере, но не заменяет проверку полномочий и авторизацию на сервере. curl не применяет это браузерное ограничение.
Почему Access-Control-Allow-Origin: * не работает вместе с credentials: include?
С credentials: include сервер должен вернуть точный Origin и Allow-Credentials: true. Ответ с Allow-Origin: * браузер не откроет скрипту.
Нужен другой пример?
Проверка CORS по настоящим заголовкам
Скопируйте фактический ответ и при необходимости OPTIONS из DevTools. Проверка CORS разделит оба решения до изменения настроек сервера.
По умолчанию локально; сетевой GET — только после клика.