Мережа/HTTP
CORS Checker / Explainer
Покроково пояснити, чи дозволить браузер крос-доменний запит — simple/preflight-класифікація, перевірка Access-Control-* заголовків відповіді, підсумок.
По одному на рядок, "Назва" або "Назва: значення" — значення на класифікацію не впливає.
Візьміть із вкладки Network у DevTools (заголовки самої відповіді або preflight OPTIONS) чи curl -I.
CORS (Cross-Origin Resource Sharing) — механізм браузера, що вирішує, чи дозволити JavaScript з одного сайту читати відповідь із сервера на іншому домені. Інструмент пояснює покроково, чи пройде конкретний запит, і які заголовки Access-Control-* для цього потрібні.
Як користуватися
- Вкажіть метод, origin запиту та заголовки відповіді сервера (Access-Control-Allow-Origin тощо) — інструмент визначить, чи браузер пропустить запит.
- Класифікація «simple» чи «preflight» показує, чи браузер спершу надішле службовий OPTIONS-запит перед основним.
- Підсумок вказує точну причину відмови, якщо запит не пройде, — це заощаджує час порівняно з читанням помилки в консолі браузера.
Типові сценарії
- Діагностика класичної помилки «has been blocked by CORS policy» без здогадок — покрокове пояснення, чого саме не вистачає.
- Перевірка конфігурації CORS на бекенді перед тим, як фронтенд і API опиняться на різних доменах у продакшені.
- Розуміння, чому запит з credentials: include відхиляється, хоча Access-Control-Allow-Origin виглядає правильно.
Що варто памʼятати
CORS — це захист браузера користувача, а не сервера: обмеження діють лише для запитів із коду сторінки в браузері, а не для запитів із curl, Postman чи сервера до сервера.
Access-Control-Allow-Origin: * несумісний із credentials: include — для запитів з cookie чи авторизацією сервер повинен повернути конкретний origin, а не зірочку.
Стаття про цей інструмент: CORS: чому браузер блокує "звичайні" запити до іншого домену
Часті запитання
Чому запит завершується помилкою CORS, хоча сервер відповів успішно?
CORS застосовує браузер, а не сервер — якщо у відповіді відсутній заголовок Access-Control-Allow-Origin, що відповідає джерелу запиту, браузер блокує читання відповіді через JavaScript, хоча сам запит завершився успішно.
Чим відрізняється простий запит від запиту з попередньою перевіркою (preflight)?
Прості запити (базові GET/POST зі стандартними заголовками) проходять напряму, а запити з користувацькими заголовками, іншими методами чи певними типами контенту спочатку викликають попередній запит OPTIONS для перевірки дозволу перед відправкою реального запиту.
Чи надсилає перевірка заголовків CORS тут мої дані на сервер?
Інструмент перевіряє заголовки, які ви надаєте, або отримує їх напряму з вашого браузера — жоден проміжний сервер не зберігає дані вашого запиту.
Чи захищає CORS API від зловмисних запитів?
Ні. CORS обмежує лише те, що браузер дозволить прочитати JavaScript-коду на сторінці — зловмисник може надіслати той самий запит напряму через curl чи скрипт, минаючи браузер і будь-які CORS-обмеження повністю.
Чому Access-Control-Allow-Origin: * не працює разом із credentials: include?
Специфікація забороняє це поєднання навмисно — дозволити будь-якому сайту читати відповіді разом із cookie чи авторизацією користувача було б серйозною діркою в безпеці, тож у такому разі сервер має повернути конкретний Origin, а не "*".