Что такое CORS в полном его обьеме
Ранее я уже писал пост «Что такое CORS и почему он необходим», но сейчас хочу дать более цельную и структурную версию, да и время выпало на написание поста.
━━━━━━━━━━ С чего всё начинается ━━━━━━━━━━
Чтобы понять CORS, сначала нужно понять SOP — Same-Origin Policy. Это базовое правило браузера: страница может свободно читать ответы только от того же origin.
Origin = • схема (http/https) • домен • порт
Например, для браузера это разные origin: • https://site.com • https://api.site.com • http://site.com • https://site.com:8443
SOP появился не просто так. Без него любой вредоносный сайт мог бы открыть страницу у пользователя в браузере, отправить запрос, например, на bank.com, где пользователь уже авторизован, и прочитать ответ с личными данными.
━━━━━━━━━━ Появление CORS ━━━━━━━━━━
Со временем веб стал сложнее. Нормальной стала архитектура, где: • frontend живёт на одном домене • API — на другом
Например: • https://app.example.com • https://api.example.com
По строгой логике SOP такой frontend не должен был бы читать ответы API, потому что origin уже разный.
И вот здесь появился CORS — Cross-Origin Resource Sharing. Это не “отключение SOP”, а контролируемое исключение из него.
То есть сервер сам говорит браузеру: • кому можно читать ответ • какие методы разрешены • какие заголовки допустимы • можно ли передавать credentials
Например: • Access-Control-Allow-Origin: https://app.example.com Это значит: браузер может отдать ответ с этого origin.
До CORS часто использовали более костыльные обходы, самый известный — JSONP. Там данные тянули через через <script>, а браузер фактически исполнял чужой JavaScript.
━━━━━━━━━━ Простые и сложные запросы ━━━━━━━━━━
В практике CORS обычно говорят о простых и сложных запросах. Простой запрос браузер отправляет сразу, без preflight-проверки OPTIONS.
Обычно это: • методы GET, HEAD, POST • для POST — только определённый контент
Важно: “простой” не значит “безопасный” или “без чувствительных данных”. Это лишь означает, что запрос попадает под более мягкие правила браузера.
Сложный запрос — это тот, перед которым браузер сначала отправляет preflight методом OPTIONS.
Так происходит, если: • используется PUT, PATCH, DELETE • есть заголовки вроде Authorization, X-CSRF-Token, X-Api-Key • используется Content-Type: application/json
В предварительном запросе участвуют заголовки: • Origin — кто отправляет запрос • Access-Control-Request-Method — какой метод хочет использовать браузер • Access-Control-Request-Headers — какие нестандартные заголовки хочет отправить
А сервер отвечает, например: • Access-Control-Allow-Origin — кому можно • Access-Control-Allow-Methods — какие методы разрешены • Access-Control-Allow-Headers — какие заголовки разрешены • Access-Control-Allow-Credentials — можно ли отправлять cookies / auth-данные
━━━━━━━━━━ Защищает ли CORS от CSRF или от SSRF ━━━━━━━━━━
Любимый вопрос на собесах и поэтому я его добавил суда)
От CSRF нет, полноценно не защищает. CSRF — это когда браузер жертвы отправляет запрос на доверенный сайт, где пользователь уже авторизован. CORS может помешать злоумышленнику прочитать ответ, но не всегда мешает самому запросу уйти.
Поэтому от CSRF защищаются не CORS, а: • SameSite cookies • CSRF-токенами • проверкой Origin / Referer • требованиями к нестандартным заголовкам
От SSRF нет, вообще. SSRF — это уже не браузерная история, а серверная. Если backend сам делает запрос по URL, который дал пользователь, CORS тут не участвует вообще.
От SSRF защита строится иначе: • zero trust, изоляция всех сервисов между собой
