# Cookie, session va autentifikatsiya

> HTTP stateless bo'lsa sayt foydalanuvchini qanday eslab qoladi? Cookie, server sessioni, token, autentifikatsiya va avtorizatsiya o'rtasidagi farq.

Manba: https://learncode.uz/web-dasturlash/cookie-session-autentifikatsiya/
Sana: 2026-05-10

![Foydalanuvchi login qilgach cookie orqali serverdagi session bilan tanilishi](https://learncode.uz/images/web-dasturlash/cookie-session-autentifikatsiya-hero.webp)

*Cookie brauzerda kichik identifikatorni, session esa server tomonda foydalanuvchining kirgan holatini saqlashi mumkin.*

HTTP tabiatan **stateless**: har bir so'rov alohida ko'riladi. Server bir
so'rovni olganda, avvalgi so'rov aynan shu foydalanuvchidan kelganini o'z-o'zidan
bilmaydi. Unda sayt login qilganingizni, savatdagi mahsulotlarni yoki til
tanlovini qanday eslab qoladi? Buning uchun cookie, session va token kabi
mexanizmlar ishlatiladi.

## Cookie va session

**Cookie** — sayt brauzerda saqlashni so'rashi mumkin bo'lgan kichik
`nom=qiymat` yozuvi. Server javobda `Set-Cookie` headerini yuboradi; brauzer
keyingi mos so'rovlarda cookie'ni avtomatik qaytarishi mumkin.

Cookie'da quyidagi sozlamalar muhim:

| Atribut | Vazifasi |
|---|---|
| `Expires` yoki `Max-Age` | Cookie qancha yashashini belgilaydi |
| `Secure` | Cookie faqat HTTPS orqali yuboriladi |
| `HttpOnly` | JavaScript cookie qiymatini o'qiy olmaydi |
| `SameSite` | Boshqa saytdan kelgan so'rovlarda yuborilishini cheklaydi |
| `Path` va `Domain` | Qaysi manzillarga cookie yuborilishini belgilaydi |

Cookie ichiga parol, karta raqami yoki katta hajmdagi ma'lumot yozilmaydi.
Ko'pincha u serverdagi sessionni topish uchun tasodifiy identifikator yoki
imzolangan, cheklangan qiymat saqlaydi.

Cookie hajmi ham cheklangan — odatda 4 KB atrofida. Undan tashqari, cookie
**har** mos so'rovda avtomatik yuboriladi, ya'ni har rasm va CSS fayli
so'ralganda ham. Katta cookie butun saytni sekinlashtiradi.

> **Cookie va localStorage farqi**
>
> `localStorage` ham brauzerda ma'lumot saqlaydi, lekin u serverga **avtomatik
> yuborilmaydi** va JavaScript uni har doim o'qiy oladi. Shu sababli sessiya
> uchun `HttpOnly` cookie xavfsizroq: XSS hujumi bo'lgan taqdirda ham skript
> cookie qiymatini o'qiy olmaydi. `localStorage` esa til tanlovi yoki tema kabi
> maxfiy bo'lmagan sozlamalar uchun qulay.

`SameSite` atributining uch qiymati bor va ular amalda quyidagicha farq qiladi:

| Qiymat | Xatti-harakat |
|---|---|
| `Strict` | Boshqa saytdan kelgan hech qanday so'rovga qo'shilmaydi |
| `Lax` | Oddiy havola bosilganda qo'shiladi, forma yuborilganda yo'q |
| `None` | Har doim qo'shiladi — `Secure` bilan birga bo'lishi shart |

Ko'p ilova uchun `Lax` mos boshlanish nuqtasi: u
[CSRF](https://learncode.uz/web-dasturlash/amaliy-web-xavfsizligi) himoyasini beradi, lekin tashqi
havola orqali kirgan foydalanuvchini tizimdan chiqarib yubormaydi.

### Session qanday ishlaydi

**Session** — foydalanuvchining bir nechta so'rov davomida saqlanadigan
holati. Klassik server sessioni quyidagicha ishlaydi:

1. Foydalanuvchi login va parolini HTTPS orqali yuboradi.
2. Server ma'lumotni tekshiradi.
3. Server tasodifiy session identifikatori yaratadi va session ma'lumotini
   xavfsiz server saqloviga yozadi.
4. Identifikator `HttpOnly`, `Secure` cookie orqali brauzerga yuboriladi.
5. Keyingi so'rovlarda brauzer cookie'ni yuboradi.
6. Server identifikator orqali foydalanuvchini topib, session muddati va
   ruxsatlarini tekshiradi.

![Login so'rovidan keyin server session yaratishi, cookie yuborishi va keyingi so'rovda foydalanuvchini tanishi](https://learncode.uz/images/web-dasturlash/cookie-session-oqimi.webp)

*Cookie session identifikatorini tashiydi; haqiqiy session holati server tomonda saqlanishi mumkin.*

> **Session identifikatori ham sir**
>
> Session ID'ni olgan hujumchi session tugamaguncha foydalanuvchi nomidan
> so'rov yuborishga urinishi mumkin. Shu sababli HTTPS, `HttpOnly`, `Secure`,
> `SameSite`, qisqa amal muddati va logout paytida sessionni bekor qilish muhim.

### Token qayerda ishlatiladi

Ba'zi tizimlar server sessioni o'rniga yoki u bilan birga imzolangan token
ishlatadi. Masalan, access token API so'rovining `Authorization` headerida
yuborilishi mumkin. Token ichidagi ma'lumotni o'qish mumkin bo'lishi uning
o'zgartirilishi mumkin degani emas — server imzoni tekshiradi.

Token "har doim cookie'dan yaxshiroq" emas. Qayerda saqlanishi, qanday
yangilanishi, qanday bekor qilinishi va XSS/CSRF tahdidlariga qarshi qanday
himoyalanishi arxitektura qaroridir. Boshlovchi uchun eng muhim narsa — tayyor
frameworkning xavfsiz autentifikatsiya imkoniyatidan foydalanish va o'zicha
kriptografiya yaratmaslik.

Ikki yondashuvni taqqoslash tanlovni osonlashtiradi:

| Jihat | Server sessioni | Imzolangan token |
|---|---|---|
| Holat qayerda | Serverda saqlanadi | Tokenning o'zida |
| Bekor qilish | Oson — yozuvni o'chirish kifoya | Qiyin — muddat tugashini kutish kerak |
| Masshtablash | Umumiy saqlov kerak | Server holat saqlamaydi |
| Mos joyi | Odatiy web sayt | Mobil ilova, mikroservis, tashqi API |

Eng muhim farq — **bekor qilish**. Foydalanuvchi parolini o'zgartirsa yoki
hisobi bloklansa, server sessionini darhol o'chirish mumkin. Imzolangan token
esa muddati tugagunga qadar amal qiladi. Shu sababli ko'p tizim ikkita token
ishlatadi: qisqa muddatli **access token** (bir necha daqiqa) va uzoq muddatli
**refresh token**, u orqali yangisi olinadi va kerak bo'lganda bekor qilinadi.

## Autentifikatsiya va avtorizatsiya

Bu ikki atama ko'p aralashadi:

- **autentifikatsiya** — "siz kimsiz?" savoliga javob; masalan login;
- **avtorizatsiya** — "sizga bu amal mumkinmi?" savoliga javob; masalan faqat
  admin foydalanuvchini o'chira olishi.

Foydalanuvchi tizimga muvaffaqiyatli kirgan bo'lsa ham, barcha ma'lumotga
ruxsat olgan bo'lmaydi. Backend har himoyalangan so'rovda avval session yoki
tokenni, keyin aynan shu resurs uchun ruxsatni tekshiradi.

![Autentifikatsiya foydalanuvchi kimligini, avtorizatsiya esa qaysi amallarga ruxsati borligini tekshirishi](https://learncode.uz/images/web-dasturlash/auth-autorizatsiya.webp)

*Login foydalanuvchini taniydi; ruxsat tekshiruvi uning qaysi resurs va amalga kira olishini belgilaydi.*

> **Ikki tekshiruv**
>
> `GET /buyurtmalar/42` so'rovida server avval session orqali foydalanuvchini
> taniydi. Keyin 42-buyurtma aynan shu foydalanuvchiga tegishlimi yoki u adminmi,
> tekshiradi. Birinchi qadam autentifikatsiya, ikkinchisi avtorizatsiyadir.

Ruxsatlarni tashkil qilishning ikki keng tarqalgan usuli bor. **Rol asosida**:
foydalanuvchiga rol beriladi (`admin`, `muharrir`, `oddiy`) va har rol nima
qila olishi belgilanadi. **Egalik asosida**: foydalanuvchi faqat o'zi yaratgan
ma'lumotni o'zgartira oladi.

Amalda ko'p tizim ikkalasini birga ishlatadi: oddiy foydalanuvchi o'z
buyurtmasini ko'radi, admin esa hammasini. Muhimi — bu qoidani bitta joyda
yozish. Ruxsat tekshiruvi o'nlab route ichiga tarqalib ketsa, birortasini
unutish ehtimoli oshadi.

## Parol va sessiya boshqaruvi

### Parol bilan ishlash

Login tizimining eng nozik qismi — parol. Uch qoida majburiy.

**Parol hech qachon ochiq saqlanmaydi.** Bazaga faqat xesh yoziladi va buning
uchun maxsus algoritm (`bcrypt`, `argon2`, `scrypt`) ishlatiladi. Ular ataylab
sekin ishlaydi, shuning uchun ularni ommaviy sinab ko'rish qiyin. `md5` va
`sha1` bu vazifa uchun yaramaydi — ular juda tez.

**Xato xabari ma'lumot bermasin.** "Bunday email topilmadi" degan javob
hujumchiga qaysi manzillar ro'yxatdan o'tganini aytadi. To'g'ri javob ikkala
holatda bir xil: "Email yoki parol noto'g'ri".

**Urinishlar cheklanadi.** Bir necha muvaffaqiyatsiz urinishdan keyin kechikish
qo'shiladi yoki qo'shimcha tekshiruv so'raladi. Bu parolni ketma-ket sinab
ko'rishni amalda imkonsiz qiladi.

Parolni tiklash oqimi ham xavfsiz bo'lishi kerak: tasodifiy, bir marta
ishlatiladigan va qisqa muddatli havola yuboriladi. Havola ishlatilgach yoki
muddati tugagach, u bekor bo'ladi.

### Session muddati va logout

Session abadiy yashamasligi kerak. Ikki xil muddat qo'llaniladi: **mutlaq**
muddat (masalan, 30 kundan keyin baribir tugaydi) va **harakatsizlik** muddati
(masalan, 30 daqiqa hech narsa qilinmasa tugaydi). Bank yoki admin panel uchun
qisqa muddat, oddiy sayt uchun uzunroq muddat mos keladi.

Logout paytida ikki ish bajariladi: cookie brauzerdan o'chiriladi **va**
serverdagi session bekor qilinadi. Faqat cookie'ni o'chirish yetarli emas —
session ID nusxasi qolgan bo'lsa, u hali ham ishlaydi.

> **Session fixation**
>
> Login qilingandan **keyin** yangi session identifikatori yaratish muhim.
> Aks holda hujumchi oldindan ma'lum bo'lgan session ID'ni foydalanuvchiga
> yuklab, keyin o'sha ID bilan uning hisobiga kirishga urinishi mumkin. Ko'p
> framework buni avtomatik bajaradi — o'z tizimingizni yozayotgan bo'lsangiz,
> buni unutmang.

## Amaliy mashq

Har kuni ishlatadigan bitta saytga kiring va DevTools'ni oching.
`Application → Cookies` bo'limida shu saytning cookie'larini ko'ring.

Uch savolga javob toping: qaysi cookie sessiyaga tegishli ko'rinadi, unda
`HttpOnly` va `Secure` belgilanganmi, va `SameSite` qiymati nima? Keyin
`Network` panelida istalgan so'rovni tanlab, `Cookie` headeri avtomatik
yuborilganini ko'ring.

Bu mashq nazariy tushunchani real, ishlayotgan tizimda ko'rish imkonini beradi.

## Qisqacha xulosa

- HTTP stateless; cookie va session so'rovlar orasida holatni bog'laydi.
- Cookie brauzerda saqlanadi va mos so'rovlarda serverga yuboriladi.
- Session ma'lumoti serverda, uning identifikatori cookie'da saqlanishi mumkin.
- `Secure`, `HttpOnly` va `SameSite` cookie xavfsizligining muhim atributlaridir.
- Autentifikatsiya foydalanuvchini taniydi, avtorizatsiya ruxsatni tekshiradi.
- Har bir himoyalangan backend route'ida ikkala tekshiruv ham zarur bo'lishi mumkin.

Keyingi darsda [amaliy web xavfsizligi](https://learncode.uz/web-dasturlash/amaliy-web-xavfsizligi)
— o'rgangan xavfsizlik qoidalarini amaliy tekshiruvda qo'llaymiz.