Origin va Same-Origin Policy: brauzer xavfsizligi va CORS

Qisqacha: Origin — URL'ning uch qismi birgalikda: sxema, host va port (https://example.com:443). Same-Origin Policy qoidasi bo'yicha bir origin'dagi sahifa boshqa origin'ning javoblari va ma'lumotlarini o'qiy olmaydi. So'rov yuborish mumkin, javobni o'qish esa yo'q. Server ruxsat bermoqchi bo'lsa, CORS sarlavhalarini (Access-Control-Allow-Origin) qaytaradi.

Bu darsda

• Ikki URL bir origin'dami yoki yo'qmi — bir qarashda aniqlaysiz.
• Same-Origin Policy nimani taqiqlashini va nimaga ruxsat berishini bilasiz.
• "Site" va "origin" farqini tushuntira olasiz.
• CORS xatosini o'qiysiz va u qaysi tomonda tuzatilishini bilasiz.
• Preflight (OPTIONS) so'rovi qachon va nega yuborilishini ko'rasiz.

Oldin bilishingiz kerak: URL anatomiyasi, HTTP sarlavhalari, MIME turlari, cookie va kesh, HTTP metodlari va status kodlari.

1. Nega bu kerak?

Brauzerda ikkita tab ochiq. Birinchisida — bankingiz kabineti, siz login qilgansiz. Ikkinchisida — tasodifiy o'yin sayti.

Cookie darsida ko'rdik: brauzer bank cookie'sini bankka yuboriladigan so'rovlarga o'zi qo'shadi. SameSite begona saytdan kelgan so'rovlarni cheklaydi, lekin cookie SameSite=None bo'lsa, u ham yordam bermaydi. Endi tasavvur qiling: o'yin saytidagi skript yashirincha bank API'siga so'rov yuboradi. Brauzer cookie'ni qo'shadi. Bank "bu mijozning o'zi" deb, hisob raqami va qoldiqni qaytaradi. Skript javobni o'qib, hujumchiga jo'natadi.

Hech qanday cheklov bo'lmasa, istalgan sayt siz kirgan barcha boshqa saytlardagi ma'lumotingizni o'qiy olardi: pochta, bank, ijtimoiy tarmoq.

Brauzer bunga yo'l qo'ymaydi. Uning asosiy xavfsizlik qoidasi — Same-Origin Policy. Bu darsda u qanday ishlashini va dasturchilar har kuni duch keladigan CORS xatosi qayerdan kelishini ko'ramiz.

2. Origin nima?

2.1 Uch qism

URL anatomiyasi darsida URL'ni qismlarga ajratgan edik. Origin (kelib chiqish manbai) — ulardan uchtasi birgalikda:

origin = sxema + host + port

https://example.com:443/kurslar?id=5#dars
└─┬─┘   └────┬────┘ └┬┘
sxema      host    port

Yo'l (/kurslar), so'rov parametrlari (?id=5) va fragment (#dars) origin'ga kirmaydi.

Ikki URL'ning uchala qismi ham aynan bir xil bo'lsa — ular bir origin'da (same-origin). Bittasi farq qilsa ham — har xil origin'da (cross-origin).

O'xshatish: ko'p qavatli uy. Sxema — ko'cha, host — uy raqami, port — kvartira raqami. Bitta kvartira ichida xonalar (yo'llar) har xil bo'lishi mumkin — lekin bu bitta oila. Qo'shni kvartira — boshqa oila, garchi uy bitta bo'lsa ham.

2.2 Solishtirish jadvali

Asosiy sahifa: https://example.com/profil. Uning origin'i https://example.com (port ko'rsatilmagan — HTTPS uchun standart 443).

E'tibor bering: api.example.com — o'sha kompaniyaning subdomeni. Lekin brauzer uchun baribir boshqa origin. Origin qoidasi qat'iy: "o'xshash" degan tushuncha yo'q.

2.3 JavaScript'da origin

URL anatomiyasi darsidagi URL vositasi origin'ni tayyor hisoblab beradi:

const manzil = new URL("https://example.com:443/kurslar?id=5");
console.log(manzil.origin); // https://example.com

const api = new URL("https://api.example.com/v1/mahsulotlar");
console.log(api.origin); // https://api.example.com

const lokal = new URL("http://localhost:5173/");
console.log(lokal.origin); // http://localhost:5173

Birinchi misolda standart port 443 origin'da ko'rsatilmadi — u "ko'rinmas" holda bor. Uchinchi misolda 5173 standart emas, shuning uchun u origin'ning bir qismi.

