CORS-помилка в консолі браузера — один із найпоширеніших і водночас найбільш незрозумілих для новачків моментів у веброзробці: запит ніби надіслано, сервер ніби відповів, але браузер відмовляється віддати відповідь коду сторінки.
Політика єдиного джерела
За замовчуванням браузери діють за Same-Origin Policy: JavaScript-код зі сторінки одного джерела (домен + протокол + порт) не може читати відповіді від запитів до іншого джерела. Це фундаментальний захисний механізм, що не дозволяє шкідливому скрипту на одному сайті красти дані з іншого сайту, де користувач авторизований.
Як CORS послаблює цю політику
CORS (Cross-Origin Resource Sharing) — це набір HTTP-заголовків, якими сервер явно дозволяє певним (або всім) зовнішнім джерелам читати свої відповіді. Ключовий заголовок — Access-Control-Allow-Origin, що вказує, які домени мають дозвіл.
Чому це блокує браузер, а не сервер
Важливо розуміти: сервер практично завжди отримує запит і відповідає на нього нормально — блокування відбувається на боці браузера, який відмовляється передати відповідь JavaScript-коду сторінки через відсутність потрібних CORS-заголовків. Саме тому запит "працює" в Postman (де немає політики Same-Origin), але падає з CORS-помилкою в браузері.
Навіщо це потрібно
- Діагностувати CORS-помилку та зрозуміти, яких саме заголовків не вистачає на сервері.
- Перевірити, чи правильно налаштований API дозволяє запити з потрібного домену.
- Зрозуміти різницю між "простими" запитами та preflight-запитами (OPTIONS).
CORS не захищає сервер від атак
CORS — це механізм, що обмежує лише браузер і лише JavaScript-код на веб-сторінці; він жодним чином не заважає зловмиснику надіслати той самий запит напряму через curl, Postman чи власний скрипт у бекенді, минаючи браузер повністю. Тому CORS ніколи не можна розглядати як заміну справжньої авторизації на сервері — це інструмент керування тим, які сайти можуть використовувати API з браузера користувача, а не бар'єр проти атак загалом.