Intervyu: Web xavfsizlik (Security)

Full-stack dasturchi uchun chuqur texnik intervyu to'plami. Har bir savol hujumning ta'rifi, mexanizmi, zaif va himoyalangan kod misoli, himoya usullari va follow-up savol bilan yoritilgan. Maqsad — nafaqat atamani aytish, balki hujumni tushunib, uni to'xtata olishni ko'rsatish.

Qanday foydalanish

• Har savolni o'qib, avval o'zingiz javob berishga urining, keyin javobni ochib solishtiring.
• Belgilar: Junior · Middle · Senior.
• Har javobda quyidagi ketma-ketlik bor: Ta'rif Mexanizm Kod misol Himoya Follow-up.
• Inglizcha atamalar (token, hash, payload) ataylab saqlangan — intervyuda ham xuddi shunday ishlatiladi.
• Kod misollari Node.js/Express + brauzer muhitida yozilgan, lekin g'oyalar barcha stack'larga tegishli.

Xavfsizlik — bu "feature" emas, jarayon. Intervyuda "men buni hech qachon xato qilmayman" demang; "men bu xatoni qanday oldini olaman va qanday aniqlayman" deng.

OWASP Top 10 — umumiy manzara

Aksariyat intervyu shu ro'yxatdan boshlanadi. OWASP Top 10 — veb-ilovalardagi eng keng tarqalgan xavfsizlik kamchiliklari ro'yxati (OWASP tashkiloti muntazam yangilab turadi). 2021 versiyasi:

Intervyuda bu ro'yxatni yoddan aytish talab qilinmaydi, lekin har birining bitta real misolini keltira olish kutiladi. Quyidagi savollar shu kategoriyalarni chuqurlashtiradi.

1. Injection: XSS

S: Cross-Site Scripting (XSS) nima? (Junior) J: Ta'rif (hujum nima): XSS — hujumchi veb-sahifaga o'zining JavaScript kodini kiritishiga va u boshqa foydalanuvchilar brauzerida ishlashiga imkon beruvchi zaiflik. Kod jabrlanuvchi brauzerida, uning nomidan ishlaydi.

Mexanizm (qanday amalga oshadi): Ilova foydalanuvchidan olingan ma'lumotni (izoh, ism, qidiruv so'zi) escape qilmasdan to'g'ridan-to'g'ri HTML'ga qo'shadi. Brauzer bu matnni oddiy matn emas, bajariladigan kod deb tushunadi.

Kod misol:

//  ZAIF — foydalanuvchi kiritmasini to'g'ridan-to'g'ri innerHTML'ga qo'yish
const comment = req.query.text; // "<script>steal()</script>"
element.innerHTML = comment;    // script ishga tushadi!

//  HIMOYA — matn sifatida qo'yish (kod sifatida emas)
element.textContent = comment;  // <script> shunchaki matn bo'lib ko'rinadi

//  Server tomonida escape qilish
function escapeHtml(str) {
  return str
    .replace(/&/g, "&amp;")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/"/g, "&quot;")
    .replace(/'/g, "&#39;");
}

Himoya usullari:

• Chiqishda (output) kontekstga mos escape qiling (HTML, attribute, JS, URL — har biri boshqacha).
• innerHTML o'rniga textContent/innerText ishlating.
• Content Security Policy (CSP) o'rnating — inline script'larni bloklaydi.
• Framework'larning avto-escape'iga tayaning (React JSX, Angular, Vue matnni default escape qiladi).
• dangerouslySetInnerHTML / v-html dan qochish; zarur bo'lsa DOMPurify bilan tozalash.

Follow-up: React JSX default XSS'dan himoya qiladi — qaysi holatda baribir XSS bo'lishi mumkin? (Javob: dangerouslySetInnerHTML, href="javascript:...", foydalanuvchi kiritgan href/src, ref orqali to'g'ridan DOM manipulyatsiyasi.)

S: Stored, Reflected va DOM-based XSS farqini tushuntiring. (Middle) J: Ta'rif: Uchalasi ham XSS, lekin zararli kod qayerdan kelishi bilan farqlanadi.

Mexanizm:

• Stored (Persistent) XSS: zararli kod serverda saqlanadi (masalan, izohlar bazasida) va sahifani ochgan har bir foydalanuvchiga yetadi. Eng xavfli, chunki bir marta kiritilib, ko'plarga ta'sir qiladi.
• Reflected XSS: kod so'rovda (URL parametri, form) kelib, javobda darhol qaytariladi (reflected), lekin saqlanmaydi. Hujumchi jabrlanuvchiga maxsus link yuboradi.
• DOM-based XSS: zaiflik faqat client-side JSda. Server umuman aralashmaydi — JS location.hash yoki document.URL kabi manbadan olingan ma'lumotni xavfli sinkka (innerHTML, eval) yozadi.

Kod misol:

// Reflected XSS — server so'rovdagi qiymatni qaytaradi
app.get('/search', (req, res) => {
  //  res.send(`<h1>Natija: ${req.query.q}</h1>`);  // q="<script>...</script>"
  res.send(`<h1>Natija: ${escapeHtml(req.query.q)}</h1>`); // 
});

// DOM-based XSS — client-side, server ko'rmaydi
//  document.getElementById('out').innerHTML = location.hash.slice(1);
document.getElementById('out').textContent = location.hash.slice(1); // 

Himoya usullari:

• Stored: kirishda validatsiya + saqlashda tozalash + chiqishda escape (chuqur himoya).
• Reflected: har qanday reflected qiymatni escape qiling, CSP qo'ying.
• DOM-based: xavfli sink'lardan (innerHTML, outerHTML, document.write, eval, setTimeout(string)) qoching; textContent va xavfsiz DOM API'lardan foydalaning.

Follow-up: Nima uchun DOM-based XSS'ni server-side WAF (Web Application Firewall) ko'pincha ushlay olmaydi? (Javob: zararli payload # fragment'da bo'lsa, u serverga umuman yuborilmaydi — hujum to'liq brauzerda kechadi.)

2. Injection: SQL Injection

S: SQL Injection nima va qanday ishlaydi? (Junior) J: Ta'rif: SQL Injection — hujumchi foydalanuvchi kiritmasi orqali SQL so'rovga o'z buyruqlarini qo'shib, bazani o'qish/o'zgartirish/o'chirish imkonini oladi.

Mexanizm: Ilova foydalanuvchi kiritmasini SQL matniga string konkatenatsiya orqali qo'shadi. Baza kiritmani "ma'lumot" emas, "buyruq qismi" deb qabul qiladi. Klassik misol: ' OR '1'='1 shartni doim rost qiladi.

Kod misol:

//  ZAIF — string konkatenatsiya
const email = req.body.email; // "' OR '1'='1"
db.query(`SELECT * FROM users WHERE email = '${email}'`);
// Natija: SELECT * FROM users WHERE email = '' OR '1'='1'   hamma qatorlar!

//  HIMOYA — parametrli so'rov (prepared statement)
db.query('SELECT * FROM users WHERE email = ?', [email]);
// Kiritma alohida uzatiladi — hech qachon "buyruq" bo'lolmaydi

//  ORM misoli (Prisma) — ostida parametrlanadi
await prisma.user.findUnique({ where: { email } });

Himoya usullari:

• Parametrli so'rov / prepared statement — asosiy va eng ishonchli himoya.
• ORM/query builder ishlating, lekin raw query yozganda ham parametrlang.
• Least privilege: ilova DB user'iga faqat kerakli huquqlar (masalan, DROP bermang).
• Input validatsiya (whitelist) — qo'shimcha qatlam, lekin yolg'iz yetarli emas.
• Xato xabarlarini yashiring — SQL xatosini foydalanuvchiga ko'rsatmang.

Follow-up: Parametrli so'rov ustun/jadval nomini dinamik qilishga yordam bermaydi — bunday holatda qanday himoyalaysiz? (Javob: ustun/jadval nomlarini faqat whitelist (ruxsat etilgan qiymatlar ro'yxati) orqali tekshirish; ularni parametrlab bo'lmaydi.)

S: NoSQL injection SQL injection'dan nimasi bilan farq qiladi? (Middle) J: Ta'rif: NoSQL injection — MongoDB kabi hujjatli bazalarda so'rov obyektiga operator kiritib, mantiqni buzish.

Mexanizm: MongoDB so'rovlari JSON obyekt. Agar foydalanuvchi kiritmasi tekshirilmasdan obyektga tushsa, hujumchi {"$gt": ""} yoki {"$ne": null} kabi operator yuborib, shartni chetlab o'tadi.

Kod misol:

//  ZAIF — body to'g'ridan-to'g'ri so'rovga
// So'rov body: { "email": "admin@x.com", "password": { "$ne": null } }
await User.findOne({ email: req.body.email, password: req.body.password });
// password: {$ne: null}  istalgan parol bilan kiradi!

//  HIMOYA — tipni majburlash va validatsiya
const email = String(req.body.email);
const password = String(req.body.password); // obyekt emas, string bo'lishi shart
await User.findOne({ email, password: hash(password) });

Himoya usullari:

• Kiritma tipini tekshiring/majburlang (String(), schema validatsiya — Zod/Joi).
• express-mongo-sanitize kabi middleware bilan $ va . belgilarini tozalang.
• Schema-based validatsiya (Mongoose strict mode).

Follow-up: Nega express-mongo-sanitize yolg'iz yetarli emas? (Javob: u faqat operatorlarni olib tashlaydi; biznes-logika darajasidagi tip xatolari va parolni ochiq solishtirish kabi muammolarni hal qilmaydi.)

3. CSRF

S: Cross-Site Request Forgery (CSRF) nima? (Middle) J: Ta'rif: CSRF — hujumchi jabrlanuvchini aldab, u allaqachon tizimga kirgan saytga o'zi bilmagan holda so'rov (masalan, pul o'tkazish) yuborishga majburlaydi.

