اصلاح قوانین ناامن

از این راهنما برای درک آسیب‌پذیری‌های رایج در پیکربندی‌های Cloud Firestore Security Rules، مرور و ایمن‌تر کردن قوانین خود، و آزمایش تغییراتتان قبل‌از استقرار آن‌ها استفاده کنید.

Help me use Firebase in my app.
1. Make sure that **Firebase agent skills** are installed and updated. For Claude Code, Codex, or Cursor agents, help me install the Firebase plugin. For other agents, run `npx skills add firebase/agent-skills`. Always try to use **Firebase agent skills** for Firebase-related tasks.
2. Help me write, validate, and deploy Firebase Security Rules to protect my app's Firestore data.

اگر هشداری دریافت کردید مبنی بر اینکه پایگاه داده Cloud Firestore شما به‌درستی ایمن نشده است، می‌توانید با اصلاح و آزمایش Cloud Firestore Security Rules، آسیب‌پذیری‌ها را برطرف کنید.

برای مشاهده «قوانین امنیتی» موجود، به برگه قوانین در کنسول Firebase بروید.

درک کردن Cloud Firestore Security Rules

Cloud Firestore Security Rules از داده‌های شما دربرابر کاربران مخرب محافظت می‌کند. قوانین پیش‌فرض برای هر نمونه Cloud Firestore ایجادشده در کنسول Firebase، دسترسی را برای همه کاربران رد می‌کند. برای توسعه برنامه‌تان و دسترسی به پایگاه داده‌تان، باید آن قوانین را اصلاح کنید و شاید لازم باشد دسترسی کلی به همه کاربران در محیط توسعه نرم‌افزار اعطا کنید. بااین‌حال، قبل‌از استقرار برنامه‌تان در محیط تولید، وقت بگذارید تا قوانینتان را به‌درستی پیکربندی کنید و داده‌هایتان را ایمن کنید.

هنگام توسعه برنامه و آزمایش پیکربندی‌های مختلف برای قوانینتان، از شبیه‌ساز Cloud Firestore برای اجرای برنامه در محیط توسعه محلی استفاده کنید.

سناریوهای رایج با قوانین ناامن

Cloud Firestore Security Rules که ممکن است به‌طور پیش‌فرض یا در ابتدای کار روی توسعه برنامه‌تان با Cloud Firestore راه‌اندازی کرده باشید باید قبل‌از استقرار برنامه‌تان بازبینی و به‌روزرسانی شود. با اجتناب از تله‌های رایج زیر، مطمئن شوید که داده‌های کاربران را به‌درستی ایمن می‌کنید.

دسترسی آزاد

هنگام راه‌اندازی Cloud Firestore، ممکن است قوانینتان را طوری تنظیم کرده باشید که دسترسی باز را درطول توسعه مجاز کند. ممکن است فکر کنید شما تنها فردی هستید که از برنامه‌تان استفاده می‌کند، اما اگر آن را مستقر کرده باشید، در اینترنت دردسترس است. اگر کاربران را اصالت‌سنجی نکنید و قوانین امنیتی را پیکربندی نکنید، هرکسی که شناسه پروژه شما را حدس بزند می‌تواند داده‌ها را سرقت، اصلاح، یا حذف کند.

// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this rule set in production; it allows
// anyone to overwrite your entire database.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      // Allow reads and deletion if the current user owns the existing document
      allow read, delete: if request.auth.uid == resource.data.author_uid;
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;

    }
  }
}
  

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      // Allow public reads
      allow read: if true
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;
      // Allow deletion if the current user owns the existing document
      allow delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}
  

دسترسی برای هر کاربر اصالت‌سنجی‌شده

گاهی اوقات، Cloud Firestore Security Rules بررسی می‌کند که کاربر به سیستم وارد شده باشد، اما دسترسی را براساس آن اصالت‌سنجی بیشتر محدود نمی‌کند. اگر یکی از قوانین شما شامل auth != null است، تأیید کنید که می‌خواهید هر کاربر واردشده به سیستم به داده‌ها دسترسی داشته باشد.

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth != null;
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Assign roles to all users and refine access based on user roles
    match /some_collection/{document} {
     allow read: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"

     // Note: Checking for roles in your database using `get` (as in the code
     // above) or `exists` carry standard charges for read operations.
    }
  }
}

// Give each user in your database a particular attribute
// and set it to true/false
// Then, use that attribute to grant access to subsets of data
// For example, an "admin" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /collection/{document} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
      allow read: true;
    }
  }
}
  

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      allow read: if true
      allow write: if request.auth.uid == request.resource.data.author_uid
    }
  }
}
  

دسترسی برای نشانی‌های ایمیل تأییدنشده

گاهی اوقات، Cloud Firestore Security Rules بررسی می‌کند که ایمیل کاربر به دامنه خاصی تعلق داشته باشد. اگرچه این کار به‌طور کلی رویه خوبی است، اما ایمیل‌ها همیشه درطول ورود به سیستم درستی‌سنجی نمی‌شوند تا زمانی که کاربر پس‌از دریافت ایمیل درستی‌سنجی، مرحله دیگری را انجام دهد. مطمئن شوید که تأیید می‌کنید ایمیل واقعاً متعلق به کاربر است.

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email_verified
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

دسترسی بسته

هنگام توسعه برنامه، رویکرد رایج دیگر این است که داده‌هایتان را قفل نگه دارید. معمولاً این یعنی دسترسی خواندن و نوشتن را برای همه کاربران به‌صورت زیر بسته‌اید:

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Firebase Admin SDK و Cloud Functions همچنان می‌توانند به پایگاه داده شما دسترسی داشته باشند. وقتی قصد دارید از Cloud Firestore به‌عنوان باطن فقط سرور در ارتباط با Firebase Admin SDK استفاده کنید، از این قوانین استفاده کنید. درحالی‌که این روش ایمن است، باید آزمایش کنید که کارخواه‌های برنامه‌تان بتوانند داده‌ها را به‌درستی بازیابی کنند.

درباره Cloud Firestore Security Rules و نحوه عملکرد آن‌ها در شروع به کار با Cloud Firestore Security Rules بیشتر بدانید.

Cloud Firestore Security Rules را بررسی کنید

برای بررسی رفتار برنامه‌تان و درستی‌سنجی پیکربندی‌های Cloud Firestore Security Rules، از شبیه‌ساز Cloud Firestore استفاده کنید. قبل‌از استقرار هرگونه تغییر، از شبیه‌ساز Cloud Firestore برای اجرا و خودکارسازی آزمون‌های واحد در محیط محلی استفاده کنید.

برای آزمایش سریع Cloud Firestore Security Rules به‌روزشده در کنسول Firebase، از ابزار Rules Playground استفاده کنید.

1. برای باز کردن «زمین بازی قوانین»، روی زمین بازی قوانین در برگه قوانین کلیک کنید.
2. در تنظیمات محیط آزمایشی قوانین، گزینه‌های آزمایشتان را انتخاب کنید، ازجمله:
   • آزمایش خواندن یا نوشتن
   • مکان خاصی در پایگاه داده شما، به‌عنوان مسیر
   • نوع اصالت‌سنجی — اصالت‌سنجی‌نشده، کاربر ناشناس اصالت‌سنجی‌شده، یا شناسه کاربر خاص
   • داده‌های مختص سند که قوانین شما به‌طور خاص به آن‌ها ارجاع می‌دهند (برای مثال، اگر قوانین شما وجود فیلد خاصی را قبل‌از اجازه نوشتن الزامی کنند)
3. روی اجرا کلیک کنید و نتایج را در برنمای بالای پنجره قوانین ببینید.