Tekshirib ko'ring: http://localhost:3000 va http://localhost:5173 — bir origin'mi?

3. Same-Origin Policy nimani cheklaydi

3.1 Asosiy g'oya: yuborish mumkin, o'qish — yo'q

Same-Origin Policy (SOP, bir manba siyosati) — brauzer qoidasi: bir origin'dagi sahifa boshqa origin'dagi ma'lumotni o'qiy olmaydi.

Eng muhim nuqta — so'z "o'qish". Pochtani eslang. Siz istalgan manzilga xat yubora olasiz — pochta bunga to'sqinlik qilmaydi. Lekin qo'shningizning pochta qutisini ochib, unga kelgan xatlarni o'qiy olmaysiz.

Brauzerda ham shunday:

• example.org dagi sahifa example.com ga so'rov yubora oladi.
• Lekin example.com qaytargan javobni o'qiy olmaydi — agar example.com o'zi ruxsat bermasa.

3.2 Nima taqiqlanadi

Boshqa origin'ning:

• fetch bilan olingan javobini JavaScript'da o'qish (JSON, matn);
• boshqa oynadagi yoki iframe'dagi sahifa tarkibini (DOM) o'qish va o'zgartirish;
• brauzer xotirasidagi ma'lumotlarini (localStorage — brauzer xotirasi darsida ko'ramiz).

fetch — JavaScript'dan HTTP so'rov yuborish vositasi. Uni fetch asoslari darsida o'rganamiz. Hozir bilish kifoya: bu kod ichidan yuborilgan so'rov.

3.3 Nima ruxsat etiladi

Veb boshidanoq bir-biriga bog'langan. Shuning uchun boshqa origin'dagi resursni sahifaga joylashtirish mumkin:

• <img src="https://example.org/logo.png"> — rasm ko'rinadi. Lekin JavaScript uning piksellarini ruxsatsiz o'qiy olmaydi.
• <link rel="stylesheet" href="https://cdn.example.org/stil.css"> — stil qo'llanadi.
• <script src="https://cdn.example.org/kutubxona.js"> — skript ishga tushadi.
• <form action="https://example.org/..." method="post"> — forma yuboriladi.
• <iframe src="https://example.org/xarita"> — boshqa sayt ko'rsatiladi, lekin ichiga kirib bo'lmaydi.

Ya'ni brauzer boshqa sayt resursini ishlatishga ruxsat beradi, lekin uning mazmunini kodingizga berishga — yo'q.

Tekshirib ko'ring: SOP o'yin saytiga bankka so'rov yuborishni taqiqlaydimi?

4. Site va origin farqi

Origin'dan tashqari yana bir yaqin atama bor — site (sayt). Ular turli qoidalarda ishlatiladi, shuning uchun farqini bilish kerak.

• Origin = sxema + to'liq host + port. Qat'iy.
• Site = sxema + asosiy domen (ro'yxatdan o'tkaziladigan qism). Subdomen va port hisobga olinmaydi.

"Asosiy domen" qanday aniqlanadi? example.com da — example.com. .uz saytlarida ham shunday. Lekin ba'zi domenlarda har bir foydalanuvchiga alohida subdomen beriladi. Masalan, GitHub Pages'da ali.github.io va vali.github.io — ikki xil odamning sayti. Shuning uchun github.io maxsus ro'yxatda turadi, va bu ikki manzil boshqa site hisoblanadi.

Bu nima uchun kerak? Cookie darsidagi SameSite atributi aynan site bo'yicha ishlaydi. app.example.com dan api.example.com ga so'rov "same-site" — SameSite=Strict cookie ham yuboriladi. SOP esa origin bo'yicha ishlaydi — javobni o'qish uchun baribir ruxsat kerak.

5. CORS: server ruxsat beradi

5.1 Muammo: o'z API'ingiz ham "begona"

Real loyihada frontend va backend ko'pincha alohida manzilda turadi: sayt — https://example.com, API — https://api.example.com. Biz bilamizki, bu ikki origin. SOP bo'yicha sayt o'z API'sining javobini ham o'qiy olmaydi!

