قوانین امنیتی پایه

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

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

برای دسترسی به قوانین و به‌روزرسانی آن‌ها، مراحل شرح‌داده‌شده در مدیریت و استقرار Firebase 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 data.

قوانین پیش‌فرض: حالت قفل‌شده

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

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

{
  "rules": {
    ".read": false,
    ".write": false
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

قوانین محیط توسعه نرم‌افزار

وقتی روی برنامه‌تان کار می‌کنید، ممکن است بخواهید دسترسی نسبتاً باز یا نامحدودی به داده‌هایتان داشته باشید. فقط مطمئن شوید که Security Rules را قبل‌از استقرار برنامه‌تان در تولید به‌روز کنید. همچنین به‌یاد داشته باشید که اگر برنامه‌تان را مستقر کنید، به‌طور عمومی قابل‌دسترسی است — حتی اگر آن را راه‌اندازی نکرده باشید.

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

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

هرچند توصیه نمی‌کنیم داده‌هایتان را برای هر کاربری که به سیستم وارد شده است قابل‌دسترس کنید، اما ممکن است مفید باشد که هنگام توسعه برنامه‌تان، دسترسی را برای هر کاربر اصالت‌سنجی‌شده‌ای تنظیم کنید.

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

{
  "rules": {
    "some_path": {
      ".read": "auth.uid !== null",
      ".write": "auth.uid !== null"
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /some_folder/{fileName} {
      allow read, write: if request.auth != null;
    }
  }
}

قوانین آماده تولید

وقتی برای استقرار برنامه‌تان آماده می‌شوید، مطمئن شوید که از داده‌هایتان محافظت می‌شود و دسترسی به‌درستی به کاربران شما اعطا می‌شود. از Authentication برای راه‌اندازی دسترسی مبتنی بر کاربر و خواندن مستقیم از پایگاه داده‌تان برای راه‌اندازی دسترسی مبتنی بر داده استفاده کنید.

هنگام ساختاردهی داده‌هایتان، نوشتن قوانین را درنظر بگیرید، زیرا نحوه تنظیم قوانین بر نحوه محدود کردن دسترسی به داده‌ها در مسیرهای مختلف تأثیر می‌گذارد.

دسترسی فقط برای مالک محتوا

این قوانین دسترسی را فقط به مالک اصالت‌سنجی‌شده محتوا محدود می‌کند. داده‌ها فقط توسط یک کاربر قابل‌خواندن و نوشتن است و مسیر داده‌ها حاوی شناسه کاربر است.

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

وقتی این قانون کار نمی‌کند: این مجموعه قانون وقتی کار نمی‌کند که چند کاربر باید داده‌های یکسانی را بنویسند یا بخوانند — کاربران داده‌ها را رونویسی می‌کنند یا نمی‌توانند به داده‌هایی که ایجاد کرده‌اند دسترسی داشته باشند.

برای راه‌اندازی این قانون: قانونی ایجاد کنید که تأیید کند کاربری که درخواست دسترسی برای خواندن یا نوشتن داده‌ها را دارد، همان کاربری است که مالک آن داده‌ها است.

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{userId}/{document} {
      allow read, write: if request.auth != null && request.auth.uid == userId
    }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth !== null && auth.uid === $uid",
        ".write": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

دسترسی عمومی و خصوصی مختلط

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

زمان عملکرد این قانون: این قانون برای برنامه‌هایی که به عناصر خواندنی عمومی نیاز دارند اما باید دسترسی ویرایش را به مالکان آن عناصر محدود کنند، به‌خوبی کار می‌کند. برای مثال، برنامه گپ یا وبلاگ.

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

برای تنظیم این قانون: قانونی ایجاد کنید که دسترسی خواندن را برای همه کاربران (یا همه کاربران اصالت‌سنجی‌شده) فعال کند و تأیید کند که کاربر نویسنده داده‌ها مالک است.

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;
    }
  }
}

