Перевірка CORS

Розуміння політики спільного використання ресурсів між різними джерелами (CORS)

Політика спільного використання ресурсів між різними джерелами (CORS) — це механізм безпеки, який реалізують веб-браузери для обмеження доступу до ресурсів, що запитуються з іншого походження, ніж те, з якого було завантажено перший документ. Походження визначається комбінацією схеми (протоколу), хоста та порту. Коли веб-додаток намагається виконати крос-доменний запит, браузер оцінює HTTP-заголовки відповіді сервера, щоб визначити, чи дозволено клієнтському коду прочитати отримані дані.

Цей інструмент допомагає розробникам проаналізувати взаємодію між параметрами запиту та заголовками відповіді сервера. Він оцінює надані дані та імітує логіку прийняття рішень браузером, показуючи, чи буде запит заблоковано чи дозволено.

---

Робота з інтерфейсом інструменту

Для перевірки політики CORS необхідно налаштувати параметри запиту та надати HTTP-заголовки відповіді. Інструмент працює локально: ваші заголовки та дані запитів залишаються у вашому браузері, нічого не завантажується і не зберігається на BroBroGo.

Вхідні параметри

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

При виникненні будь-яких помилок введення відображається повідомлення: «Виправте виділений вхід і спробуйте знову.».

---

Аналіз рішень браузера та їх причини

Після аналізу введених даних інструмент виводить один із статусів рішення браузера у полі «Рішення браузера»:

• «Вставте відповідь, щоб перевірити її CORS політику.» (початковий стан).
• «Введіть відповідь і запит на деталі, потім перевірте політику CORS.» (якщо дані відсутні).
• «Це дозволено завдяки вставленій CORS відповіді.».
• «Заблокований вставленою відповіддю CORS.».
• «Заголовки відповідають вимогам, але стан попереднього запиту невідомий.».

Причини прийняття рішень щодо джерела (Origin)

Якщо заголовок Access-Control-Allow-Origin містить кілька значень або розділений комами, він вважається недійсним.

Вплив облікових даних (Credentials)

Коли запит виконується з обліковими даними (cookies або HTTP-автентифікація), діють суворіші правила:

• Заголовок Access-Control-Allow-Credentials повинен мати точне значення true. У цьому випадку виводиться: «Access-Control-Allow-Credentials абсолютно правда.». Якщо заголовок відсутній або має інше значення, відображається: «Підтверджений запит має бути Access-Control-Allow-Credentials: правдивий.».
• Якщо облікові дані не використовуються, цей заголовок не впливає на рішення: «Документи не включаються, тому Access-Control-Allow-Credentials не впливає на це рішення.».
• При використанні облікових даних значення * (wildcard) у заголовку Access-Control-Allow-Origin є неприпустимим. Також у цьому випадку символи шаблону * у заголовках Access-Control-Allow-Methods та Access-Control-Allow-Headers втрачають своє значення групового символу.

---

Особливості попередніх запитів (Preflight)

Попередній запит (виконується методом OPTIONS) використовується браузером для перевірки, чи дозволяє сервер виконати фактичний запит з певним методом та заголовками.

Перевірка HTTP-статусу preflight-відповіді

Для успішного проходження попереднього запиту сервер має повернути успішний статус із діапазону 2xx.

• Якщо статус успішний: «Стан попереднього запиту ‹status› успішний.».
• Якщо статус не належить до 2xx: «Стан попереднього запиту ‹status› не є успішним станом 2xx.».
• Якщо рядок стану HTTP відсутній у вставлених заголовках, результат перевірки статусу стає невизначеним: «Рядок стану HTTP не вставлено, тому неможливо перевірити обов’язковий стан 2xx для попереднього запиту.».

Перевірка методів та заголовків

• Методи: Якщо метод дозволено, виводиться: «Попередній запит дозволяє метод ‹method›.». Якщо метод належить до списку безпечних (CORS-safelisted), він не потребує обов'язкової присутності у заголовках відповіді: «‹method› входить до списку безпечних методів CORS, тому його не обов’язково вказувати в Access-Control-Allow-Methods.». В іншому випадку: «Access-Control-Allow-Methods не дозволяє метод ‹method›.».
• Заголовки: Якщо запитані заголовки не потребують схвалення: «Жодна із запитаних назв заголовків не потребує схвалення попереднім запитом.». Якщо заголовки дозволені сервером: «Попередній запит дозволяє такі назви заголовків: ‹headers›.».
• Використання шаблону *: Якщо запит не містить облікових даних, символ * дозволяє будь-який заголовок: «Access-Control-Allow-Headers: * охоплює ці назви для запиту без облікових даних: ‹headers›.». Якщо заголовок не дозволено: «Access-Control-Allow-Headers не дозволяє: ‹headers›.».
• Особливість заголовка Authorization: Заголовок Authorization є винятком. Він обов'язково має бути чітко вказаний у списку Access-Control-Allow-Headers, навіть якщо сервер повертає Access-Control-Allow-Headers: *. У разі відсутності явного згадування виводиться: «Authorization має бути чітко зазначений; Access-Control-Allow-Headers: * це не покриває.».

---

Обмеження аналізу

Цей інструмент виконує статичний аналіз наданих текстових заголовків та параметрів запиту. Він не здійснює мережевих запитів до серверів, не зчитує URL-адреси, не встановлює файли cookie, не перевіряє записи DNS чи сертифікати TLS і не змінює конфігурацію серверів.

Успішний результат перевірки («Це дозволено завдяки вставленій CORS відповіді.») свідчить лише про коректність наданих заголовків для вказаних параметрів. Він не гарантує, що реальний запит у браузері пройде успішно, оскільки на живий запит можуть вплинути перенаправлення (redirects), кешовані відповіді, динамічна зміна правил на сервері, встановлені розширення браузера або фактична відповідь, отримана після виконання preflight-запиту.

---

Часті запитання (FAQ)

Слід вставити фактичну відповідь чи відповідь на попередній запит?
Використовуйте фактичну відповідь, щоб перевірити, чи може код у браузері прочитати її. Для відповіді OPTIONS, яка дозволяє подальший метод і запитані заголовки, використовуйте відповідь на попередній запит.

Чому джокер може провалитися з обліковими даними?
Коли додаються файли cookie або HTTP автентифікації, дозволене джерело має точно відповідати запитувальному джерелу. Вайлдкарди для дозволених методів і заголовків також втрачають своє значення вайлдкарду.

Чи підтверджує прохідний результат, що живий запит спрацює?
Ні. Цей результат охоплює лише вставлену відповідь та деталі запиту, внесені тут. Перенаправлення, кешовані відповіді, зміна правил сервера, розширення браузера та фактична відповідь після префлайту все одно можуть змінити результат.

Хто найчастіше використовує цей інструмент для перевірки заголовків?
Інструмент корисний для фронтенд- і бекенд-розробників, розробників API-платформ, системних інженерів (Operations), а також для всіх, кому потрібно перевірити, чи зможе браузерний код прочитати відповідь сервера або чи схвалює OPTIONS-відповідь подальший метод і заголовки.