// docs / baas security / firebase if-true explainer

توضیح Firebase allow read, write: if true: چه می‌کند و چگونه آن را اصلاح کنیم

Q: تفاوت بین if true و if request.auth != null چیست؟

if true دسترسی ناشناس را اجازه میدهد — هر کسی در اینترنت. if request.auth != null هر کاربر واردشدهای را نیاز دارد، که بهتر است ولی همچنان اشتباه: هر کاربر اپلیکیشن شما میتواند داده هر کاربر دیگری را بخواند. قواعد تولید باید با request.auth.uid == resource.data.owner_uid یا مشابه به کاربر یا org خاص محدود شوند.

Q: آیا Firebase هرگز قواعد if true را بهطور خودکار منقضی میکند؟

پروژههای قدیمیتر (پیش از ۲۰۲۳) یک تایمر ۳۰ روزه داشتند که قواعد if true را به if false تبدیل میکرد. پروژههای فعلی این کار را نمیکنند — قانون تا زمانی که بهصورت دستی جایگزین نشود برای همیشه باقی میماند. اگر پروژه شما پیش از ۲۰۲۳ ایجاد شده و قواعد شما خوب به نظر میرسند، دوبار بررسی کنید: تایمر ممکن است قبلاً آنها را به if false برگردانده باشد که اپلیکیشن خود شما را مسدود میکند.

Q: اگر اپلیکیشن من واقعاً خواندن عمومی است (بلاگ، کاتالوگ محصول) چه؟

پس بهصراحت allow read: if true; allow write: if false; را فقط روی مجموعه عمومی بنویسید — نه روی هر مجموعه در پایگاهداده. از یک عبارت match جداگانه بهازای هر مجموعه استفاده کنید و هرگز از wildcard بازگشتی '{'document=**'}' روی قواعد قابل نوشتن استفاده نکنید.

<code>allow read, write: if true;</code> رایج‌ترین پیکربندی نادرست Firebase در تولید است. این پیش‌فرض حالت آزمایشی است که کنسول Firebase وقتی یک پایگاه‌داده جدید ایجاد می‌کنید پیشنهاد می‌دهد، قانونی است که ابزارهای کدنویسی هوش مصنوعی از مستندات بازتولید می‌کنند، و قانونی است که کل پایگاه‌داده Firestore شما را به هر کسی در اینترنت باز می‌کند. این مقاله نحو را با دقت توضیح می‌دهد، نشان می‌دهد یک مهاجم وقتی این قانون فعال است چه می‌بیند، و چهار جایگزین به‌تدریج محدودتر را ارائه می‌دهد که با موارد کاربرد مختلف سازگار هستند.

نحو، خط به خط

یک سند کامل قوانین حالت آزمایشی Firestore شش خط است:

firebase

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

رمزگشایی:

rules_version = '2'; موتور قواعد v2 (فعلی) را انتخاب می‌کند. قواعد قدیمی‌تر v1 منسوخ شده‌اند.
service cloud.firestore بلوک را به Firestore محدود می‌کند. Realtime Database از یک نحو متفاوت مبتنی بر JSON استفاده می‌کند؛ Cloud Storage از service firebase.storage استفاده می‌کند.
match /databases/{database}/documents پایگاه‌داده ویژه (default) را متصل می‌کند (بیشتر پروژه‌ها فقط یکی دارند).
match /{document=**} یک wildcard بازگشتی است. ** هر مسیری با هر عمقی را تطبیق می‌دهد. ترکیب با {document}، این هر سند در هر مجموعه‌ای را ضبط می‌کند — یک عبارت تطبیق واحد که کل پایگاه‌داده را حاکم می‌کند.
allow read, write: if true; بدنه قانون است. هم read و هم write اجازه داده شده‌اند؛ شرط if true، خب، همیشه درست است. read عملیات‌های get و list را پوشش می‌دهد؛ write عملیات‌های create، update و delete را پوشش می‌دهد.

اثر نهایی: هر کلاینتی با شناسه پروژه Firebase و SDK مناسب می‌تواند هر سندی را در هر مجموعه‌ای بخواند یا بنویسد. احراز هویت لازم نیست. محدودیت نرخ اعمال نمی‌شود.

