CORS (Cross-Origin Resource Sharing)

Щоб зрозуміти, що таке CORS, потрібно розібратися, як браузер працює із запитами між сайтами. За замовчуванням діє політика одного джерела – Same-Origin Policy (SOP). Вона обмежує можливість JavaScript-коду однієї сторінки отримувати дані з іншого джерела без спеціального дозволу.

Джерелом вважається комбінація протоколу, домену та порту. Наприклад, https://example.com і https://api.example.com вважаються різними джерелами, хоча належать до одного основного домену. Аналогічно відрізняються адреси з HTTP і HTTPS або різними портами.

По суті, CORS – це механізм, за допомогою якого сервер повідомляє браузеру, чи дозволено сторінці з іншого джерела читати відповідь на запит. Якщо відповідний дозвіл відсутній, браузер не надає JavaScript доступу до отриманих даних.

Такий підхід необхідний у сучасних вебзастосунках, де інтерфейс і серверна логіка часто працюють окремо. Наприклад, frontend інтернет-магазину може розміщуватися на одному домені, а API з інформацією про товари, замовлення та користувачів – на іншому.

Під час реалізації API-інтеграцій правильне налаштування міждоменного доступу допомагає організувати обмін даними між клієнтською частиною застосунку та зовнішніми сервісами без порушення браузерних обмежень.

Механізм заснований на спеціальних HTTP-заголовках, які передаються між браузером і сервером. Коли JavaScript надсилає запит до іншого джерела, браузер зазначає його походження в заголовку Origin.

Сервер аналізує запит і повертає відповідь із налаштуваннями доступу. Наприклад, заголовок Access-Control-Allow-Origin повідомляє, якому джерелу дозволено читати дані. Спрощено процес виглядає так:

• користувач відкриває вебзастосунок;
• frontend надсилає запит до API на іншому джерелі;
• браузер додає заголовок Origin;
• сервер обробляє запит і повертає CORS-заголовки;
• браузер перевіряє отримані дозволи;
• якщо умови дотримані, JavaScript отримує доступ до відповіді.

Наприклад, інтерфейс на https://shop.example.com звертається до API на https://api.example.com. Якщо сервер дозволяє запити з https://shop.example.com, браузер надає застосунку можливість прочитати отримані дані.

Однак якщо потрібні заголовки відсутні, браузер блокує доступ JavaScript до відповіді. При цьому сам HTTP-запит у деяких випадках уже міг бути надісланий та оброблений сервером.

Цей механізм особливо актуальний для застосунків на React.js, Vue та Angular, де користувацький інтерфейс активно взаємодіє з backend через API.

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

• frontend і backend розташовані на різних доменах;
• сайт використовує API стороннього сервісу;
• вебзастосунок звертається до окремого сервера авторизації;
• адміністративна панель працює на піддомені;
• застосунок отримує дані з хмарної інфраструктури;
• кілька вебсервісів використовують спільний API.

Наприклад, інтернет-магазин може отримувати дані про товари з окремого backend-сервісу, а особистий кабінет – звертатися до API для перегляду замовлень. Якщо інтерфейс і сервер перебувають на різних джерелах, CORS визначає, чи дозволено браузеру передавати отриману відповідь JavaScript-коду сторінки.

Важливо розуміти, що такі обмеження діють саме в браузері. У разі прямого звернення до API із серверного застосунку, наприклад через backend на Node.js, браузерна перевірка міждоменного доступу зазвичай не застосовується.

Тому CORS потрібен передусім для безпечної взаємодії клієнтської частини застосунку з ресурсами інших джерел, а не для обмеження всіх звернень до сервера.

Робота механізму залежить від кількох HTTP-заголовків. Вони дозволяють серверу вказувати дозволені джерела, методи запитів, додаткові заголовки та умови передавання облікових даних.

1. Access-Control-Allow-Origin визначає, яким джерелам дозволено читати відповідь. Наприклад, сервер може вказати конкретний домен або використати символ * для загальнодоступних ресурсів, які не потребують передавання облікових даних.
2. Access-Control-Allow-Methods перелічує допустимі HTTP-методи, наприклад GET, POST, PUT або DELETE. Цей заголовок використовується під час попередньої перевірки запиту.
3. Access-Control-Allow-Headers визначає, які додаткові заголовки клієнт може передавати. Це важливо, коли запит містить Authorization, нестандартні заголовки або певні типи Content-Type.
4. Access-Control-Allow-Credentials повідомляє браузеру, чи дозволено надавати JavaScript доступ до відповіді на міждоменний запит з обліковими даними, наприклад cookie.
5. Access-Control-Max-Age визначає, як довго браузер може кешувати результат попередньої перевірки.

Наприклад, сервер може повернути:

Access-Control-Allow-Origin: https://shop.example.com

Це означає, що JavaScript сторінки із зазначеного джерела зможе прочитати відповідь за умови виконання інших вимог CORS.

Для запитів з обліковими даними не можна використовувати Access-Control-Allow-Origin: *. У такому випадку необхідно вказати конкретне дозволене джерело.