Mexanizm: Brauzer har so'rovga o'sha domenning cookie'larini avtomatik qo'shadi. Hujumchi o'z saytida yashirin form/rasm joylaydi; jabrlanuvchi uni ochsa, brauzer bank saytiga cookie bilan so'rov yuboradi va bank uni "haqiqiy" deb qabul qiladi. XSS'dan farqi: CSRF cookie'ning avtomatik jo'natilishini suiiste'mol qiladi, kod kiritmaydi.

Kod misol:

<!-- Hujumchi sahifasidagi yashirin form -->
<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="to" value="hacker">
  <input type="hidden" name="amount" value="10000">
</form>
<script>document.forms[0].submit();</script>

//  HIMOYA — CSRF token
app.use(csrf()); // har form uchun noyob token generatsiya
app.post('/transfer', (req, res) => {
  // token body'dagi qiymat cookie/session bilan mos kelmasa — rad
});

//  Cookie'ni SameSite qilish
res.cookie('session', id, { httpOnly: true, secure: true, sameSite: 'strict' });

Himoya usullari:

• CSRF token (synchronizer token pattern) — server har formaga noyob, oldindan bilib bo'lmaydigan token beradi.
• SameSite cookie (Strict yoki Lax) — cookie faqat o'z saytidan yuborilsin.
• Double-submit cookie pattern.
• Muhim amallar uchun qayta autentifikatsiya (parol so'rash).
• Faqat GET orqali holat o'zgartirmaslik (GET idempotent bo'lishi kerak).

Follow-up: JWT'ni Authorization: Bearer header'da yuborsangiz, CSRF token kerakmi? (Javob: Odatda yo'q — chunki header'ni brauzer avtomatik qo'shmaydi, hujumchi sayti uni o'qiy/o'rnata olmaydi. CSRF asosan cookie-based autentifikatsiyaga tegishli.)

4. Authentication vs Authorization

S: Authentication va Authorization farqi nima? (Junior) J: Ta'rif:

• Authentication (autentifikatsiya, AuthN): "Siz kimsiz?" — shaxsni tasdiqlash (login/parol, token).
• Authorization (avtorizatsiya, AuthZ): "Sizga nima mumkin?" — tasdiqlangan shaxsning huquqlarini tekshirish.

Mexanizm: Avval AuthN bo'ladi (kim ekanini aniqlaymiz), keyin AuthZ (nima qila olishini hal qilamiz). AuthN'siz AuthZ bo'lmaydi, lekin AuthN muvaffaqiyatli bo'lsa ham, AuthZ rad etilishi mumkin (kirdingiz, lekin admin panelga ruxsat yo'q).

Kod misol:

// AuthN middleware — kim ekanini aniqlaydi
function authenticate(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  const user = verifyToken(token);      // 401 agar yaroqsiz
  if (!user) return res.status(401).json({ error: 'Autentifikatsiya kerak' });
  req.user = user;
  next();
}

// AuthZ middleware — huquqni tekshiradi
function authorize(role) {
  return (req, res, next) => {
    if (req.user.role !== role)         // 403 agar huquq yetmasa
      return res.status(403).json({ error: 'Ruxsat yo\'q' });
    next();
  };
}

app.delete('/users/:id', authenticate, authorize('admin'), deleteUser);

Himoya usullari:

• 401 (Unauthorized) — AuthN muvaffaqiyatsiz; 403 (Forbidden) — AuthZ muvaffaqiyatsiz. Aralashtirmang.
• Avtorizatsiyani har so'rovda serverda tekshiring, faqat UI'ni yashirish yetarli emas.
• RBAC (Role-Based) yoki ABAC (Attribute-Based) modeldan foydalaning.

Follow-up: Frontend'da tugmani if (user.isAdmin) bilan yashirdingiz. Bu yetarlimi? (Javob: Yo'q — bu faqat UX. Har qanday foydalanuvchi API'ga to'g'ridan-to'g'ri so'rov yuborishi mumkin, shuning uchun tekshiruv backend'da ham bo'lishi shart.)

5. JWT xavfsizligi

S: JWT (JSON Web Token) nima va uch qismi nimadan iborat? (Middle) J: Ta'rif: JWT — tomonlar orasida ma'lumotni imzolangan (signed) holda uzatuvchi kompakt token standarti. Ko'pincha stateless autentifikatsiya uchun ishlatiladi.

Mexanizm: Uch qism nuqta bilan ajratiladi: header.payload.signature.

• Header: algoritm (masalan, HS256) va tip.
• Payload: claim'lar (userId, role, exp) — Base64URL bilan kodlangan, shifrlanmagan!
• Signature: header+payload'ning maxfiy kalit bilan imzosi. Server imzoni qayta hisoblab, tokenni o'zgartirilmaganini tekshiradi.

Kod misol:

//  ZAIF — payload'ga maxfiy ma'lumot solish (u ochiq o'qiladi!)
jwt.sign({ userId, creditCard: '4111...' }, secret); // hech qachon!

//  HIMOYA — faqat kerakli, maxfiy bo'lmagan claim + qisqa muddat
jwt.sign(
  { sub: userId, role: 'user' },
  process.env.JWT_SECRET,
  { expiresIn: '15m', algorithm: 'HS256' }
);

// Tekshirish — algoritmni majburlab belgilang
jwt.verify(token, process.env.JWT_SECRET, { algorithms: ['HS256'] });

Himoya usullari:

• Payload shifrlanmagan — hech qachon parol/karta/maxfiy ma'lumot solmang.
• verifyda algoritmni aniq belgilang — alg: none va HS256RS256 almashtirish hujumlarini oldini oladi.
• Kuchli, uzun JWT_SECRET (env'da), muntazam rotatsiya.
• exp (expiry) qisqa bo'lsin.

Follow-up: alg: none hujumi nima? (Javob: hujumchi header'da algoritmni none qilib, imzosiz token yuboradi; imzoni tekshirmaydigan zaif kutubxona uni qabul qilib qo'yadi. Shuning uchun ruxsat etilgan algoritmlar ro'yxatini qat'iy belgilang.)

S: JWT'ni qayerda saqlash kerak — localStorage yoki cookie? XSS vs CSRF trade-off'ini tushuntiring. (Senior) J: Ta'rif: Token saqlash joyi ikki xavf orasidagi murosani belgilaydi: localStorage XSS xavfi, cookie CSRF xavfi.

Mexanizm:

• localStorage/JS-accessible: JavaScript o'qiy oladi. XSS bo'lsa, hujumchi kod tokenni o'g'irlaydi. Lekin brauzer uni avtomatik yubormaydi CSRF yo'q.
• Cookie (httpOnly): JavaScript o'qiy olmaydi XSS token o'g'irlay olmaydi. Lekin brauzer uni har so'rovga avtomatik qo'shadi CSRF xavfi paydo bo'ladi (shuning uchun SameSite kerak).

Kod misol:

//  Eng mustahkam yondashuv: httpOnly + Secure + SameSite cookie
res.cookie('accessToken', token, {
  httpOnly: true,   // JS o'qiy olmaydi  XSS himoyasi
  secure: true,     // faqat HTTPS orqali
  sameSite: 'strict', // CSRF himoyasi
  maxAge: 15 * 60 * 1000, // 15 daqiqa
});

//  Ko'p uchraydigan xato — token'ni localStorage'da saqlash
localStorage.setItem('token', token); // XSS bo'lsa darhol o'g'irlanadi

Himoya usullari:

• Amaliyotda ko'pchilik httpOnly + Secure + SameSite cookie ni afzal ko'radi — XSS token o'g'irlashning oldini oladi.
• localStorage tanlansa, XSS'ga qarshi kurash (CSP, escape) hal qiluvchi ahamiyatga ega bo'ladi.
• Qisqa umrli access token + xavfsiz saqlangan refresh token kombinatsiyasi.
• Token'ni URL'ga hech qachon qo'ymang (log/history'da qoladi).

Follow-up: Nima uchun XSS bo'lsa, httpOnly cookie ham to'liq qutqarmaydi? (Javob: hujumchi token'ni o'qiy olmasa ham, XSS orqali jabrlanuvchi brauzeridan turib so'rov yuborishi mumkin — token cookie'da avtomatik ketadi. XSS baribir kritik.)

S: Refresh token rotation nima va nega kerak? (Senior) J: Ta'rif: Refresh token — qisqa umrli access token tugaganda yangisini olish uchun ishlatiladigan uzoq umrli token. Rotation — har foydalanishda refresh token'ni yangisiga almashtirish va eskisini bekor qilish.

Mexanizm: Access token qisqa (masalan, 15 daqiqa) bo'ladi — o'g'irlansa ham tez kuchini yo'qotadi. Refresh token uzoq (kunlar/haftalar). Rotation'da: har /refresh chaqiruvida server yangi refresh token beradi, eskisini "ishlatilgan" deb belgilaydi. Agar eski (ishlatilgan) token qayta ishlatilsa — bu o'g'irlik alomati, server butun oilani (token family) bekor qiladi.

Kod misol:

app.post('/refresh', async (req, res) => {
  const old = req.cookies.refreshToken;
  const record = await db.refreshTokens.find(old);

  // Ishlatilgan token qayta kelsa — o'g'irlik! Butun zanjirni bekor qil
  if (!record || record.used) {
    await db.refreshTokens.revokeFamily(record?.familyId);
    return res.status(401).json({ error: 'Token buzilgan' });
  }

  await db.refreshTokens.markUsed(old);           // eskisini yop
  const next = issueRefreshToken(record.familyId); // yangisini ber (rotation)
  res.cookie('refreshToken', next, { httpOnly: true, secure: true, sameSite: 'strict' });
  res.json({ accessToken: issueAccessToken(record.userId) });
});

Himoya usullari:

• Refresh token'larni serverda saqlab, bekor qilish (revoke) imkonini bering.
• Rotation + reuse detection — o'g'irlangan tokenni aniqlaydi.
• Refresh token'ni httpOnly cookieda saqlang.
• Logout'da refresh token'ni serverda o'chiring.

Follow-up: Access token'ni ham serverda tekshirmasangiz (stateless), foydalanuvchini darhol qanday bloklaysiz? (Javob: to'liq stateless JWT'ni darrov bekor qilib bo'lmaydi — shuning uchun access token qisqa qilinadi va/yoki blacklist (denylist) yoki qisqa TTL li tekshiruv qo'shiladi.)

6. Session xavfsizligi

S: Session-based va token-based (JWT) autentifikatsiya farqi va session xavfsizligi qoidalari. (Middle) J: Ta'rif: Session-based — server holatni (session) saqlaydi, brauzerga faqat sessionId cookie beriladi. Token-based — holat token ichida, server stateless.

Mexanizm: Session'da server xotira/Redis/DB da sessionId user bog'lanishini saqlaydi. Cookie'dagi sessionId faqat "kalit". Xavflar: session hijacking (id o'g'irlash) va session fixation (hujumchi oldindan belgilangan id'ni jabrlanuvchiga yuklash).

