Проверка CORS

Как работает инструмент Проверка CORS

Инструмент Проверка CORS помогает понять, разрешит ли веб-браузер конкретный cross-origin запрос на основе предоставленных вами HTTP-заголовков ответа и параметров вашего запроса.

Для выполнения проверки вы вставляете заголовки ответа, указываете происхождение (origin), метод и заголовки планируемого запроса, а также выбираете, включены ли учетные данные. На основе этих данных инструмент определяет, разрешит ли браузер данный запрос, и объясняет свое решение в соответствии с правилами политики CORS.

Этот инструмент работает локально: он анализирует только предоставленные заголовки ответа и параметры запроса. Он не связывается с сервером, не считывает URL-адреса, не устанавливает файлы cookie, не проверяет DNS/TLS и не изменяет конфигурацию сервера.

Входные параметры для проверки

Чтобы запустить проверку, необходимо настроить следующие поля в интерфейсе:

• Ответ на проверку (выбор между «Фактический ответ» или «Ответ на предварительный запрос»).
• HTTP заголовки ответов: текстовое поле для ввода заголовков ответа HTTP, включая строку статуса для предварительных запросов. Максимальный размер ввода составляет 200 000 символов. Если поле оставить пустым, появится ошибка «Вставьте HTTP заголовки ответов перед проверкой.». Если текст слишком большой, отобразится сообщение «Эта реакция необычно велика. Оставьте это под ‹max› символами.». При наличии некорректных строк вы увидите ошибку «Строка ‹line› не является действительным заголовком HTTP или статусной строкой.» или «Строка ‹line› содержит неверное название заголовка HTTP.».
• Происхождение запроса: текстовое поле для указания схемы, хоста и опционального порта источника (например, https://app.example.com). Поле должно содержать только чистый источник без путей, параметров запроса или учетных данных. В противном случае возникнет ошибка «Введите начало координат только со схемой, хостом и необязательным портом, например, https://app.example.com.».
• Запрошенный метод: HTTP-метод для проверки. Некорректный токен вызовет ошибку «Введите валидный токен метода HTTP.». Если метод запрещен для использования в fetch-запросах браузера, инструмент покажет ошибку «Браузеры не разрешают метод ‹method› в запросах на получение.».
• Запрошенные имена заголовков: список заголовков из Access-Control-Request-Headers, разделенных запятыми или переводами строк (например, Content-Type, Authorization). При вводе недопустимого имени отображается ошибка ««‹header›» не является действительным названием заголовка HTTP запроса.».
• Включите уводные данные: переключатель (toggle), указывающий, содержит ли запрос файлы cookie или данные HTTP-аутентификации.

Если во входных данных присутствуют ошибки, инструмент выведет общее предупреждение: «Исправьте выделенный ввод и попробуйте снова.».

Решения браузера и результаты анализа

После проведения анализа инструмент выводит одно из следующих решений в поле Решение браузера:

• «Это разрешено благодаря вставленному ответу CORS.»
• «Заблокировано вставленным ответом CORS.»
• «Заголовки проходят, но статус предполётного режима неизвестен.»
• «Введите ответ и запрос деталей, затем проверьте политику CORS.» (если данные не заполнены).
• «Вставьте ответ, чтобы проверить его CORS политику.» (начальное состояние инструмента).

Также инструмент отображает Поля управления доступом с парсированием (разобранные поля группы Access-Control-*).

Правила CORS и причины решений

Инструмент детально объясняет логику своего решения на основе стандартов CORS:

• Проверка происхождения (Origin):
  • Если заголовок совпадает: «Access-Control-Allow-Origin точно совпадает с ‹origin›.».
  • Если разрешены любые источники: «Access-Control-Allow-Origin позволяет любой источник этого запроса.».
  • Если заголовок отсутствует: «Access-Control-Allow-Origin пропал.».
  • Если значение некорректно: «Access-Control-Allow-Origin имеет недопустимое значение: ‹value›.». Если заголовок содержит несколько значений или разделен запятыми, он распознается как недействительный.
  • Если значение не совпадает с ожидаемым: «Access-Control-Allow-Origin ‹actual›, а не ‹expected›.».
• Учетные данные (Credentials):
  • Если учетные данные включены, заголовок Access-Control-Allow-Origin не может принимать значение *. В этом случае выводится ошибка: *«Access-Control-Allow-Origin не может быть , когда учитываются удостоверения квалификации.».
  • Для запросов с учетными данными заголовок Access-Control-Allow-Credentials должен иметь точное значение true. При успешном совпадении выводится: «Access-Control-Allow-Credentials абсолютно верно.». Если он отсутствует или не равен true: «Запрос с аккредитацией должен Access-Control-Allow-Credentials: истинный.».
  • Если учетные данные не используются: «Документы не учитываются, поэтому Access-Control-Allow-Credentials не влияет на это решение.».
• Статус предварительного запроса (Preflight):
  • Успешный статус: «Статус предполётного ‹status› успешен.».
  • Неуспешный статус: «Статус предполётного ‹status› не является успешным статусом 2xx.».
  • Если строка статуса отсутствует в предполётном ответе, результат проверки статуса становится неопределенным (indeterminate): «Строка статуса HTTP не была вставлена, поэтому требуемый статус 2xx до полета не может быть проверен.».
• Разрешенные методы:
  • Если метод разрешен предполётным запросом: «Предполётный этап позволяет ‹method›.».
  • Если метод входит в безопасный список: «‹method› является методом CORS-сейф-листинг, и не обязательно указывать его в Access-Control-Allow-Methods.».
  • Если метод заблокирован: «Access-Control-Allow-Methods не разрешает ‹method›.».
• Разрешенные заголовки:
  • Если заголовки не требуют проверки: «Запрашиваемые названия заголовков не требуют предварительного одобрения.».
  • Если заголовки разрешены предполётным ответом: «В предполётном режиме разрешаются запрошенные имена заголовков: ‹headers›.».
  • Использование маски * без учетных данных: «Access-Control-Allow-Headers: * охватывает эти имена для запроса без удостоверений квалификации: ‹headers›.». При наличии учетных данных групповые символы (*) для методов и заголовков теряют свое значение дикой карты.
  • Если заголовки не разрешены: «Access-Control-Allow-Headers не разрешает: ‹headers›.».
  • Особый случай с Authorization: этот заголовок всегда должен быть явно указан в Access-Control-Allow-Headers, даже если присутствует символ *. В противном случае выводится: «Authorization должны быть указаны явно; Access-Control-Allow-Headers: * это не покрывает.».

Ограничения результатов проверки

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

• Возможные перенаправления (redirects);
• Кэшированные ответы браузера;
• Изменения правил на стороне сервера;
• Влияние установленных расширений браузера;
• Фактический ответ сервера, полученный после выполнения предварительного запроса.

Конфиденциальность данных

Ваша конфиденциальность полностью защищена при использовании инструмента. Все вставленные заголовки и параметры запроса обрабатываются исключительно внутри вашего веб-браузера. Никакие данные не отправляются на серверы и не сохраняются на платформе BroBroGo.

Кому полезен этот инструмент

Инструмент разработан для широкого круга специалистов, сталкивающихся с настройкой и отладкой сетевых запросов в браузере:

• Фронтенд-разработчики, проверяющие возможность чтения ответов кодом браузера;
• Бэкенд-разработчики и разработчики API-платформ, настраивающие CORS-политики на сервере;
• Инженеры по эксплуатации (Operations), проверяющие корректность конфигурации веб-серверов;
• Любые специалисты, которым необходимо убедиться, что предполётный ответ OPTIONS одобряет последующий метод и запрошенные заголовки.

Часто задаваемые вопросы (FAQ)

Стоит ли вставлять сам ответ или ответ до перелёта?

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

Почему джокер-карта может провалиться с учётными данными?

Когда в запросе включены файлы cookie или HTTP-аутентификация, разрешенный источник в заголовке Access-Control-Allow-Origin должен строго и точно совпадать с источником запроса (использование * запрещено). Кроме того, при использовании учетных данных уайлд-карды (*) для разрешенных методов и заголовков полностью теряют свое групповое значение.

Доказывает ли проходящий результат, что живой запрос будет работать?

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