Yechim — CORS (Cross-Origin Resource Sharing — origin'lar orasida resurs almashish). Bu server brauzerga "shu origin'ga ruxsat beraman" deb aytadigan usul. Ruxsat — javob sarlavhalarida.

5.2 Qanday ishlaydi

1. https://example.com dagi skript https://api.example.com/mahsulotlar ga so'rov yuboradi.
2. Brauzer so'rovga o'zi sarlavha qo'shadi: Origin: https://example.com — "bu so'rov shu origin'dan".
3. Server javob beradi va (agar ruxsat bersa) qo'shadi: Access-Control-Allow-Origin: https://example.com.
4. Brauzer javob sarlavhasini so'rovdagi origin bilan solishtiradi. Mos keldi — javobni skriptga beradi. Mos kelmadi yoki sarlavha yo'q — javobni yashiradi va konsolda xato chiqaradi.

Muhim: tekshiruvni brauzer qiladi. Server faqat ruxsat sarlavhasini qo'yadi yoki qo'ymaydi.

5.3 Terminalda ko'ramiz

curl bilan brauzerni "o'ynaymiz" — Origin sarlavhasini o'zimiz qo'shamiz. GitHub API'si:

curl -I -H "Origin: https://example.com" https://api.github.com/zen

Natija (qisqartirilgan):

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: ETag, Link, Location, ...

* — "istalgan origin'ga ruxsat". GitHub API'si ochiq, uni istalgan saytdan chaqirish mumkin.

Endi Google bosh sahifasi:

curl -I -H "Origin: https://example.com" https://www.google.com

Javob HTTP/1.1 200 OK, lekin sarlavhalar orasida Access-Control-Allow-Origin yo'q. Demak, https://example.com dagi skript bu javobni fetch bilan o'qiy olmaydi. Brauzer uni yashiradi.

E'tibor bering: curl ikkala javobni ham bemalol ko'rsatdi. CORS — faqat brauzer qoidasi. curl, Postman, serverdagi Node.js kodi unga bo'ysunmaydi. Chunki ular sizning bank cookie'laringizni avtomatik qo'shib yurmaydi — himoya qilinadigan narsa yo'q.

5.4 CORS xatosini o'qish

Brauzer javobni yashirganda konsolda shunday qizil yozuv chiqadi:

Access to fetch at 'https://api.example.com/mahsulotlar' from origin
'http://localhost:5173' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource.

Tarjimasi: "http://localhost:5173 origin'idan https://api.example.com/mahsulotlar ga fetch so'rovi CORS siyosati bilan bloklandi: so'ralgan resursda Access-Control-Allow-Origin sarlavhasi yo'q."

Uch muhim xulosa:

• So'rov serverga yetib borgan va server javob bergan. DevTools'ning Network panelida uning status kodini ham ko'rasiz.
• Brauzer faqat javobni kodingizdan yashirgan.
• Tuzatish joyi — server: u kerakli sarlavhani qaytarishi kerak.

5.5 Asosiy CORS sarlavhalari

Hammasi server javobida keladi. Brauzer so'rovda faqat Origin (va preflight'da ikkita Access-Control-Request-...) yuboradi.

Tekshirib ko'ring: Frontend dasturchi konsolda CORS xatosini ko'rdi va fetch kodini o'n marta qayta yozdi. Xato ketmadi. Nega?

6. Preflight: "oldindan so'rab ko'rish"

6.1 Oddiy va "murakkab" so'rovlar

Ba'zi so'rovlar "oddiy" hisoblanadi — ularni oddiy HTML forma ham yubora olardi. Masalan, GET yoki oddiy forma ma'lumotli POST. Brauzer ularni to'g'ridan-to'g'ri yuboradi, keyin javobdagi ruxsatni tekshiradi.

Lekin quyidagilardan biri bo'lsa, so'rov "murakkab":

• metod PUT, PATCH yoki DELETE;
• Content-Type: application/json;
• maxsus sarlavha, masalan Authorization (kirish tokeni).

Bunday so'rovni oddiy forma yubora olmaydi. Eski serverlar bunga tayyor bo'lmasligi mumkin. Shuning uchun brauzer asosiy so'rovdan oldin serverdan ruxsat so'raydi. Bu preflight (uchishdan oldingi tekshiruv) deyiladi. U OPTIONS metodi bilan yuboriladi.

O'xshatish: mehmonga borishdan oldin qo'ng'iroq qilasiz: "Beshtamiz bilan borsak bo'ladimi?" Uy egasi "ha" desa — borasiz. Yo'q desa — bormaysiz.

6.2 Haqiqiy preflight

Brauzer yuboradigan preflight'ni curl bilan takrorlaymiz. -X OPTIONS — metodni tanlash:

curl -i -X OPTIONS https://api.github.com/user \
  -H "Origin: https://example.com" \
  -H "Access-Control-Request-Method: PUT" \
  -H "Access-Control-Request-Headers: content-type,authorization"