Kod misol:

//  Xavfsiz session sozlamalari
app.use(session({
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: { httpOnly: true, secure: true, sameSite: 'strict', maxAge: 3600000 },
  store: new RedisStore({ client }),   // xotirada emas, Redis'da
}));

//  Login'dan keyin session ID'ni yangilang — fixation himoyasi
app.post('/login', (req, res) => {
  // ... parol tekshiruvi
  req.session.regenerate(() => {  // eski ID bekor, yangisi
    req.session.userId = user.id;
    res.json({ ok: true });
  });
});

Himoya usullari:

• Login'dan keyin session ID'ni regenerate qiling (fixation himoyasi).
• Cookie: httpOnly, Secure, SameSite.
• Session'ga timeout (idle va absolute) qo'ying.
• Logout'da session'ni serverdan o'chiring.
• Session ID kriptografik jihatdan tasodifiy va uzun bo'lsin.

Follow-up: Katta miqyosli (horizontally scaled) tizimda session'ni qayerda saqlaysiz va nega? (Javob: markaziy store'da — Redis/Memcached — chunki so'rovlar turli server'larga tushadi; in-memory session bir serverga bog'lanib qoladi.)

7. Password hashing

S: Parolni bazada qanday saqlash kerak? Nega ochiq (plaintext) saqlash mumkin emas? (Junior) J: Ta'rif: Parollar hech qachon ochiq saqlanmasligi kerak — ular bir tomonlama hash (bcrypt/argon2) qilib saqlanadi.

Mexanizm: Hash — kirishdan chiqishga bir tomonlama funksiya: paroldan hash olish oson, hash'dan parolni qaytarish (deyarli) imkonsiz. Login'da kiritilgan parol qayta hash qilinadi va saqlangani bilan solishtiriladi. Baza o'g'irlansa ham, parollar ochilmaydi.

Kod misol:

const bcrypt = require('bcrypt');

//  ZAIF — ochiq yoki oddiy hash
db.save({ password: req.body.password });          // ochiq — falokat
db.save({ password: md5(req.body.password) });     // MD5 — sindiriladi

//  HIMOYA — bcrypt (salt avtomatik ichida)
const hash = await bcrypt.hash(req.body.password, 12); // 12 = cost factor
db.save({ passwordHash: hash });

// Tekshirish
const ok = await bcrypt.compare(req.body.password, user.passwordHash);

Himoya usullari:

• bcrypt, argon2 yoki scrypt ishlating — ular ataylab sekin (brute force qimmat).
• Salt har parol uchun noyob — bir xil parollar turlicha hash bo'ladi (bcrypt buni avtomatik qiladi).
• Cost/work factor'ni apparatga qarab yetarlicha yuqori qo'ying.
• Parolni hech qachon log qilmang.

Follow-up: Nega bcrypt uchun cost factor'ni oshirib borish kerak? (Javob: apparat kuchaygani sari sindirish arzonlashadi; cost'ni oshirib, hash'ni "qimmat" saqlaymiz.)

S: Nega MD5/SHA-256 parol uchun yaramaydi, lekin bcrypt yaraydi? Salt va pepper nima? (Senior) J: Ta'rif: MD5/SHA — tez kriptografik hash'lar; parol uchun aynan tezligi kamchilik. bcrypt/argon2 — sekin, parolga moslashtirilgan.

Mexanizm:

• Tezlik muammosi: GPU MD5/SHA'ni soniyasiga milliardlab hisoblaydi brute force va rainbow table (oldindan hisoblangan hash lug'ati) samarali.
• Salt — har parolga qo'shiladigan noyob tasodifiy qiymat. Rainbow table'ni bekor qiladi va bir xil parollar turli hash beradi.
• Pepper — barcha parollarga qo'shiladigan, lekin bazadan tashqarida (masalan, env yoki HSM'da) saqlanadigan maxfiy qiymat. Baza o'g'irlansa ham, pepper'siz hash sindirilmaydi.
• bcrypt ichida salt bor va work factor orqali sekinlashtiriladi.

Kod misol:

//  Tez hash + salt bo'lsa ham — GPU brute force uchun ojiz
const hash = sha256(salt + password);

//  bcrypt — sekin, salt ichida
const hash = await bcrypt.hash(password, 12);

//  Pepper qo'shish (env'da saqlangan sir)
const peppered = crypto.createHmac('sha256', process.env.PEPPER)
                       .update(password).digest('hex');
const hash2 = await bcrypt.hash(peppered, 12);

Himoya usullari:

• Parol uchun faqat sekin, moslashtirilgan funksiyalar (bcrypt/argon2/scrypt).
• Har parolga noyob salt (kutubxona avtomatik).
• Ixtiyoriy pepper — bazadan alohida saqlangan qatlam.
• argon2id — hozirgi tavsiya (memory-hard, GPU'ga chidamli).

Follow-up: argon2 bcrypt'dan nima bilan afzal? (Javob: argon2 memory-hard — ko'p RAM talab qiladi, bu GPU/ASIC bilan parallel sindirishni qimmatlashtiradi; bcrypt asosan CPU-bound.)

