Що таке CORS (Cross-Origin Resource Sharing)?

Уяви собі ситуацію:
ти розробляєш backend на FastAPI. Твій додаток ідеально працює з frontend, який знаходиться на іншому домені (наприклад, frontend розміщений на http://frontend-app.com, а API — на http://backend-api.com). Ти відправляєш GET-запит з frontend на backend, але замість бажаної відповіді — браузер показує помилку. Як так? Backend-ендпоінт працює, запити через Postman проходять… Що ж відбувається?

Відповідь на це питання — CORS.

CORS (Cross-Origin Resource Sharing) — це механізм, який дозволяє або забороняє браузерам взаємодіяти з ресурсами, що запитуються з інших доменів. Без налаштованого CORS браузери, дотримуючись політики "одного джерела" (Same Origin Policy), блокують такі запити. Це відбувається не через помилки в коді, а через вбудовану систему безпеки браузерів.

CORS: захист від небажаних зв'язків

У сучасному вебі додатки часто розміщуються на різних доменах або піддоменах:

• Frontend (http://frontend-app.com)
• Backend (http://api.backend.com)
• CDN для статики (http://cdn.backend.com)

Без CORS браузер вважатиме, що ідея передавати дані між "різними доменами" (або джерелами) може бути ризиковою. А ризик реальний: неконтрольована взаємодія може призвести до атак, таких як Cross-Site Scripting (XSS) або Cross-Site Request Forgery (CSRF).

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

Як CORS вирішує проблему

CORS додає в заголовки відповіді сервера інструкції для браузера:

• Які методи дозволені? (GET, POST, DELETE, і т.д.)
• Які домени можуть звертатись? (наприклад, http://frontend-app.com)
• Чи дозволені спеціальні заголовки? (наприклад, Authorization)
• Чи дозволено використовувати cookie?

Без цих заголовків браузер автоматично заблокує запити, бо не зможе перевірити, чи "безпечно" віддавати дані.

---

Механізм роботи CORS

Все почалося з "політики одного джерела", якій підпорядковуються браузери. Вона каже:

• Запити вважаються безпечними, якщо вони відбуваються в межах одного джерела. Джерело (origin) визначається комбінацією:
  • Протоколу (наприклад, HTTPS)
  • Хоста (домену)
  • Порту (80, 443 і т.д.)

Приклад одного джерела:

• https://mydomain.com:443 → https://mydomain.com:443: ок
• https://mydomain.com → http://mydomain.com: НЕ ок (різні протоколи)
• https://sub.mydomain.com → https://mydomain.com: НЕ ок (різні піддомени)

Щоб взаємодіяти між "різними джерелами", потрібен CORS.

Preflight Request (попередній запит)

Інколи браузер перед відправкою основного запиту робить спеціальний "попередній запит" типу OPTIONS.

Цей запит дозволяє браузеру спитати у сервера:

• "Дозволяєш мені надіслати запит з такими параметрами і заголовками?"
• "Які методи і заголовки ти підтримуєш?"

Якщо сервер відповідає позитивно (додає потрібні заголовки в відповідь), браузер виконує основний запит. Інакше — блокує його.

Приклад попереднього запиту:

OPTIONS /data HTTP/1.1
Host: api.backend.com
Origin: http://frontend-app.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

Відповідь сервера:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://frontend-app.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Authorization

Якщо сервер не відповість подібним чином, браузер скаже: "Ні, це небезпечно", і заблокує запит.

---

Навіщо це потрібно програмісту?

Без розуміння CORS твій backend буде:

1. Недоступним для frontend.
2. Або — в гіршому випадку — вразливим для атак, якщо CORS налаштований необережно (наприклад, дозволяє запити звідусіль).

Тому кожен розробник API має розуміти, як увімкнути CORS і правильно його налаштувати:

• Дозволяти тільки ті джерела, які справді повинні взаємодіяти.
• Обмежувати методи і заголовки, щоб мінімізувати можливе використання API зловмисниками.

---

Де CORS викликає помилки?

Під час налагодження проблем з CORS ти можеш зустріти такі неприємні випадки:

• Помилка "Access-Control-Allow-Origin missing".
  Браузер каже: "Я не бачу заголовка Access-Control-Allow-Origin, отже запит заблоковано". Це відбувається, якщо сервер не додає CORS у свою відповідь або не налаштований для роботи з твоїм джерелом.
• Помилка "Request header field is not allowed".
  Клієнтський запит містить заголовок (наприклад, Authorization), який не дозволений сервером. Таке часто трапляється при авторизації.
• "CORS policy does not allow...".
  Це універсальна помилка, яка говорить, що сервер не відповідає вимогам браузера.

Якщо натрапив на проблему з CORS, перше місце для перевірки — це заголовки відповіді сервера.

---

У реальному житті

Уяви, що ти пишеш API для управління банківськими рахунками. Якщо зловмисник зможе відправляти запити з іншого сайту (без твого дозволу), це може призвести до витоку даних або фальшивих транзакцій.

Корисні посилання:

• MDN про CORS
• Специфікація W3C для CORS