Tarjimasi: "Men https://example.com dan kelyapman. PUT metodi bilan, Content-Type va Authorization sarlavhalari bilan so'rov yubormoqchiman. Mumkinmi?"

GitHub javobi (qisqartirilgan):

HTTP/1.1 204 No Content
access-control-allow-origin: *
access-control-allow-methods: GET, POST, PATCH, PUT, DELETE
access-control-allow-headers: Authorization, Content-Type, ...
access-control-max-age: 86400

• 204 No Content — "hammasi joyida, tana yo'q" (status kodlari).
• Metodlar ro'yxatida PUT bor, sarlavhalar ro'yxatida Authorization va Content-Type bor — ruxsat.
• max-age: 86400 — "bu javobni 1 kun eslab qol, har safar so'rama".

Shundan keyingina brauzer haqiqiy PUT so'rovini yuboradi. DevTools'ning Network panelida bitta fetch uchun ikkita qator ko'rasiz: avval OPTIONS (preflight), keyin asosiy so'rov.

Tekshirib ko'ring: fetch bilan GET /mahsulotlar so'rovi yuborildi, maxsus sarlavhalarsiz. Preflight bo'ladimi?

7. Kompyuteringizda: localhost va CORS

Siz loyiha yozyapsiz. Frontend http://localhost:5173 da, backend http://localhost:3000 da ishlayapti. Frontend backend'ga fetch qiladi — va CORS xatosi chiqadi.

Hayron bo'lmang: portlar farq qiladi, demak origin'lar ham farq qiladi. Ikki yo'l bor:

1. Backend'da CORS'ni yoqish. Server javobiga Access-Control-Allow-Origin: http://localhost:5173 qo'shiladi. Express'da buni cors degan kichik paket qiladi — CORS chuqur darsida o'rnatamiz.
2. Dev proxy. Vite kabi frontend vositasi so'rovni o'zi backend'ga uzatadi. Brauzer uchun hammasi bitta origin'dan keladi. Buni Vite dev server darsida sozlaymiz.

Vite, Express — hozircha shunchaki nomlar, ularni o'z qismlarida o'rganamiz. Hozir asosiysi: "localhost'da CORS" — normal holat, xato emas.

8. Hujumchi nigohi

Hujum 1: begona saytdan ma'lumot o'qish. Hujumchining sayti bankka fetch yuboradi. Cookie SameSite=None bo'lsa, brauzer uni qo'shadi. Lekin bank javobida hujumchi origin'iga ruxsat yo'q — brauzer javobni yashiradi. SOP himoya qildi.

Hujum 2: so'rovning o'zi bilan zarar (CSRF). Hujumchi javobni o'qishga urinmaydi. U yashirin forma bilan bankka "pul o'tkaz" so'rovini yuboradi. Formaga SOP to'sqinlik qilmaydi. Cookie avtomatik qo'shilsa, bank so'rovni bajaradi. Himoya: cookie'da SameSite=Lax yoki Strict (cookie darsi) va serverdagi maxsus CSRF tekshiruvi (CSRF darsi).

Hujum 3: dasturchi o'zi eshik ochib qo'yadi. Server har qanday Origin ni ko'r-ko'rona qaytaradi va cookie'ga ham ruxsat beradi:

❌ Access-Control-Allow-Origin: <so'rovdagi har qanday Origin>
❌ Access-Control-Allow-Credentials: true

Endi istalgan sayt foydalanuvchining cookie'si bilan so'rov yuborib, javobni o'qiy oladi — SOP amalda o'chirilgan. Himoya: ruxsat berilgan origin'larni aniq ro'yxat bilan tekshirish.

Brauzer ham bir xavfsizlik to'sig'ini qo'ygan: Access-Control-Allow-Origin: * bilan birga cookie'li so'rov ishlamaydi. Cookie kerak bo'lsa, server aniq origin yozishi shart.

9. Ko'p uchraydigan xatolar

9.1 CORS'ni frontendda "tuzatish"

Internetda ko'p uchraydigan "maslahat": fetch ga mode: "no-cors" qo'shing. Xato ketadi — lekin javob ham ketadi! Brauzer "shaffof bo'lmagan" (opaque) javob beradi: statusi 0, tanasi bo'sh. Kod ma'lumotni baribir o'qiy olmaydi. Tuzatish: faqat serverda.

9.2 "Allow CORS" brauzer kengaytmasi

Kengaytma CORS tekshiruvini sizning brauzeringizda o'chiradi. Sizda ishlaydi, foydalanuvchilarda — yo'q. Bundan tashqari, u yoqiq qolsa, barcha saytlarda himoyangizni pasaytiradi. Tuzatish: kengaytmani o'chiring va serverni sozlang.