8. HTTPS / TLS

S: HTTPS qanday ishlaydi? TLS handshake'ni tushuntiring. (Middle) J: Ta'rif: HTTPS = HTTP + TLS. TLS ma'lumotni yo'lda shifrlaydi, server haqiqiyligini tasdiqlaydi va yaxlitligini (integrity) ta'minlaydi.

Mexanizm (handshake, soddalashtirilgan):

1. Client Hello: brauzer qo'llab-quvvatlaydigan TLS versiyasi va cipher'larni yuboradi.
2. Server Hello + Certificate: server o'z sertifikatini (ichida public key) yuboradi.
3. Sertifikat tekshiruvi: brauzer sertifikatni ishonchli CA (Certificate Authority) imzolaganini tekshiradi.
4. Kalit almashish: asimmetrik shifrlash yordamida ikkala tomon umumiy session key (simmetrik) kelishib oladi.
5. Shifrlangan aloqa: keyingi barcha trafik tez simmetrik kalit bilan shifrlanadi.

Ya'ni: asimmetrik shifrlash faqat kalit almashish uchun (sekin, lekin xavfsiz), keyin simmetrik (tez).

Kod misol:

// Server tomonda HTTPS'ni majburlash
app.use((req, res, next) => {
  if (req.headers['x-forwarded-proto'] !== 'https')
    return res.redirect(`https://${req.headers.host}${req.url}`); // 
  next();
});

// HSTS — brauzerga "faqat HTTPS ishlat" deydi
res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');

Himoya usullari:

• Hamma joyda HTTPS (HTTP'ni HTTPS'ga redirect).
• HSTS header — downgrade va SSL-strip hujumlarining oldini oladi.
• Zamonaviy TLS versiyasi (1.2+, imkon bo'lsa 1.3), eski cipher'larni o'chiring.
• Sertifikatni muddati o'tishidan oldin yangilang (avtomatlashtiring — Let's Encrypt).

Follow-up: TLS 1.3 1.2'dan nimasi bilan yaxshiroq? (Javob: kamroq round-trip (tezroq handshake, 0-RTT imkoni), zaif cipher'lar olib tashlangan, forward secrecy majburiy.)

S: Man-in-the-Middle (MITM) hujumi nima va TLS uni qanday to'xtatadi? (Middle) J: Ta'rif: MITM — hujumchi ikki tomon (client va server) orasiga kirib olib, trafikni o'qiydi yoki o'zgartiradi.

Mexanizm: Ochiq (HTTP) yoki zaif tarmoqda hujumchi o'zini "server" qilib ko'rsatadi (ARP spoofing, rogue Wi-Fi, DNS spoofing). TLS buni sertifikat orqali to'xtatadi: hujumchida haqiqiy CA imzolagan sertifikat bo'lmaydi, brauzer ogohlantiradi. SSL stripping — hujumchi HTTPS'ni HTTP'ga tushirishga urinadi; HSTS buni bloklaydi.

Kod misol:

//  HSTS bilan downgrade'ni bloklash
res.setHeader('Strict-Transport-Security',
  'max-age=63072000; includeSubDomains; preload');

//  Cookie'larni faqat HTTPS orqali yuborish
res.cookie('session', id, { secure: true, httpOnly: true, sameSite: 'strict' });

Himoya usullari:

• HTTPS + HSTS (+ preload list).
• Sertifikatlarni to'g'ri tekshirish; ilovalarda certificate pinning.
• Ochiq Wi-Fi'da maxfiy amallardan qochish (yoki VPN).
• Secure cookie — cookie hech qachon HTTP orqali ketmasin.

Follow-up: Certificate pinning nima va qanday xavfi bor? (Javob: ilova faqat ma'lum sertifikat/kalitga ishonadi; MITM'ni qiyinlashtiradi, lekin sertifikat yangilanganda pin eskirsa, ilova ishlamay qolishi mumkin.)

9. CORS

S: CORS nima, nega kerak va uni qanday to'g'ri sozlaysiz? (Middle) J: Ta'rif: CORS (Cross-Origin Resource Sharing) — brauzerning Same-Origin Policy cheklovini nazorat ostida yumshatuvchi mexanizm. U qaysi tashqi origin'lar sizning API'ngizga brauzerdan murojaat qila olishini belgilaydi.