{
// Allow anyone to read data, but only authenticated content owners can
// make changes to their data

  "rules": {
    "some_path": {
      "$uid": {
        ".read": true,
        // or ".read": "auth.uid !== null" for only authenticated users
        ".write": "auth.uid === $uid"
      }
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}

دسترسی مبتنی بر مشخصه و مبتنی بر نقش

برای اینکه این قانون کار کند، باید مشخصه‌هایی را برای کاربران در داده‌هایتان تعریف و اختصاص دهید. Firebase Security Rules درخواست را با داده‌های پایگاه داده یا فراداده فایل شما بررسی می‌کند تا دسترسی را تأیید یا رد کند.

زمان عملکرد این قانون: اگر نقشی را به کاربران اختصاص می‌دهید، این قانون به شما امکان می‌دهد دسترسی را براساس نقش‌ها یا گروه‌های خاصی از کاربران محدود کنید. برای مثال، اگر نمرات را ذخیره می‌کنید، می‌توانید سطوح دسترسی متفاوتی را به گروه «دانش‌آموزان» (فقط خواندن محتوای خودشان)، گروه «معلمان» (خواندن و نوشتن در موضوع خودشان)، و گروه «مدیران» (خواندن همه محتوا) اختصاص دهید.

وقتی این قانون کار نمی‌کند: در Realtime Database و Cloud Storage، قوانین شما نمی‌توانند از روش get() که قوانین Cloud Firestore می‌توانند دربرگیرند استفاده کنند. درنتیجه، باید پایگاه داده یا فراداده فایل خود را به‌گونه‌ای ساختاربندی کنید که ویژگی‌هایی را که در قوانین خود استفاده می‌کنید منعکس کند.

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

همچنین می‌توانید ادعاهای سفارشی را در Authentication راه‌اندازی کنید و سپس آن اطلاعات را از متغیر auth.token در هر Firebase Security Rules بازیابی کنید.

مشخصه‌ها و نقش‌های تعریف‌شده با داده

این قوانین فقط در Cloud Firestore و Realtime Database کار می‌کند.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, Check a boolean `admin` attribute
    allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
   }
  }
}

{
  "rules": {
    "some_path": {
      "${subpath}": {
        //
        ".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
        ".read": true
      }
    }
  }
}

مشخصه‌ها و نقش‌های ادعای سفارشی

برای اجرای این قوانین، ادعاهای سفارشی را در Firebase Authentication تنظیم کنید و سپس از این ادعاها در قوانین خود استفاده کنید.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an administrator claim
    allow write: if request.auth.token.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if request.auth.token.reader == "true";
     allow write: if request.auth.token.writer == "true";
   }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Create a custom claim for each role or group
        // you want to use
        ".write": "auth.uid !== null && auth.token.writer === true",
        ".read": "auth.uid !== null && auth.token.reader === true"
      }
    }
  }
}

service firebase.storage {
  // Allow reads if the group ID in your token matches the file metadata's `owner` property
  // Allow writes if the group ID is in the user's custom token
  match /files/{groupId}/{fileName} {
    allow read: if resource.metadata.owner == request.auth.token.groupId;
    allow write: if request.auth.token.groupId == groupId;
  }
}

مشخصه‌های اجاره

برای اجرای این قوانین، چندمستأجری را در Google Cloud Identity Platform (GCIP) راه‌اندازی کنید و سپس از مستأجر در قوانینتان استفاده کنید. مثال‌های زیر به کاربر در مستأجر خاصی، برای مثال tenant2-m6tyz، اجازه نوشتن می‌دهند

service cloud.firestore {
  match /databases/{database}/documents {
    // For tenant-based access control, check for a tenantID
    allow write: if request.auth.token.firebase.tenant == 'tenant2-m6tyz';
    allow read: true;
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Only allow reads and writes if user belongs to a specific tenant
        ".write": "auth.uid !== null && auth.token.firebase.tenant === 'tenant2-m6tyz'",
        ".read": "auth.uid !== null
      }
    }
  }
}

service firebase.storage {
  // Only allow reads and writes if user belongs to a specific tenant
  match /files/{tenantId}/{fileName} {
    allow read: if request.auth != null;
    allow write: if request.auth.token.firebase.tenant == tenantId;
  }
}