9.3 Cookie bilan *

Access to fetch at '...' from origin '...' has been blocked by CORS
policy: The value of the 'Access-Control-Allow-Origin' header in
the response must not be the wildcard '*' when the request's
credentials mode is 'include'.

Tarjimasi: "So'rov cookie bilan (credentials: 'include') yuborilganda, javobdagi Access-Control-Allow-Origin yulduzcha * bo'lishi mumkin emas." Tuzatish: server aniq origin qaytarsin va Access-Control-Allow-Credentials: true qo'shsin.

9.4 OPTIONS ga javob yo'q

Backend PUT /mahsulotlar ni yozgan, lekin OPTIONS so'roviga 404 qaytaradi. Preflight muvaffaqiyatsiz — brauzer asosiy PUT ni umuman yubormaydi. Dasturchi server logida PUT ni qidiradi, lekin u yerda yo'q. Tuzatish: serverda OPTIONS ga to'g'ri CORS sarlavhalari bilan javob berish (odatda CORS paketi buni o'zi qiladi).

9.5 "CORS serverni himoya qiladi" deb o'ylash

CORS foydalanuvchini himoya qiladi, serverni emas. Hujumchi curl bilan istalgan so'rovni yuboradi — CORS unga to'sqinlik qilmaydi. Server o'z API'sini autentifikatsiya va ruxsatlar bilan himoya qilishi kerak.

10. Mashqlar

1-mashq (oson): Origin'larni solishtiring

Har bir juftlik uchun "bir" yoki "boshqa" deb yozing:

1. https://example.com/a va https://example.com/b?x=1 —
2. http://example.com va https://example.com —
3. https://example.com va https://www.example.com —
4. http://localhost:3000 va http://127.0.0.1:3000 —

2-mashq (o'rta): Preflight bo'ladimi?

https://example.com dagi skript https://api.example.com ga so'rov yuboradi. Qaysilarida preflight bo'ladi?

1. GET /mahsulotlar — sarlavhasiz.
2. POST /buyurtma — Content-Type: application/json bilan.
3. DELETE /buyurtma/15.
4. GET /profil — Authorization: Bearer ... sarlavhasi bilan.

3-mashq (qiyin): Terminalda tekshiring

Siz https://example.com dagi sahifadan quyidagi ikki manzilni fetch bilan o'qimoqchisiz:

• https://cdn.jsdelivr.net/npm/dayjs@1.11.13/dayjs.min.js
• https://www.google.com/

curl bilan har birining javob sarlavhalarini Origin bilan oling va grep -i access-control bilan filtrlang. Brauzer qaysi birini o'qishga ruxsat beradi?

curl -sI -H "Origin: https://example.com" \
  https://cdn.jsdelivr.net/npm/dayjs@1.11.13/dayjs.min.js \
  | grep -i access-control

Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: *

curl -sI -H "Origin: https://example.com" https://www.google.com/ \
  | grep -i access-control

11. Real ishda

• Har kuni: frontend va backend alohida portda ishlaganda CORS xatosi — yangi loyihadagi birinchi "to'siq". Endi uni o'qiy olasiz va qayerda tuzatishni bilasiz.
• Backend: CORS sozlamasi — har bir API'ning majburiy qismi. Ruxsat berilgan origin'lar ro'yxati odatda muhit o'zgaruvchisida saqlanadi.
• Chuqurroq: CORS'ni mijoz tomonidan fetch bilan, server tomonidan Express'da batafsil o'rganamiz.
• Intervyu: "CORS nima va nega kerak?", "Preflight qachon yuboriladi?", "Nega Postman'da ishlaydi, brauzerda ishlamaydi?" — juda mashhur savollar.

Xulosa

• Origin = sxema + host + port. Bittasi farq qilsa — boshqa origin.
• Same-Origin Policy: boshqa origin'ga so'rov yuborish mumkin, javobni o'qish — faqat ruxsat bilan.
• Site — asosiy domen bo'yicha (subdomen va portsiz); SameSite cookie shunga tayanadi.
• CORS — server javobidagi Access-Control-Allow-* sarlavhalari; tekshiruvni brauzer qiladi, tuzatish esa serverda.
• "Murakkab" so'rovdan oldin brauzer OPTIONS preflight yuboradi.

Keyingi dars: Tarmoqni terminaldan tekshirish — sayt ochilmasa, muammo Wi-Fi'da, DNS'da yoki serverda ekanini ping, nslookup, tracert va curl bilan qanday topishni o'rganamiz.