چرا Firebase این را به‌عنوان پیش‌فرض ارائه می‌دهد

Firebase می‌خواهد شما در ۳۰ ثانیه اول پس از ایجاد یک پروژه در حال کدنویسی باشید. جایگزین — مجبور کردن شما به نوشتن یک قانون درست پیش از این‌که هر خواندن یا نوشتنی کار کند — onboarding را مسدود می‌کرد. پس کنسول وقتی یک پایگاه‌داده ایجاد می‌کنید دو گزینه ارائه می‌دهد: حالت تولید (همه چیز را رد کن، خودت قوانین را بنویس) یا حالت آزمایشی (همه چیز را به مدت ۳۰ روز اجازه بده). اکثر توسعه‌دهندگان روی حالت آزمایشی کلیک می‌کنند، سپس فراموش می‌کنند مرور کنند. پروژه‌های قدیمی‌تر یک تایمر ۳۰ روزه داشتند؛ پروژه‌های فعلی یک قانون if true نامحدود بدون انقضای خودکار دارند.

مشکل ساختاری: ابزارهای کدنویسی هوش مصنوعی روی مستندات، آموزش‌ها و پاسخ‌های Stack Overflow آموزش می‌بینند که قواعد حالت آزمایشی را نشان می‌دهند. وقتی از Cursor یا Claude Code می‌پرسید "چطور Firebase را راه‌اندازی کنم"، پاسخ اغلب شامل بلوک دقیق allow read, write: if true به‌گونه‌ای است که گویا قانون تولید است. هوش مصنوعی نمی‌داند — و تشویق نمی‌شود بداند — که این قانون برای تولید امن نیست.

یک مهاجم چه می‌بیند

به‌طور مشخص، مهاجمی که شناسه پروژه Firebase شما را می‌داند (در ۳۰ ثانیه از بسته هر اپلیکیشن مستقرشده قابل استخراج است) و موارد زیر را اجرا می‌کند، می‌تواند هر سند در هر مجموعه‌ای را فهرست کند:

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

bash

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

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

در مسیر نوشتن: یک POST ساده با {fields} یک سند جدید ایجاد می‌کند. مهاجمان می‌توانند مجموعه‌های شما را با زباله آلوده کنند، صفحات کاربری که از Firestore می‌خوانند را تخریب کنند، یا از پایگاه‌داده شما به‌عنوان یک message broker رایگان استفاده کنند — صورت‌حساب مصرف شما جهش می‌کند، شما بررسی می‌کنید، صورت‌حساب مشکل را توضیح می‌دهد.

چهار جایگزین امن تولید

جایگزینی را انتخاب کنید که با مدل داده اپلیکیشن شما مطابقت دارد. هر چهار فرض می‌کنند که شما احراز هویت کاربر دارید (Firebase Auth یا هر ارائه‌دهنده‌ای که یک Firebase ID token صادر می‌کند):

گزینه ۱: اسناد متعلق به کاربر

رایج‌ترین الگوی SaaS. اسناد زیر /users/{userId}/... قرار دارند و فقط مالک می‌تواند به آن‌ها دست بزند. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

گزینه ۲: فیلد مالک روی هر سند

وقتی اسناد در مجموعه‌های flat قرار دارند (تو در توی شناسه کاربر نیستند)، یک فیلد owner_uid ذخیره کنید و آن را بررسی کنید. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

firebase

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

گزینه ۳: ایزولاسیون چندمستأجری org

برای SaaS B2B با داده محدود به org. یک فیلد org_id روی هر سند ذخیره کنید و آن را در برابر claim سفارشی کاربر بررسی کنید. allow read, write: if request.auth.token.org_id == resource.data.org_id;. نیاز به تنظیم claim سفارشی در زمان ثبت‌نام از طریق Firebase Admin SDK دارد.

firebase

allow read, write: if request.auth.token.org_id == resource.data.org_id;

گزینه ۴: محتوای عمومی فقط-خواندن