Не всі міждоменні запити виконуються однаково. Для певних HTTP-методів і заголовків браузер спочатку надсилає попередній запит – preflight.

Він використовує метод OPTIONS і дозволяє перевірити, чи дозволяє сервер майбутній запит.

Наприклад, якщо вебзастосунок надсилає POST-запит із Content-Type: application/json, браузер зазвичай спочатку перевіряє, чи приймає сервер такий метод і заголовок від цього джерела. Процес складається з кількох етапів:

1. Браузер надсилає OPTIONS-запит.
2. Сервер повертає дозволені методи, заголовки та джерела.
3. Браузер перевіряє відповідь.
4. Якщо умови виконані, надсилається основний запит.
5. Відповідь основного запиту також проходить перевірку CORS.

Preflight допомагає браузеру перевірити дозволи до надсилання певних міждоменних запитів. Однак він не замінює перевірку авторизації та прав доступу на сервері.

Налаштування CORS зазвичай виконується на backend, API-сервері, reverse proxy або API Gateway. Конкретний спосіб залежить від використовуваних технологій та архітектури проєкту.

Основне завдання розробника – визначити, яким джерелам дозволено отримувати відповіді сервера та які запити мають підтримуватися. Процес включає:

• визначення дозволених доменів і піддоменів;
• налаштування Access-Control-Allow-Origin;
• зазначення необхідних HTTP-методів;
• дозвіл потрібних заголовків;
• налаштування роботи з cookie й авторизацією;
• обробку попередніх OPTIONS-запитів;
• перевірку поведінки застосунку в різних середовищах.

Наприклад, для API інтернет-магазину можна дозволити звернення з браузерного інтерфейсу https://shop.example.com, але не відкривати доступ усім стороннім сайтам.

У проєктах із кількома середовищами дозволені джерела можуть відрізнятися. Локальна розробка використовує localhost, тестова версія – staging-домен, а робоча – production-адресу.

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

Важливо враховувати й роботу кешування: якщо сервер динамічно повертає дозволений Origin зі списку довірених джерел, для коректної обробки кешем зазвичай потрібен заголовок Vary: Origin.

CORS Error – поширена помилка під час розробки сайтів і застосунків, які звертаються до API на іншому джерелі.

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

Найчастіше помилка виникає, якщо:

• сервер не повертає Access-Control-Allow-Origin;
• джерело запиту відсутнє у списку дозволених;
• сервер не обробляє OPTIONS-запит;
• не дозволений потрібний HTTP-метод;
• відсутній дозвіл на додатковий заголовок;
• використовується wildcard разом із передаванням облікових даних;
• запит перенаправляється або завершується мережевою помилкою;
• конфігурації staging і production відрізняються.

Наприклад, frontend може успішно працювати локально, але після деплою перестати отримувати дані з API. Причина може полягати в тому, що production-домен не додали до списку дозволених джерел.

Для діагностики розробники використовують DevTools браузера. На вкладці Network можна перевірити Origin, параметри preflight-запиту й заголовки відповіді, а на вкладці Console – побачити повідомлення про помилку.

Такі сценарії бажано перевіряти в межах QA/QC тестування сайту, особливо якщо проєкт використовує авторизацію, форми, платежі та сторонні API.

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

• авторизацію та перевірку прав користувача;
• захист від CSRF;
• фільтрацію й валідацію вхідних даних;
• HTTPS і шифрування з’єднання;
• обмеження частоти запитів;
• контроль доступу до ресурсів API.

Наприклад, зловмисник може надіслати запит безпосередньо на сервер, не використовуючи браузер. У такому випадку CORS сам по собі не запобігатиме зверненню. Саме тому backend має самостійно перевіряти токени, сесії, ролі та права доступу.

Неправильна конфігурація також може створювати ризики. Якщо сервер автоматично дозволяє будь-який Origin і водночас допускає запити з обліковими даними, це може призвести до розкриття конфіденційних відповідей стороннім вебсторінкам.

Тому правила міждоменного обміну потрібно розглядати як один із компонентів загальної системи безпеки.

Для бізнесу CORS важливий насамперед для стабільної роботи цифрових продуктів. Якщо міждоменні запити налаштовані неправильно, користувачі можуть зіткнутися з неробочими формами, відсутністю даних в особистому кабінеті, помилками завантаження каталогу або збоями окремих функцій.

Для розробників це необхідна частина взаємодії frontend і backend. Коректна конфігурація допомагає організувати обмін даними між застосунками, API та хмарними сервісами, не вимикаючи обмеження браузера заради зручності розробки.

Особливо важливий цей механізм під час створення складних продуктів: SaaS-платформ, маркетплейсів, інтернет-магазинів і корпоративних вебсистем. У таких проєктах веброзробка часто передбачає кілька окремих сервісів, яким необхідно безпечно взаємодіяти між собою.

У підсумку, CORS – це механізм керування міждоменним доступом у браузері. Він допомагає вебзастосункам працювати з ресурсами інших джерел, зберігаючи контроль над тим, які сторінки можуть читати відповіді сервера. Правильне налаштування забезпечує передбачувану роботу API, знижує ризик помилок інтеграції та підтримує безпеку цифрового продукту.