Published on

Firebase security rules: ma'lumotlar bazasini xakerlardan himoyalash

Authors

Nega security rules kerak?

Dasturni yangi boshlaganimizda Firebase hammaga ochiq (Test Mode) bo'ladi. Agar siz dasturni shu holatda App Store'ga yuklasangiz, istalgan xaker sizning ma'lumotlar bazangizga ulanib, hamma narsani o'chirib yuborishi yoki o'zgartirishi mumkin. Shuning uchun biz Firestore Xavfsizlik qoidalarini (Security Rules) yozishimiz shart.

Bu qoidalar to'g'ridan-to'g'ri Firebase Console'da (Rules bo'limida) yoziladi. Ularni Swift'da yoza olmaymiz, ammo sintaksisi juda o'xshash.

1. Eng oddiy qoida: Faqat Ro'yxatdan o'tganlarga ruxsat (Auth)

Tasavvur qiling, sizning ilovangizga faqat ro'yxatdan o'tgan foydalanuvchilar kira oladi. Demak, bazani ham faqat shunday foydalanuvchilar uchun ochishimiz kerak:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // Barcha hujjatlar uchun qoida:
    match /{document=**} {
      allow read, write: if request.auth != null;
    }

  }
}

Qoida qanday o'qiladi: Agar kelayotgan so'rovning (request) autentifikatsiya ma'lumotlari bo'sh (null) bo'lmasa, unga o'qish va yozishga (read, write) ruxsat ber!

2. Foydalanuvchi faqat O'Z profilingina tahrirlay olsin

Tasavvur qiling, kodda xatolik ketdi va Dostonbek o'z ismini o'zgartiraman deb, Alisherning ismini o'zgartirib yubordi. Buning oldini olish uchun biz "User o'z IDsi bilan mos keladigan hujjatnigina tahrirlay oladi" degan qoida yozamiz:

match /users/{userId} {
  // Hamma foydalanuvchi ma'lumotlarini o'qishi mumkin
  allow read: if request.auth != null;

  // Ammo, yozish (write) faqat o'ziga ruxsat etiladi
  allow write: if request.auth.uid == userId;
}

3. Sub-collection (Ichki kolleksiya) uchun qoidalar

Kolleksiya ichidagi ichki kolleksiyalar o'zining Ota kolleksiyasidan xavfsizlik qoidalarini meros (inherit) qilib OLMAYDI. Har biri uchun alohida yozish kerak:

// Foydalanuvchilar kolleksiyasi
match /users/{userId} {
  allow read: if request.auth != null;
  allow write: if request.auth.uid == userId;

  // Ichki "Saralanganlar" kolleksiyasi qoidasi
  match /favorite_products/{favoriteProductId} {
    allow read: if request.auth != null;
    allow write: if request.auth.uid == userId;
  }
}

4. Ma'lumotning o'ziga qarab ruxsat berish (Visibility)

Bizda postlar bor. Ularning bazilari public (ommaviy), ba'zilari private (maxfiy). Maxfiy postlarni hech kim o'qimasligi kerak. Bunda biz bazadagi ma'lumotning (resource.data) o'zini tekshiramiz:

match /posts/{postId} {
  // Postning visibility maydoni 'public' bo'lsagina o'qishga ruxsat
  allow read: if resource.data.visibility == 'public';
}

5. Admin (Menejer) ruxsatlarini berish

Dasturingizda Mahsulotlar (Products) bor. Oddiy foydalanuvchilar uni faqat ko'ra oladi (read). Mahsulot qo'shish yoki o'chirishni faqat Admin qila olishi kerak.

  1. admins nomli kolleksiya ochamiz va unga adminlarning ID larini saqlaymiz.
  2. Security Rules'da funksiya yaratamiz va uni chaqiramiz:
match /products/{productId} {
  // Hamma o'qiy oladi
  allow read: if request.auth != null;
  // Faqat admin yarata, yangilay va o'chira oladi
  allow create, update, delete: if isAdmin(request.auth.uid);
}

// Adminni tekshiruvchi funksiya
function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}

Xulosa

Security Rules yozish biroz zerikarli bo'lishi mumkin, ammo ular sizning ilovangizning eng asosiy himoya devori hisoblanadi. Hech qachon ilovani App Store'ga test qoidalari (allow read, write: if true;) bilan chiqarmang.

Buy mea coffee