Asosiy kontentga o‘tish

Maqolalar

Darslik · 2026-08-16 · ~3 daqiqa o‘qiladi · boshlang'ich

CORS: brauzer aslida nimadan himoya qiladi

#security #api #backend

Mundarija

Frontend'chi kelib aytadi: "API'ing ishlamayapti, CORS xatosi beryapti!" Backend'chi StackOverflow'dan birinchi topilgan javobni ko'chiradi: CORS_ALLOW_ALL_ORIGINS = True — xato yo'qoladi, hamma xursand. Faqat endi istalgan sayt sizning API'ingizga foydalanuvchi nomidan so'rov yubora oladi. Keling, bu narsani bir marta to'g'ri tushunib olaylik.

Boshlanish nuqtasi: Same-Origin Policy#

Brauzerda qattiq qoida bor: bir saytdagi JavaScript boshqa origin'ga so'rov yuborib, javobini o'qiy olmaydi. Origin = protokol + domen + port:

https://solijonov.uz      va  https://api.solijonov.uz   → har xil origin
https://solijonov.uz      va  https://solijonov.uz:8000  → har xil origin

Nega bu qoida bor? Siz bankim.uz'ga kirib turibsiz, cookie'ingiz brauzerda. Boshqa tabda yomon-sayt.uz ochiq. Same-Origin Policy bo'lmasa, yomon sayt JavaScript bilan bankim.uz/api/balansga so'rov yuborar va sizning cookie'laringiz bilan javobni o'qib olardi. SOP — brauzerning foydalanuvchini himoya qilishi.

Muhim tushuncha: CORS — bu himoya emas, himoyani nazorat ostida yumshatish. "Mening API'imga mana bu origin'lardan kelishga ruxsat" deyish usuli.

CORS qanday ishlaydi#

Brauzer boshqa origin'ga so'rov yuborishdan oldin (yoki bilan birga) serverdan "ruxsatnoma" so'raydi. Oddiy GET'da javob header'iga qaraydi:

Access-Control-Allow-Origin: https://solijonov.uz

Javobda so'rov yuborgan origin bo'lsa — JavaScript javobni o'qiydi. Bo'lmasa — brauzer javobni JS'dan yashiradi va konsolda o'sha mashhur xatoni ko'rasiz.

"Murakkab" so'rovlarda (masalan, Content-Type: application/json bilan POST) brauzer avval preflight yuboradi — OPTIONS metodli razvedka so'rovi: "shu origin'dan, shu metod bilan kelsam maylimi?" Server ruxsat header'lari bilan javob bersa, asosiy so'rov ketadi.

Ikki keng tarqalgan tushunmovchilik#

1. "CORS server himoyasi". Yo'q! CORS faqat brauzerdagi JavaScriptni cheklaydi. curl, Postman, boshqa server — bularga CORS umuman ta'sir qilmaydi, so'rov bemalol yetib boradi. Server himoyasi — autentifikatsiya, ruxsatlar, rate limiting.

2. "Allow-All qilsam nima bo'ladi?" Access-Control-Allow-Origin: * — ochiq, cookie'siz API uchun normal (masalan, ochiq ma'lumotlar API'si). Lekin cookie/sessiya bilan ishlaydigan API'da istalgan sayt foydalanuvchi sessiyasi bilan so'rov o'qiy olishiga eshik ochasiz. Brauzerlar shu sabab credentials + * kombinatsiyasini bloklaydi — uni chetlab o'tish uchun originni echo qilish esa (so'ragan originni qaytarib qo'yish) eng xavfli anti-pattern.

Django'da to'g'ri sozlash#

django-cors-headers bilan:

INSTALLED_APPS = [..., "corsheaders"]
MIDDLEWARE = ["corsheaders.middleware.CorsMiddleware", ...]  # tepada tursin

# Aniq ro'yxat — yulduzcha emas:
CORS_ALLOWED_ORIGINS = [
    "https://solijonov.uz",
    "https://app.solijonov.uz",
]
CORS_ALLOW_CREDENTIALS = True  # faqat cookie/sessiya kerak bo'lsa

Qoida oddiy: ruxsat ro'yxati — bor bo'lgani. Development uchun http://localhost:5173 kabi manzillarni ham ro'yxatga qo'shasiz (env orqali), production'da esa faqat real frontend originlaringiz qoladi.

Yodda qoladigan xulosa#

  • SOP foydalanuvchini himoya qiladi, CORS — bu himoyada siz ochgan nazoratli eshik;
  • CORS xatosi — "API buzilgan" emas, "server bu origin'ga ruxsat bermagan" degani;
  • Allow-All + credentials — hech qachon;
  • CORS bor joyda CSRF haqida ham o'ylang — ular qarindosh mavzular.

Savollar bo'lsa — Telegram'da muhokama qilamiz.