برای محتوای بازاریابی، پروفایل‌های عمومی، کاتالوگ‌های محصول — هر چیزی که واقعاً خواندن عمومی است ولی فقط ادمین می‌نویسد. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. claim سفارشی admin فقط روی حساب‌های ادمین تنظیم می‌شود.

firebase

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

کوئری ممیزی سریع

پیش از اصلاح، بررسی کنید آیا if true واقعاً فعال است. کنسول Firebase → Firestore → Rules را باز کنید و برای if true جستجو کنید. اگر آن را خارج از یک کامنت پیدا کردید، یک یافته قانون باز دارید. شبیه‌ساز قوانین در همان UI به شما اجازه می‌دهد درخواست مهاجم را به‌صورت محلی بازپخش کنید — یک GET /users/somebody ناشناس را بچسبانید و تأیید کنید شبیه‌ساز Allowed برمی‌گرداند.

تأیید خارجی: یک اسکن FixVibe را روی URL تولیدی خود اجرا کنید. فحص baas.firebase-rules قواعد Firestore، Realtime Database و Storage شما را پروب می‌کند و همان یافته‌ای را که یک مهاجم کشف می‌کرد گزارش می‌دهد — مستقل از آنچه کنسول Firebase نشان می‌دهد.

سؤالات متداول

تفاوت بین <code>if true</code> و <code>if request.auth != null</code> چیست؟

if true دسترسی ناشناس را اجازه می‌دهد — هر کسی در اینترنت. if request.auth != null هر کاربر وارد‌شده‌ای را نیاز دارد، که بهتر است ولی همچنان اشتباه: هر کاربر اپلیکیشن شما می‌تواند داده هر کاربر دیگری را بخواند. قواعد تولید باید با request.auth.uid == resource.data.owner_uid یا مشابه به کاربر یا org خاص محدود شوند.

آیا Firebase هرگز قواعد <code>if true</code> را به‌طور خودکار منقضی می‌کند؟

پروژه‌های قدیمی‌تر (پیش از ۲۰۲۳) یک تایمر ۳۰ روزه داشتند که قواعد if true را به if false تبدیل می‌کرد. پروژه‌های فعلی این کار را نمی‌کنند — قانون تا زمانی که به‌صورت دستی جایگزین نشود برای همیشه باقی می‌ماند. اگر پروژه شما پیش از ۲۰۲۳ ایجاد شده و قواعد شما خوب به نظر می‌رسند، دوبار بررسی کنید: تایمر ممکن است قبلاً آن‌ها را به if false برگردانده باشد که اپلیکیشن خود شما را مسدود می‌کند.

آیا می‌توانم از بررسی timestamp تاریخ آینده به‌عنوان یک ایمنی استفاده کنم؟

خیر — یک شرط timestamp یک کنترل امنیتی نیست. قانون باز را در یک تاریخ آینده منقضی می‌کند، یعنی تا آن تاریخ مهاجمان دسترسی کامل دارند. و تاریخ را فراموش خواهید کرد. if true را با یک قانون محدود به auth جایگزین کنید، نه یک قانون محدود به زمان.

اگر اپلیکیشن من واقعاً خواندن عمومی است (بلاگ، کاتالوگ محصول) چه؟

پس به‌صراحت allow read: if true; allow write: if false; را فقط روی مجموعه عمومی بنویسید — نه روی هر مجموعه در پایگاه‌داده. از یک عبارت match جداگانه به‌ازای هر مجموعه استفاده کنید و هرگز از wildcard بازگشتی {document=**} روی قواعد قابل نوشتن استفاده نکنید.

گام‌های بعدی

یک اسکن FixVibe را روی URL تولیدی خود اجرا کنید — فحص baas.firebase-rules تأیید می‌کند آیا if true در حال حاضر از اینترنت عمومی قابل بهره‌برداری است. برای مکانیک‌های اسکنر و تشخیص‌های موازی برای Realtime Database و Storage، اسکنر قوانین Firebase را ببینید. برای کلاس معادل پیکربندی نادرست در Supabase، اسکنر Supabase RLS را بخوانید.