Mexanizm: Same-Origin Policy default'da boshqa origin'ga (protocol://host:port farq qilsa) JS so'rov javobini o'qishni taqiqlaydi. Brauzer "murakkab" so'rovlardan oldin preflight (OPTIONS) so'rov yuborib, serverdan Access-Control-Allow-Origin kabi header'larni so'raydi. Server ruxsat bersa — asosiy so'rov ketadi. Muhim: CORS — brauzer himoyasi; server-to-server so'rovga ta'sir qilmaydi.

Kod misol:

//  ZAIF — hammaga ruxsat + credentials birga (xavfli/xato kombinatsiya)
app.use(cors({ origin: '*', credentials: true })); // brauzer bunga yo'l qo'ymaydi

//  HIMOYA — aniq whitelist
const allowed = ['https://app.example.com', 'https://admin.example.com'];
app.use(cors({
  origin: (o, cb) => cb(null, !o || allowed.includes(o)),
  credentials: true,   // cookie yuborilsin
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
}));

Himoya usullari:

• Origin'ni whitelist qiling, * dan qoching (ayniqsa credentials: true bilan).
• Faqat kerakli method va header'larga ruxsat bering.
• CORS'ni autentifikatsiya o'rniga ishlatmang — u himoya emas, faqat brauzer siyosati.
• Origin'ni request'dan olib "aks ettirib" qaytarmang (reflected origin xatosi).

Follow-up: "CORS xatosi" chiqdi — bu server so'rovni rad etdi degani emas. Nega? (Javob: server ko'pincha so'rovni qabul qilib javob beradi, lekin kerakli CORS header'lar bo'lmasa brauzer javobni JS'dan yashiradi. Muammo javobni o'qishda, so'rov o'tishida emas.)

10. Content Security Policy

S: Content Security Policy (CSP) nima va u XSS'ni qanday kamaytiradi? (Senior) J: Ta'rif: CSP — brauzerga "qaysi manbalardan (script, style, image) resurs yuklash mumkin"ligini aytuvchi HTTP header. XSS ta'sirini keskin kamaytiradi.

Mexanizm: Brauzer CSP siyosatini o'qib, faqat ruxsat etilgan origin'lardan resurs yuklaydi va inline scriptlarni (agar nonce/hash bo'lmasa) bloklaydi. Shunday qilib, hujumchi XSS orqali <script> kiritsa ham, u CSP siyosatiga to'g'ri kelmasa ishga tushmaydi.

Kod misol:

//  ZAIF — unsafe-inline hamma inline script'ga ruxsat (XSS'ni ochadi)
res.setHeader('Content-Security-Policy',
  "default-src *; script-src 'unsafe-inline'");

//  HIMOYA — nonce bilan, faqat o'z domenidan
const nonce = crypto.randomBytes(16).toString('base64');
res.setHeader('Content-Security-Policy',
  `default-src 'self'; script-src 'self' 'nonce-${nonce}'; object-src 'none'; base-uri 'self'`);
// HTML'da: <script nonce="${nonce}">...</script> — faqat shu nonce'li script ishlaydi

Himoya usullari:

• 'unsafe-inline' va 'unsafe-eval' dan qoching.
• Nonce yoki hash bilan kerakli inline script'larga ruxsat.
• default-src 'self' bilan boshlang, keyin zaruriyat bo'yicha kengaytiring.
• object-src 'none', base-uri 'self', frame-ancestors qo'shing.
• Content-Security-Policy-Report-Only bilan avval sinab ko'ring (report yig'ing).

Follow-up: CSP XSS'ni oldini oladimi yoki ta'sirini kamaytiradimi? (Javob: kamaytiradi (mitigation), oldini olmaydi. U ikkinchi himoya qatlami — asosiy himoya baribir input/output'ni to'g'ri boshqarish. CSP "chuqur himoya" (defense in depth) qismidir.)

11. Security headers (Helmet)

S: Muhim security header'larni sanang. Helmet nima qiladi? (Middle) J: Ta'rif: Security header'lar — brauzer xatti-harakatini xavfsiz tomonga sozlaydigan HTTP javob header'lari. Helmet — Express'da ularni bir joyda o'rnatuvchi kutubxona.

Mexanizm: Har header brauzerga aniq ko'rsatma beradi: qayerdan skript yuklash, sahifani frame'ga solish mumkinmi, MIME turini "taxmin qilmaslik" va h.k.

Kod misol:

const helmet = require('helmet');
app.use(helmet()); // oqilona default'lar to'plami

// Muhim header'lar va vazifasi:
// Strict-Transport-Security   faqat HTTPS (HSTS)
// Content-Security-Policy     resurs manbalarini cheklaydi (XSS)
// X-Frame-Options: DENY       clickjacking (frame'ga solishni taqiqlaydi)
// X-Content-Type-Options: nosniff  MIME sniffing'ni to'xtatadi
// Referrer-Policy             Referer'da qancha ma'lumot ketishini boshqaradi
// Permissions-Policy          kamera/mikrofon/geolokatsiya ruxsatlari

Himoya usullari:

• Helmet'ni yoqing, lekin CSP'ni loyihaga moslab aniq sozlang (default bo'sh).
• X-Powered-By kabi ma'lumot beruvchi header'larni o'chiring.
• HSTS'ni ishlab chiqarish (production) HTTPS'da yoqing.

Follow-up: X-Content-Type-Options: nosniff nimadan himoya qiladi? (Javob: brauzer javob turini kontentga qarab "taxmin qilishini" (MIME sniffing) to'xtatadi — masalan, yuklangan rasmni HTML/JS deb bajarib yuborish hujumidan.)

12. Clickjacking

S: Clickjacking nima va undan qanday himoyalanasiz? (Middle) J: Ta'rif: Clickjacking — hujumchi haqiqiy saytni ko'rinmas iframe'ga solib, uning ustiga aldamchi UI qo'yadi; foydalanuvchi bir narsani bosaman deb, aslida yashirin tugmani bosadi.

Mexanizm: Hujumchi sahifasida sizning saytingiz shaffof (opacity: 0) iframe sifatida joylanadi va aldamchi tugma bilan ustma-ust qo'yiladi. Foydalanuvchi "Yut!" tugmasini bossa, aslida iframe'dagi "Pul o'tkaz"ni bosadi.

Kod misol:

//  HIMOYA — sahifani frame'ga solishni taqiqlash
res.setHeader('X-Frame-Options', 'DENY'); // hech kim frame'ga sololmaydi

//  Zamonaviy usul — CSP frame-ancestors (moslashuvchan)
res.setHeader('Content-Security-Policy', "frame-ancestors 'self'");
// faqat o'z domeningiz frame'ga solishi mumkin

Himoya usullari:

• X-Frame-Options: DENY yoki SAMEORIGIN.
• CSP frame-ancestors — X-Frame-Options'ning zamonaviy, kuchliroq varianti.
• Muhim amallar uchun qo'shimcha tasdiq (masalan, parol qayta so'rash).

Follow-up: X-Frame-Options va CSP frame-ancestors ikkalasi bo'lsa, qaysi ustun keladi? (Javob: zamonaviy brauzerlarda frame-ancestors ustun turadi; lekin eski brauzerlar uchun ikkalasini ham qo'yish tavsiya etiladi.)

13. SSRF

S: Server-Side Request Forgery (SSRF) nima? (Senior) J: Ta'rif: SSRF — hujumchi serverni aldab, o'zi tanlagan manzilga (ko'pincha ichki tarmoqqa) so'rov yuborishga majburlaydi.

Mexanizm: Ilova foydalanuvchi bergan URL'ga so'rov yuboradi (masalan, "rasmni URL'dan import qil"). Hujumchi URL o'rniga ichki manzil beradi: http://169.254.169.254/ (bulut metadata — IAM kalitlari!) yoki http://localhost:6379 (ichki Redis). Server ishonchli tarmoq ichida bo'lgani uchun bu so'rovlar o'tadi.

Kod misol:

//  ZAIF — foydalanuvchi URL'iga to'g'ridan-to'g'ri so'rov
app.post('/fetch', async (req, res) => {
  const data = await fetch(req.body.url); // url = http://169.254.169.254/...
  res.send(await data.text());            // ichki metadata sizib chiqadi!
});

//  HIMOYA — whitelist + IP tekshiruv
const ALLOWED_HOSTS = ['images.example.com'];
async function safeFetch(url) {
  const u = new URL(url);
  if (u.protocol !== 'https:') throw new Error('Faqat https');
  if (!ALLOWED_HOSTS.includes(u.hostname)) throw new Error('Ruxsat etilmagan host');
  const ip = await dns.lookup(u.hostname);
  if (isPrivateIP(ip.address)) throw new Error('Ichki IP taqiqlangan'); // SSRF bloki
  return fetch(url);
}

Himoya usullari:

• Chiquvchi so'rov host'larini whitelist qiling.
• Ichki/private IP diapazonlarini bloklang (127.0.0.0/8, 10.0.0.0/8, 169.254.0.0/16).
• DNS rebinding'ga qarshi — hostname'ni resolve qilingandan keyin IP'ni tekshiring.
• Bulut metadata endpoint'ini bloklang; IMDSv2'ga o'ting.
• Redirect'larni cheklang (redirect ichki manzilga olib borishi mumkin).

Follow-up: Faqat hostname'ni whitelist qilish nega yetarli emas? (Javob: DNS rebinding — hujumchi domen dastlab tashqi IP'ni, tekshiruvdan keyin ichki IP'ni qaytarishi mumkin. Shuning uchun so'rov vaqtidagi haqiqiy IP'ni tekshirish kerak.)

14. IDOR / Broken Access Control

S: IDOR (Insecure Direct Object Reference) nima va uni qanday oldini olasiz? (Senior) J: Ta'rif: IDOR — foydalanuvchi so'rovdagi identifikatorni (id) o'zgartirib, o'ziga tegishli bo'lmagan resursga kirishi. Bu Broken Access Control'ning eng keng tarqalgan ko'rinishi.

Mexanizm: Endpoint resursni id bo'yicha oladi, lekin egaligini/huquqini tekshirmaydi. /api/orders/123 hujumchi 124 qilib boshqa foydalanuvchi buyurtmasini ko'radi.

Kod misol:

//  ZAIF — faqat id bo'yicha, egalik tekshirilmaydi
app.get('/api/orders/:id', authenticate, async (req, res) => {
  const order = await Order.findById(req.params.id);
  res.json(order); // istalgan id — istalgan buyurtma!
});

//  HIMOYA — egalik/huquqni tekshirish
app.get('/api/orders/:id', authenticate, async (req, res) => {
  const order = await Order.findOne({
    _id: req.params.id,
    userId: req.user.id,        // faqat o'ziniki
  });
  if (!order) return res.status(404).json({ error: 'Topilmadi' });
  res.json(order);
});

Himoya usullari:

• Har resurs so'rovida egalik yoki huquqni tekshiring (nafaqat AuthN).
• So'rovni foydalanuvchi kontekstiga bog'lang (WHERE userId = currentUser).
• Ketma-ket, taxmin qilinadigan id'lar o'rniga UUID (taxminni qiyinlashtiradi, lekin yolg'iz himoya emas).
• Markazlashgan avtorizatsiya (policy) qatlami.

Follow-up: UUID ishlatish IDOR'ni to'liq hal qiladimi? (Javob: Yo'q — UUID faqat taxminni qiyinlashtiradi (security through obscurity). Haqiqiy himoya har so'rovda huquq tekshiruvi. UUID sizib chiqsa (log, referrer), qo'shimcha tekshiruvsiz baribir ochiq.)

15. Rate limiting / Brute force

S: Brute force hujumini rate limiting bilan qanday to'xtatasiz? (Middle) J: Ta'rif: Brute force — hujumchi parol/token/OTP'ni ko'p urinish orqali topishga harakat qiladi. Rate limiting — ma'lum vaqt ichidagi so'rovlar sonini cheklaydi.

Mexanizm: Har IP/foydalanuvchi uchun so'rov hisoblanadi; chegaradan oshsa, so'rovlar rad etiladi (429) yoki sekinlashtiriladi. Login, OTP, parol tiklash kabi endpoint'lar ayniqsa muhofaza qilinadi.

Kod misol:

const rateLimit = require('express-rate-limit');

//  Login uchun qattiq limit
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 daqiqa
  max: 5,                    // IP'ga 5 urinish
  standardHeaders: true,
  message: { error: 'Juda ko\'p urinish. Keyinroq qayta urining.' },
});
app.post('/login', loginLimiter, loginHandler);

//  Qo'shimcha — hisob darajasida bloklash (account lockout)
if (user.failedAttempts >= 5) {
  return res.status(429).json({ error: 'Hisob vaqtincha bloklandi' });
}

Himoya usullari:

• Login/OTP/reset endpoint'lariga rate limit.
• Account lockout yoki progressive delay (urinish oshgani sari kutish ortadi).
• CAPTCHA shubhali trafikda.
• Distributed brute force uchun IP + hisob + qurilma bo'yicha cheklash; store'ni Redisda saqlang (bir nechta server).
• Muvaffaqiyatsiz urinishlarni log/monitoring qiling.

Follow-up: IP bo'yicha rate limit'ning kamchiligi nima? (Javob: hujumchi ko'p IP (botnet, proxy) ishlatsa chetlab o'tadi; NAT ortidagi ko'p foydalanuvchi bitta IP'da bo'lsa, adolatli foydalanuvchilar zarar ko'radi. Shuning uchun ko'p qatlamli — hisob + qurilma + xatti-harakat.)

16. 2FA / TOTP

S: Two-Factor Authentication (2FA) va TOTP qanday ishlaydi? (Middle) J: Ta'rif: 2FA — parolga (biladigan narsa) qo'shimcha ikkinchi omil (bor narsa — telefon, yoki mavjudlik — barmoq izi). TOTP (Time-based One-Time Password) — telefondagi ilova (Google Authenticator) har 30 soniyada yangi kod chiqaradigan usul.

Mexanizm: Ro'yxatdan o'tishda server va ilova umumiy secretni bo'lishadi (QR kod orqali). TOTP kodi = HMAC(secret, joriy_vaqt / 30) dan olingan 6 xonali son. Server ham xuddi shu hisobni bajarib solishtiradi — kod tarmoq orqali oldindan yuborilmaydi.

Kod misol:

const speakeasy = require('speakeasy');

// Sozlashda — secret generatsiya, QR sifatida foydalanuvchiga
const secret = speakeasy.generateSecret();
db.saveUserSecret(user.id, secret.base32); // xavfsiz saqlang

// Login'ning 2-bosqichida — kodni tekshirish
const ok = speakeasy.totp.verify({
  secret: user.totpSecret,
  encoding: 'base32',
  token: req.body.code,
  window: 1, // vaqt farqi uchun ±1 oyna
});
if (!ok) return res.status(401).json({ error: 'Kod noto\'g\'ri' });

Himoya usullari:

• TOTP secret'ini shifrlab saqlang; hech qachon ochiq ko'rsatmang.
• Backup (recovery) kodlar bering — telefon yo'qolsa.
• TOTP kodini ham rate limit qiling (brute force 6 xonaga qarshi).
• SMS 2FA'dan ustun — SMS SIM swappingga zaif.

Follow-up: Nega SMS orqali 2FA TOTP'dan zaifroq? (Javob: SMS SIM swapping, SS7 hujumlari va perexvatga zaif; TOTP esa qurilmada offline generatsiya bo'ladi, tarmoq orqali uzatilmaydi.)

17. Secrets management

S: Nega maxfiy ma'lumotlar (API kalit, parol) kodda yoki git'da bo'lmasligi kerak? (Junior) J: Ta'rif: Secrets (API key, DB parol, JWT secret) — kodga yoki versiya nazoratiga (git) tushmasligi kerak bo'lgan maxfiy qiymatlar.

Mexanizm: Git tarixni saqlaydi — bir marta commit qilingan sir keyin o'chirilsa ham, tarixda qoladi. Repo ochiq bo'lsa yoki sizib chiqsa, sir hammaga ochiq. Bot'lar GitHub'ni doim kalitlar uchun skanerlaydi.

Kod misol:

//  ZAIF — kodda hardcode
const stripe = new Stripe('sk_live_51H...'); // git tarixida abadiy qoladi!

//  HIMOYA — environment variable
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

# .gitignore — .env hech qachon commit qilinmasin
.env
.env.local

# .env.example — faqat kalit nomlari (qiymatsiz), namuna sifatida
STRIPE_SECRET_KEY=
DATABASE_URL=

Himoya usullari:

• Sirlarni env variable yoki secrets manager (AWS Secrets Manager, Vault, Doppler)da saqlang.
• .env ni **.gitignore**ga qo'shing; .env.example (qiymatsiz) commit qiling.
• Sir sizib ketsa — darhol rotatsiya (yangilash), git tarixidan tozalash yetarli emas.
• CI/CD'da sirlarni "secret" sifatida inject qiling, log'da chiqarmang.
• Repo skaneri (git-secrets, trufflehog) bilan commit'dan oldin tekshiring.

Follow-up: .env ni xato bilan commit qildingiz va push qildingiz. Nima qilasiz? (Javob: eng avval sirni bekor qilib, yangisiga almashtiring (rotation) — chunki u allaqachon ochiq bo'lgan. Keyin git tarixidan tozalash (filter-repo) — lekin bu ikkinchi darajali, chunki sir allaqachon ko'rilgan bo'lishi mumkin.)

18. Input validation / Sanitization

S: Input validation va sanitization farqi. Nega ikkalasi ham kerak? (Middle) J: Ta'rif:

• Validation: kiritma kutilgan qoidaga mosligini tekshirish (email formati, uzunlik, tip). Mos kelmasa — rad et.
• Sanitization: kiritmani tozalash/xavfsiz shaklga keltirish (HTML teglarini olib tashlash, escape).

Mexanizm: Validation "yaroqlimi?" degan savolga javob beradi (whitelist yondashuv eng yaxshi). Sanitization esa "xavfli qismini olib tashlaymiz". Chuqur himoya uchun ikkalasi birga — validation kirishda, escape/sanitize chiqishda.

Kod misol:

const { z } = require('zod');

//  Validation — schema bilan (whitelist)
const schema = z.object({
  email: z.string().email(),
  age: z.number().int().min(0).max(120),
  role: z.enum(['user', 'admin']),   // faqat ruxsat etilgan qiymatlar
});
const result = schema.safeParse(req.body);
if (!result.success) return res.status(400).json({ errors: result.error.issues });

//  Sanitization — foydalanuvchi HTML'ini tozalash
const clean = DOMPurify.sanitize(req.body.bio); // <script> olib tashlanadi

Himoya usullari:

• Whitelist (ruxsat etilganini belgilash) blacklist'dan ustun.
• Server-side'da majburiy validatsiya (client-side faqat UX).
• Schema kutubxonalari (Zod, Joi, Yup) bilan tiplarni majburlang.
• Sanitize'ni to'g'ri kontekstda (HTML, SQL, shell) bajaring.

Follow-up: Nima uchun client-side validation'ga tayanish mumkin emas? (Javob: foydalanuvchi so'rovni brauzerni chetlab (Postman, curl) yuborishi mumkin; client-side faqat qulaylik uchun, xavfsizlik chegarasi emas.)

19. Principle of Least Privilege

S: Principle of Least Privilege (eng kam imtiyoz) nima? Real misol keltiring. (Senior) J: Ta'rif: Har komponent/foydalanuvchi/servis faqat o'z vazifasi uchun zarur minimal huquqqa ega bo'lishi kerak — ortiqcha emas.

Mexanizm: Ortiqcha huquq — buzilganda zarar ko'lami kattalashadi. Agar veb-ilova DB'ga admin sifatida ulansa va SQL injection bo'lsa — hujumchi butun bazani o'chira oladi. Agar u faqat kerakli jadvallarga SELECT/INSERT huquqi bilan ulansa — zarar cheklanadi.

Kod misol:

--  ZAIF — ilova to'liq huquqli user bilan ulanadi
GRANT ALL PRIVILEGES ON *.* TO 'app_user'@'%';

--  HIMOYA — faqat kerakli huquqlar
GRANT SELECT, INSERT, UPDATE ON shop.orders TO 'app_user'@'10.0.%';
GRANT SELECT ON shop.products TO 'app_user'@'10.0.%';
-- DROP, DELETE, boshqa DB'lar — yo'q

//  Bulutda — servis roliga faqat kerakli ruxsat (IAM)
// S3 bucket'dan faqat o'qish, yozish yo'q:
// { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:...bucket/*" }

Himoya usullari:

• DB user'lariga minimal huquq; alohida vazifaga alohida user.
• Bulut IAM'da tor rollar (wildcard * dan qoching).
• Konteyner'larni root'siz ishlating.
• Vaqtinchalik yuqori huquq kerak bo'lsa — just-in-time ruxsat, doimiy emas.

Follow-up: "Least privilege" va "defense in depth" qanday bir-birini to'ldiradi? (Javob: least privilege bitta komponent buzilganda zararni cheklaydi; defense in depth ko'p qatlam himoya qo'yadi. Birgalikda — bir qatlam yiqilsa, boshqasi ushlaydi va zarar tor bo'ladi.)

20. Dependency vulnerabilities

S: Uchinchi tomon kutubxonalaridagi zaifliklarni qanday boshqarasiz? (Middle) J: Ta'rif: Zamonaviy ilova yuzlab npm paketga tayanadi; ulardan birida zaiflik bo'lsa, sizning ilovangiz ham zaif (supply chain xavfi — OWASP A06).

Mexanizm: node_modules chuqur bog'liqlik daraxti — sizga kerak bo'lmagan tranzitiv paket ham keladi. Ma'lum zaifliklar CVE sifatida e'lon qilinadi; npm audit loyihangizni shu ma'lumotlar bazasiga solishtiradi.

Kod misol:

#  Zaifliklarni tekshirish
npm audit                    # hisobot
npm audit fix                # avtomatik tuzatiladiganlarni tuzatadi
npm audit --production       # faqat prod bog'liqliklar

#  Versiyani ko'rish/yangilash
npm outdated
npm update

//  CI'da avtomatlashtirish (masalan, GitHub Actions bosqichi)
// - Dependabot / Renovate bilan avtomatik PR
// - npm ci (lock fayl aniq versiyalarni majburlaydi)

Himoya usullari:

• npm audit ni CI'ga qo'shing; kritik zaiflikda build'ni to'xtating.
• Dependabot/Renovate/Snyk — avtomatik yangilanish PR'lari.
• package-lock.json ni commit qiling, npm ci ishlating (aniq, takrorlanadigan versiya).
• Keraksiz paketlarni olib tashlang (hujum yuzasini kamaytiring).
• Paketning obro'sini/faolligini tekshiring (typosquatting'dan ehtiyot bo'ling).

Follow-up: npm audit "critical" ko'rsatdi, lekin fix breaking change talab qiladi. Nima qilasiz? (Javob: zaiflik sizning ishlatish yo'lingizga tegishlimi baholaysiz (ba'zan reachable emas); zarur bo'lsa, testlar bilan yangilaysiz yoki vaqtincha patch/workaround qo'yasiz. Ko'r-ko'rona --force qilmaysiz.)

21. Encryption vs Hashing

S: Encryption va hashing farqi nima? Har biri qachon ishlatiladi? (Middle) J: Ta'rif:

• Hashing: bir tomonlama — kirishdan chiqish olinadi, lekin qaytarib bo'lmaydi. Parol, integrity tekshiruvi uchun.
• Encryption: ikki tomonlama — kalit bilan shifrlanadi va qaytarib ochiladi (decrypt). Maxfiy ma'lumotni saqlash/uzatish uchun.

Mexanizm: Parolni hash qilamiz, chunki uni qaytarib olishga hech qachon zarurat yo'q (faqat solishtiramiz). Kredit karta yoki xabarni encrypt qilamiz, chunki keyin uni o'qishimiz kerak.

Kod misol:

const crypto = require('crypto');

// Hashing (bir tomonlama) — parol uchun
const hash = await bcrypt.hash(password, 12); // qaytmaydi

// Encryption (ikki tomonlama) — maxfiy matn uchun
function encrypt(text, key) {
  const iv = crypto.randomBytes(16);
  const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);
  const enc = Buffer.concat([cipher.update(text, 'utf8'), cipher.final()]);
  return { iv, enc, tag: cipher.getAuthTag() }; // keyin decrypt qilinadi
}

Himoya usullari:

• Parol hash (bcrypt/argon2), hech qachon encrypt qilmang.
• Qayta o'qish kerak bo'lgan maxfiy ma'lumot encryption (AES-256-GCM).
• AEAD (masalan, GCM) — shifrlash + integrity birga.
• Kalitlarni xavfsiz boshqaring (KMS), IV/nonce'ni takrorlamang.

Follow-up: Nega parolni encrypt qilish (hash o'rniga) yomon g'oya? (Javob: encryption teskari qaytariladi — kalit o'g'irlansa, barcha parollar ochiladi. Hash'da esa qaytarish yo'l yo'q, shuning uchun parol uchun to'g'ri tanlov.)

S: Symmetric va asymmetric encryption farqi. Har biri qayerda ishlatiladi? (Senior) J: Ta'rif:

• Symmetric: bitta umumiy kalit shifrlash va ochish uchun (AES). Tez.
• Asymmetric: juft kalit — public (shifrlaydi) va private (ochadi) (RSA, ECC). Sekin, lekin kalit almashishni hal qiladi.

Mexanizm: Symmetric tez, lekin kalitni ikki tomon qanday xavfsiz almashtiradi? Muammo. Asymmetric buni hal qiladi: har kim sizning public key bilan shifrlaydi, faqat siz private key bilan ochasiz. TLS aynan shuni birlashtiradi: asymmetric bilan session kalitni almashadi, keyin tez symmetric bilan ma'lumot uzatadi.

Kod misol:

const crypto = require('crypto');

// Asymmetric — juft kalit
const { publicKey, privateKey } = crypto.generateKeyPairSync('rsa', { modulusLength: 2048 });

// Public bilan shifrlash (har kim qila oladi)
const enc = crypto.publicEncrypt(publicKey, Buffer.from('maxfiy'));
// Private bilan ochish (faqat egasi)
const dec = crypto.privateDecrypt(privateKey, enc);

// Raqamli imzo — private bilan imzo, public bilan tekshirish
const sig = crypto.sign('sha256', Buffer.from('data'), privateKey);
const valid = crypto.verify('sha256', Buffer.from('data'), publicKey, sig);

Himoya usullari:

• Katta ma'lumot symmetric (AES-256), tezlik uchun.
• Kalit almashish / imzo asymmetric (RSA/ECC).
• Ko'pincha hibrid (TLS kabi): asymmetric bilan kalit almashib, symmetric bilan uzatish.
• Private key'ni hech qachon oshkor qilmang; kalit uzunligini zamonaviy tut (RSA ≥2048, ECC).

Follow-up: Nega TLS to'liq asymmetric bilan ishlamaydi? (Javob: asymmetric hisoblash jihatidan sekin va qimmat; katta trafikni symmetric tezroq shifrlaydi. Shuning uchun asymmetric faqat boshida session kalitni xavfsiz almashishga ishlatiladi.)

22. Security logging & monitoring

S: Xavfsizlik logging va monitoring nega muhim? Nimalarni log qilasiz (va nimalarni yo'q)? (Middle) J: Ta'rif: Security logging — xavfsizlikka oid hodisalarni yozib borish; monitoring — ularni kuzatib, hujumni real vaqtda aniqlash (OWASP A09).

Mexanizm: Log bo'lmasa, buzg'unchilikni sezmaysiz va tergov qila olmaysiz. Muvaffaqiyatsiz login'lar, huquq rad etishlari, kutilmagan xatolar — hujum alomatlari. Lekin log'ga maxfiy ma'lumot (parol, token, karta) yozish — o'zi zaiflik.

Kod misol:

//  To'g'ri — hodisani log qil, lekin maxfiy ma'lumotsiz
logger.warn('login_failed', {
  userId: user?.id,       // ok
  ip: req.ip,             // ok
  attempts: user?.failedAttempts,
  // password: ...        //  HECH QACHON
});

//  Anomaliyada ogohlantirish
if (user.failedAttempts > 10) {
  alerting.notify('Ehtimoliy brute force', { userId: user.id, ip: req.ip });
}

Himoya usullari:

• Login (muvaffaqiyat/muvaffaqiyatsiz), huquq rad, admin amallarni log qiling.
• Log'ga parol/token/karta/PII yozmang (yoki mask qiling).
• Log'larni markazlashtiring (ELK, CloudWatch), o'zgartirishdan himoyalang.
• Anomaliyalarga alert qo'ying; log'larni muntazam ko'rib chiqing.

Follow-up: Log'lar o'zi qanday xavf tug'diradi? (Javob: maxfiy ma'lumot log'ga tushsa — yangi sizish nuqtasi; log injection (yolg'on yozuv kiritish); log'ga ruxsatsiz kirish. Log'larni ham himoya qilinadigan aktiv sifatida ko'ring.)

23. File upload xavfsizligi

S: Fayl yuklash (file upload) funksiyasini qanday xavfsiz qilasiz? (Senior) J: Ta'rif: Fayl yuklash — foydalanuvchi serverga fayl joylashi; noto'g'ri boshqarilsa, kod bajarish, XSS, DoS yoki path traversalga olib keladi.

Mexanizm: Xavflar: (1) .php/.jsp yuklab, serverda bajartirish; (2) ../../etc/passwd kabi nom bilan path traversal; (3) MIME'ni aldab, HTML/SVG yuklab XSS; (4) juda katta fayl bilan DoS.

Kod misol:

const multer = require('multer');

//  Tur, hajm, nom nazorati
const upload = multer({
  limits: { fileSize: 5 * 1024 * 1024 }, // 5MB — DoS himoyasi
  fileFilter: (req, file, cb) => {
    const allowed = ['image/jpeg', 'image/png', 'image/webp'];
    if (!allowed.includes(file.mimetype)) return cb(new Error('Ruxsatsiz tur'));
    cb(null, true);
  },
});

app.post('/upload', upload.single('img'), (req, res) => {
  //  Nomni server generatsiya qiladi (foydalanuvchi nomiga ishonmaymiz)
  const safeName = `${crypto.randomUUID()}.jpg`; // path traversal yo'q
  //  Kontent turini "magic bytes" bilan tekshirish (kengaytmaga emas)
  //  Web root'dan tashqarida yoki alohida domen/CDN'da saqlash
});

Himoya usullari:

• Fayl turi va hajmini cheklang; MIME'ni magic bytes bilan tasdiqlang.
• Fayl nomini server generatsiya qilsin (UUID); foydalanuvchi nomini yo'lga qo'ymang.
• Fayllarni web root'dan tashqarida yoki alohida (cookie-less) domen/CDN'da saqlang — yuklangan fayl bajarilmasin.
• Rasm bo'lsa qayta encode/resize qiling (yashirin payload yo'qoladi).
• Antivirus skaneri (masalan, ClamAV) yuqori xavfli muhitda.

Follow-up: Nega yuklangan fayllarni asosiy domendan alohida (masalan, usercontent.example.com) saqlash tavsiya etiladi? (Javob: agar fayl HTML/JS bo'lsa va bajarilsa, u alohida origin'da bo'lgani uchun asosiy saytning cookie/session'iga (same-origin) yeta olmaydi — XSS ta'siri cheklanadi.)

24. API xavfsizligi

S: REST API'ni xavfsiz qilishning asosiy tamoyillari qanday? (Senior) J: Ta'rif: API xavfsizligi — autentifikatsiya, avtorizatsiya, kirish nazorati, ma'lumot himoyasi va suiiste'moldan (abuse) himoyani birlashtiradi.

Mexanizm: API to'g'ridan-to'g'ri (brauzersiz) chaqiriladi — UI cheklovlariga tayanib bo'lmaydi. Har endpoint mustaqil himoyalanishi, har so'rov autentifikatsiya + avtorizatsiya + validatsiyadan o'tishi kerak.

Kod misol:

//  Qatlamli himoya — har biri alohida vazifa
app.post('/api/v1/orders',
  rateLimiter,                 // suiiste'moldan
  authenticate,                // kim (AuthN)
  authorize('customer'),       // huquq (AuthZ)
  validate(orderSchema),       // input validatsiya
  async (req, res) => {
    const order = await createOrder({ ...req.body, userId: req.user.id });
    res.status(201).json(order); // faqat kerakli maydonlar
  }
);

Himoya usullari:

• Hamma joyda HTTPS; har so'rovda AuthN + AuthZ.
• Input validatsiya (schema) va output filtering (ortiqcha maydon qaytarmang — over-posting/mass assignment).
• Rate limiting va pagination (katta javob bilan DoS'ni oldini olish).
• Versiyalash (/v1/), aniq CORS, xato xabarlarida ichki tafsilotni yashirish.
• GraphQL bo'lsa — query chuqurligi/murakkabligini cheklash.

Follow-up: Mass assignment (over-posting) zaifligi nima? (Javob: { ...req.body } ni to'g'ridan-to'g'ri modelga berish — foydalanuvchi isAdmin: true yoki role kabi kutilmagan maydonni qo'shib yuborishi mumkin. Yechim: faqat ruxsat etilgan maydonlarni oling (whitelist/DTO).)

25. Security misconfiguration

S: Security misconfiguration nima? Ishlab chiqarishga (production) chiqishdan oldin nimalarni tekshirasiz? (Middle) J: Ta'rif: Security misconfiguration — noto'g'ri yoki e'tiborsiz sozlamalar tufayli yuzaga keladigan zaiflik (OWASP A05): default parollar, ochiq debug, ortiqcha ruxsatlar.

Mexanizm: Ko'pincha "ishladi, demak bo'ldi" deb, xavfsiz bo'lmagan default'lar production'ga chiqib ketadi: batafsil xato (stack trace) sirlarni oshkor qiladi; debug endpoint'lar ochiq qoladi; CORS *; default admin/admin parol.

Kod misol:

//  ZAIF — production'da xatoni to'liq ko'rsatish
app.use((err, req, res, next) => {
  res.status(500).json({ error: err.message, stack: err.stack }); // sirlarni oshkor
});

//  HIMOYA — production'da umumiy xabar, log ichkarida
app.use((err, req, res, next) => {
  logger.error(err); // to'liq — faqat log'da
  const isDev = process.env.NODE_ENV !== 'production';
  res.status(err.status || 500).json({
    error: isDev ? err.message : 'Ichki xatolik',
  });
});

Himoya usullari (production checklist):

• NODE_ENV=production; debug/verbose xatolarni o'chiring.
• Default parol/kalitlarni almashtiring; keraksiz xizmat/port'larni yoping.
• Security header'lar (Helmet), aniq CORS, HTTPS + HSTS.
• Admin/debug endpoint'larga kirishni cheklang yoki o'chiring.
• Bog'liqliklarni yangilang (npm audit); X-Powered-By ni o'chiring.

Follow-up: Nega production'da to'liq stack trace qaytarish xavfli? (Javob: stack trace fayl yo'llari, kutubxona versiyalari, ba'zan sirlarni oshkor qiladi — hujumchiga ilova ichki tuzilishini xaritalashda yordam beradi.)

Eng ko'p so'raladigan savollar

Vaqtingiz kam bo'lsa, avval shularga ravon javob bera olishga tayyorlaning. Bular deyarli har full-stack intervyuda uchraydi:

1. XSS nima va uch turini (stored/reflected/DOM) qanday farqlaysiz? Qanday himoyalanasiz? escape, CSP, textContent, DOMPurify.
2. SQL injection qanday ishlaydi va asosiy himoyasi nima? parametrli so'rov (prepared statement).
3. CSRF nima va XSS'dan farqi? cookie'ning avtomatik jo'natilishi; himoya: CSRF token + SameSite cookie.
4. Authentication va Authorization farqi? "kimsiz?" vs "nima mumkin?"; 401 vs 403.
5. JWT'ni qayerda saqlaysiz — XSS vs CSRF trade-off? httpOnly+Secure+SameSite cookie; qisqa access + refresh rotation.
6. Parolni qanday saqlaysiz? Nega MD5/SHA yaramaydi? bcrypt/argon2, salt, ataylab sekin.
7. HTTPS/TLS qanday ishlaydi? sertifikat + asymmetric kalit almashish symmetric shifrlash.
8. CORS nima va "CORS xatosi" aslida nimani anglatadi? brauzer siyosati; javobni JS'dan yashirish, so'rovni bloklash emas.
9. OWASP Top 10'dan uchtasini misol bilan ayting. Injection, Broken Access Control, Security Misconfiguration.
10. IDOR nima? egalik tekshirilmasa, id almashtirib begona resursga kirish; himoya: har so'rovda huquq tekshiruvi.
11. Encryption vs hashing farqi? ikki tomonlama (kalit bilan qaytadi) vs bir tomonlama.
12. Brute force'ni qanday to'xtatasiz? rate limiting, account lockout, CAPTCHA, 2FA.
13. Sirlarni (API key) qanday boshqarasiz? env/secrets manager, .gitignore, sizsa — rotation.
14. Security header'lar (Helmet) nima beradi? CSP, HSTS, X-Frame-Options, nosniff.

Intervyu maslahati: har javobni "hujum mexanizm himoya" tartibida quring. "SQL injection'dan qo'rqaman" emas, "SQL injection foydalanuvchi kiritmasini so'rovga qo'shganda bo'ladi; men parametrli so'rov bilan buni to'xtataman va DB user'iga least privilege beraman" deng. Bitta himoyaga emas, chuqur himoyaga (defense in depth) urg'u bering — bu Senior darajani ko'rsatadi.