PROEVERYTHING & even more
Код • • • Читати оригінал на Dev • 2 хв читання • 0

Як працюють Same-Origin Policy та CORS у веббраузерах

Сучасний браузер є одним із найбільш ворожих середовищ виконання коду, де кожен відкритий штаб може нести загрозу для банківських сесій або персональних даних користувачів. Модель безпеки веббраузера виступає критичним бар'єром між хаосом сторонніх скриптів та конфіденційною інформацією. Розуміння фундаментальних механізмів захисту, таких як Same-Origin Policy та CORS, є обов'язковим для розробників, оскільки будь-яка помилка в їхній імплементації робить систему вразливою до XSS, CSRF та викрадення сесій.

#веббезпека #Same-Origin Policy #CORS #розробка #кібербезпека
Як працюють Same-Origin Policy та CORS у веббраузерах — ілюстрація до новини в рубриці «Код»
Як працюють Same-Origin Policy та CORS у веббраузерах — ілюстрація до новини в рубриці «Код» · Джерело зображення: Dev

За даними Dev, браузерна модель безпеки — це не просто набір додаткових функцій, а «несучі стіни» архітектури інтернету. Коли розробник ігнорує ці правила, він фактично будує систему на піску, що дозволяє хакерам легко реалізовувати атаки для викрадення cookies, виконання скриптів від імені користувача або витоку даних через бічні канали.

Same-Origin Policy (SOP) як фундамент захисту

Найстаріша та найважливіша стіна безпеки — Same-Origin Policy (SOP). Вона обмежує взаємодію документів і скриптів з ресурсами інших джерел. Джерело (origin) визначається як комбінація протоколу, хоста та порту. Наприклад, запити між https://app.com/page та https://app.com/api вважаються однаковими, тоді як будь-яка зміна протоколу (http vs https), піддомену або порту створює різні джерела.

SOP блокує можливість JavaScript на сайті evil.com читати DOM, cookies або відповіді з сайту bank.com. Однак важливо розуміти критичний нюанс: SOP не блокує відправку крос-доменних запитів, вона лише забороняє їх читання. Саме ця особливість робить атаки типу CSRF можливими — браузер дозволяє відправити форму з куками, але блокує можливість хакерському скрипту побачити результат цієї дії.

CORS: контрольований доступ до ресурсів

Cross-Origin Resource Sharing (CORS) є свідомим винятком із правил SOP. Це механізм, за допомогою якого сервери дозволяють запити з конкретних джерел через спеціальні HTTP-заголовки. Процес взаємодії поділяється на два типи:

  • Прості запити (GET, POST з безпечними типами контенту) виконуються напряму, і браузер блокує доступ до відповіді, якщо відсутні правильні заголовки.
  • Запити з префлайтом (custom headers, DELETE, PUT, JSON bodies) спочатку викликають метод OPTIONS. Сервер повинен підтвердити дозволи через заголовок Access-Control-Allow-Origin.

Поширена помилка розробників полягає у використанні комбінації Access-Control-Allow-Origin: разом із Access-Control-Allow-Credentials: true, що браузери відхиляють. Проте часто зустрічається вразливий паттерн динамічного відображення заголовка Origin без належної валідації. Такий підхід дозволяє будь-якому джерелу виконувати запити з авторизаційними даними, повністю нівелюючи захист SOP.

Для забезпечення безпеки розробники повинні уникати використання універсальних символів у CORS та ретельно валідувати кожен вхідний заголовок джерела перед наданням доступу до даних.

Контекст для України

Для українських розробників та команд важливо розуміти, що з ростом популярності локальних SaaS-платформ та фінансових сервісів, питання безпеки крос-доменних запитів стає критичним. Наприклад, інтеграція українських платіжних шлюзів або систем авторизації вимагає чіткого налаштування CORS для запобігання підміни даних. Також актуальність цієї теми підсилюється через активність кіберзлочинців у регіоні, що робить знання про вразливості типу XSS та CSRF базовою компетенцією для будь-якого українського Fullstack-інженера.

Часті запитання

Чим відрізняється Same-Origin Policy від CORS?
Same-Origin Policy є базовим механізмом безпеки, який забороняє скриптам читати дані з інших джерел. CORS працює як свідомий виняток до цих правил, дозволяючи серверам явно вказувати, яким саме стороннім джерелам можна отримувати доступ до ресурсів через спеціальні HTTP-заголовки.
Чому атаки типу CSRF можливі при наявності SOP?
Це відбувається тому що Same-Origin Policy не блокує саму відправку крос-доменних запитів, а лише забороняє їх читання. Браузер дозволяє відправити форму з куками на інший сайт, але хакерський скрипт не може побачити результат цієї дії через обмеження SOP.
Яка поширена помилка розробників при налаштуванні CORS?
Розробники часто використовують комбінацію Access-Control-Allow-Origin разом із Access-Control-Allow-Credentials: true, що браузери відхиляють. Також вразливим є динамічне відображення заголовка Origin без належної валідації, що дозволяє будь-якому джерелу виконувати запити з авторизаційними даними.
Telegram

Свіжі новини у нашому Telegram

Отримуйте миттєві сповіщення про нові публікації в рубриці «Код»

@procodeandevenmore