برای ایمن نگه داشتن منابع Firebase و داده‌های کاربران، این رهنمودها را دنبال کنید. همه موارد لزوماً برای الزامات شما اعمال نمی‌شوند، اما آن‌ها را در ذهن داشته باشید همان‌طور که برنامه خود را توسعه می‌دهید.
از ترافیک سوءاستفاده‌گرانه اجتناب کنید
راه‌اندازی پایش و هشدار برای خدمات پس‌زمینه
برای شناسایی ترافیک سوءاستفاده‌گرانه، مثل حمله‌های منع سرویس (DOS)، پایش و هشدار را برای Cloud Firestore، Realtime Database، Cloud Storage، و Hosting راه‌اندازی کنید
اگر به حمله‌ای به برنامه‌تان مشکوک هستید، در اسرع وقت با «پشتیبانی» تماس بگیرید تا آن‌ها را از آنچه درحال رخ دادن است مطلع کنید.
فعال کردن App Check
برای کمک به اطمینان از اینکه فقط برنامه‌های شما می‌توانند به سرویس‌های زیرینه شما دسترسی داشته باشند، Firebase App Check را برای هر سرویسی که از آن پشتیبانی می‌کند فعال کنید.
Cloud Functions را پیکربندی کنید تا برای ترافیک عادی مقیاس‌بندی شود
Cloud Functions به‌طور خودکار مقیاس‌بندی می‌شود تا نیازهای برنامه‌تان را برآورده کند، اما درصورت حمله، این کار می‌تواند به معنای صورت‌حساب سنگین باشد. برای جلوگیری از این امر، می‌توانید تعداد نمونه‌های هم‌زمان یک تابع را براساس ترافیک عادی برنامه‌تان محدود کنید.
تنظیم هشدار برای مطلع شدن از نزدیک شدن به محدودیت‌ها
اگر سرویس شما دارای جهش‌های درخواست باشد، اغلب سهمیه‌ها فعال می‌شوند و ترافیک برنامه شما را به‌طور خودکار محدود می‌کنند.
حتماً داشبورد استفاده و صورت‌حساب خود را پایش کنید.
هشدارهای بودجه را برای پروژه‌تان تنظیم کنید تا وقتی استفاده از منابع از حد انتظار فراتر رفت مطلع شوید.
اگر از Firebase AI Logic، Firebase App Hosting، Cloud Functions for Firebase، و Firebase Extensions استفاده می‌کنید، سقف هزینه تنظیم کنید تا اگر پروژه‌تان به بودجه تعیین‌شده برای آن سرویس رسید، سرویس مربوطه موقتاً متوقف شود.
جلوگیری از DOSes خود: آزمایش کردن توابع به‌صورت محلی با شبیه‌سازها
ممکن است درحین توسعه، به‌طور تصادفی خودتان را درمعرض حمله DOS قرار دهید Cloud Functions: برای مثال، با ایجاد یک حلقه نوشتن-راه‌انداز بی‌نهایت. با توسعه دادن با Firebase Local Emulator Suite می‌توانید از تأثیر این اشتباهات بر سرویس‌های فعال جلوگیری کنید.
و اگر به‌طور تصادفی خودتان را DOS کردید، تابع خود را با حذف آن از index.js و سپس اجرای firebase deploy --only functions
در مواردی که پاسخ‌گویی هم‌زمان اهمیت کمتری دارد، توابع را به‌صورت تدافعی ساختاربندی کنید
اگر لازم نیست نتیجه تابع را به‌صورت هم‌زمان ارائه دهید، می‌توانید با پردازش نتایج در دسته‌های بزرگ، ترافیک سوءاستفاده‌گرانه را کاهش دهید: نتایج را در موضوع Pub/Sub منتشر کنید و نتایج را در فواصل زمانی منظم با تابع زمان‌بندی‌شده پردازش کنید.
آشنایی با کلیدهای میانای برنامه‌سازی کاربردی
کلیدهای میانای برنامه‌سازی کاربردی برای سرویس‌های Firebase محرمانه نیستند
کلیدهای میانای برنامه‌سازی کاربردی برای سرویس‌های Firebase فقط پروژه و برنامه Firebase شما را برای آن سرویس‌ها شناسایی می‌کنند. صدور مجوز ازطریق اجازه‌های Google Cloud IAM، Firebase Security Rules، و Firebase App Check انجام می‌شود.
همه کلیدهای میانای برنامه‌سازی کاربردی (API) ارائه‌شده توسط Firebase به‌طور خودکار به میاناهای برنامه‌سازی کاربردی (API) مرتبط با Firebase محدود می‌شوند. اگر راه‌اندازی برنامه شما از دستورالعمل‌های این صفحه پیروی کند، دراین‌صورت کلیدهای API محدودشده به سرویس‌های Firebase نیازی ندارند به‌عنوان رمز درنظر گرفته شوند و افزودن آن‌ها به کد یا فایل‌های پیکربندی ایمن است.
تنظیم محدودیت‌های کلید میانای برنامه‌سازی کاربردی
اگر برای دیگر سرویس‌های Google از کلیدهای API استفاده می‌کنید، مطمئن شوید که محدودیت‌های کلید API را برای محدود کردن کلیدهای API به مشتریان برنامه و APIهایی که استفاده می‌کنید اعمال کنید.
از کلیدهای میانای برنامه‌سازی کاربردی (API) ارائه‌شده توسط Firebase فقط برای APIهای مرتبط با Firebase استفاده کنید. اگر برنامه‌تان از میاناهای برنامه‌سازی کاربردی دیگری (برای مثال، Places API برای Maps یا Gemini Developer API) استفاده می‌کند، از کلید میانای برنامه‌سازی کاربردی جداگانه‌ای استفاده کنید و آن را به میانای برنامه‌سازی کاربردی مربوطه محدود کنید.
کلیدهای سرور FCM را مخفی نگه دارید
برخلاف کلیدهای API برای سرویس‌های Firebase، FCM کلیدهای سرور (که توسط میانای برنامه‌سازی کاربردی HTTP FCM قدیمی) استفاده می‌شوند حساس هستند و باید محرمانه نگه داشته شوند.
فعال کردن گزارش ممیزی برای Cloud Messaging
برای Cloud Messaging، گزارش‌گیری ممیزی ابری را فعال کنید تا بتوانید فعالیت‌های مدیریتی و رویدادهای دسترسی را در منابع FCM خود ثبت کنید.
کلیدهای حساب سرویس را مخفی نگه دارید
برخلاف کلیدهای API برای سرویس‌های Firebase، کلیدهای خصوصی حساب سرویس (که توسط Firebase Admin SDK استفاده می‌شود) حساس هستند و باید محرمانه نگه داشته شوند.
Firebase Security Rules
مقداردهی اولیه قوانین در حالت تولید یا قفل‌شده
وقتی Cloud Firestore، Realtime Database، و Cloud Storage را راه‌اندازی می‌کنید، Firebase Security Rules را مقداردهی اولیه کنید تا به‌طور پیش‌فرض همه دسترسی‌ها را رد کند، و قوانینی اضافه کنید که با توسعه برنامه شما، دسترسی به منابع خاص را اعطا کنند.
برای نمونه‌های جدید Cloud Firestore (حالت تولید) و Realtime Database (حالت قفل‌شده)، از یکی از تنظیمات پیش‌فرض استفاده کنید. برای Cloud Storage، با پیکربندی قوانین امنیتی مانند زیر شروع کنید:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
قوانین امنیتی یک طرح‌واره هستند؛ هنگام افزودن اسناد، قوانین را اضافه کنید
قوانین امنیتی را پس‌از نوشتن برنامه، به‌عنوان نوعی وظیفه پیش‌از راه‌اندازی، ننویسید. درعوض، قوانین امنیتی را هنگام نوشتن برنامه خود بنویسید و با آن‌ها مانند یک طرح پایگاه داده: هر زمان که نیاز به استفاده از نوع سند جدید یا ساختار مسیر دارید، ابتدا قانون امنیتی آن را بنویسید.
قوانین امنیتی آزمون واحد با Local Emulator Suite؛ آن را به CI اضافه کنید
برای اطمینان از اینکه قوانین امنیتی‌تان با توسعه برنامه‌تان همگام است، قوانینتان را با Firebase Local Emulator Suite آزمایش واحد کنید و این آزمایش‌ها را به خط لوله CI خود اضافه کنید. این راهنماها را برای Cloud Firestore و Realtime Database ببینید.
اصالت‌سنجی
اصالت‌سنجی سفارشی: ایجاد JWT از محیط مورداعتماد (سمت سرور)
اگر ازقبل سیستم ورود به سیستم امنی دارید، چه سیستم سفارشی چه سرویس طرف سوم، می‌توانید از سیستم موجودتان برای اصالت‌سنجی با سرویس‌های Firebase استفاده کنید. JWTهای سفارشی را از یک محیط قابل اعتماد ایجاد کنید، سپس توکن‌ها را به مشتری خود منتقل کنید، که از توکن برای احراز هویت استفاده می‌کند (iOS+، Android، Web، Unity، C++).
برای نمونه‌ای از استفاده از اصالت‌سنجی سفارشی با ارائه‌دهنده شخص ثالث، پست وبلاگ اصالت‌سنجی با Firebase بااستفاده از Okta را ببینید.
اصالت‌سنجی مدیریت‌شده: ارائه‌دهندگان OAuth 2.0 امن‌ترین هستند
اگر از ویژگی‌های اصالت‌سنجی مدیریت‌شده Firebase استفاده می‌کنید، گزینه‌های ارائه‌دهنده OAuth 2.0 / OpenID Connect (Google، Facebook، و غیره) امن‌ترین گزینه‌ها هستند. درصورت امکان، باید از یک یا چند ارائه‌دهنده از این ارائه‌دهندگان پشتیبانی کنید (بسته به پایگاه کاربرتان).
اصالت‌سنجی ایمیل-گذرواژه: برای جلوگیری از حملات جستجوی فراگیر، سهمیه سخت‌گیرانه‌ای برای نقطه پایانی ورود به سیستم تنظیم کنید
اگر از سرویس اصالت‌سنجی مدیریت‌شده ایمیل-گذرواژه Firebase استفاده می‌کنید، سهمیه پیش‌فرض نقاط پایانی identitytoolkit.googleapis.com را محدود کنید تا از حملات جستجوی فراگیر جلوگیری شود. می‌توانید این کار را از
صفحه Identity Toolkit API
در کنسول Google Cloud انجام دهید.
اصالت‌سنجی ایمیل-گذرواژه: فعال کردن محافظت دربرابر شمارش ایمیل
اگر از سرویس اصالت‌سنجی مدیریت‌شده ایمیل-گذرواژه Firebase استفاده می‌کنید، محافظت دربرابر شمارش ایمیل را فعال کنید، که از سوءاستفاده عوامل مخرب از نقاط پایانی اصالت‌سنجی پروژه شما برای حدس زدن نام حساب‌ها جلوگیری می‌کند.
برای اصالت‌سنجی چندعاملی به Google Cloud Identity Platform ارتقا دهید
برای امنیت بیشتر هنگام ورود به سیستم، می‌توانید با ارتقا دادن به Google Cloud Identity Platform، پشتیبانی اصالت‌سنجی چندعاملی را اضافه کنید. کد Firebase Authentication فعلی‌تان پس‌از ارتقا همچنان کار خواهد کرد.
اصالت‌سنجی ناشناس
فقط از اصالت‌سنجی ناشناس برای آماده‌سازی گرم استفاده کنید
فقط از اصالت‌سنجی ناشناس برای ذخیره وضعیت پایه کاربران قبل‌از اینکه واقعاً به سیستم وارد شوند استفاده کنید. اصالت‌سنجی ناشناس جایگزینی برای ورود به سیستم کاربر نیست.
اگر کاربران بخواهند داده‌هایشان را در دستگاه‌های دیگر داشته باشند، آن‌ها را به روش ورود به سیستم دیگری تبدیل کنید
اگر کاربر فضای ذخیره‌سازی محلی را پاک کند یا دستگاهش را عوض کند، داده‌های اصالت‌سنجی ناشناس حفظ نخواهد شد. اگر لازم است داده‌ها را پس‌از بازراه‌اندازی برنامه در یک دستگاه حفظ کنید، کاربر را به حساب دائمی تبدیل کنید.
از قوانین امنیتی استفاده کنید که کاربران را ملزم می‌کند به ارائه‌دهنده ورود به سیستم تبدیل شده باشند یا ایمیل خود را درستی‌سنجی کرده باشند
هرکسی می‌تواند در پروژه شما حساب ناشناس ایجاد کند. با درنظر گرفتن این موضوع، از همه داده‌های غیرعمومی با قوانین امنیتی که به روش‌های ورود به سیستم خاص یا نشانی‌های ایمیل تأییدشده نیاز دارند محافظت کنید.
برای مثال:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
ایمنی Cloud Functions
هرگز اطلاعات حساس را در متغیرهای محیطی قرار ندهید
اغلب در برنامه Node.js خودمیزبان، از متغیرهای محیطی برای نگهداری اطلاعات حساس مثل کلیدهای خصوصی استفاده می‌کنید. این کار را در Cloud Functions انجام ندهید. ازآنجایی‌که Cloud Functions محیط‌ها را بین فراخوانی‌های تابع مجدداً استفاده می‌کند، اطلاعات حساس نباید در محیط ذخیره شود.
برای ذخیره کردن کلیدهای Firebase API (که محرمانه نیستند)، کافی است آن‌ها را در کد جاسازی کنید.
اگر از Firebase Admin SDK در Cloud Functions استفاده می‌کنید، نیازی نیست اطلاعات اعتباری حساب سرویس را به‌طور صریح ارائه دهید، زیرا Admin SDK می‌تواند آن‌ها را به‌طور خودکار درطول مقداردهی اولیه به‌دست آورد.
اگر با Google و میاناهای برنامه‌سازی کاربردی Google Cloud تماس می‌گیرید که به اعتبارنامه‌های حساب سرویس نیاز دارند، کتابخانه Google Auth برای Node.js می‌تواند این اعتبارنامه‌ها را از اعتبارنامه‌های پیش‌فرض برنامه دریافت کند که به‌طور خودکار در Cloud Functions پر می‌شوند.
برای دردسترس قرار دادن کلیدهای خصوصی و اطلاعات کاربری سرویس‌های غیرGoogle برای Cloud Functions، از Secret Manager استفاده کنید.
رمزگذاری اطلاعات حساس
اگر نمی‌توانید از ارسال اطلاعات حساس به توابع خود اجتناب کنید، باید راهکار سفارشی خود را برای رمزگذاری اطلاعات ارائه دهید.
توابع ساده ایمن‌تر هستند؛ اگر به پیچیدگی نیاز دارید، Cloud Run را درنظر بگیرید
سعی کنید توابع خود را تا حد امکان ساده و قابل‌فهم نگه دارید. پیچیدگی در توابع شما اغلب می‌تواند منجر به اشکالاتی شود که به‌سختی قابل‌تشخیص هستند یا رفتار غیرمنتظره‌ای داشته باشند.
اگر به منطق پیچیده یا پیکربندی‌های محیطی نیاز دارید، به‌جای Cloud Functions، از Cloud Run استفاده کنید.
مدیریت محیط
راه‌اندازی پروژه‌های توسعه و آماده‌سازی
پروژه‌های Firebase جداگانه‌ای برای توسعه، آماده‌سازی، و تولید راه‌اندازی کنید. کد مشتری را تا زمانی که در پروژه آماده‌سازی آزمایش نشده است با تولید ادغام نکنید.
محدود کردن دسترسی تیم به داده‌های تولید
اگر با تیم بزرگ‌تری کار می‌کنید، می‌توانید با محدود کردن دسترسی به داده‌های تولید بااستفاده از نقش‌های IAM ازپیش تعریف‌شده یا نقش‌های IAM سفارشی، پیامدهای اشتباهات و نقض‌ها را کاهش دهید.
اگر تیم شما از Firebase Local Emulator Suite (توصیه‌شده) برای توسعه استفاده می‌کند، ممکن است نیازی به اعطای دسترسی گسترده‌تر به پروژه تولید نداشته باشید.
مدیریت کتابخانه
مراقب غلط‌های املایی کتابخانه یا نگهدارندگان جدید باشید
هنگام افزودن کتابخانه‌ها به پروژه خود، به نام کتابخانه و نگهدارندگان آن توجه ویژه‌ای داشته باشید. کتابخانه‌ای با نام مشابه کتابخانه‌ای که قصد دارید نصب کنید می‌تواند حاوی کد مخرب باشد.
کتابخانه‌ها را بدون درک تغییرات به‌روز نکنید
قبل‌از ارتقا دادن، گزارش‌های تغییر هر کتابخانه‌ای را که استفاده می‌کنید بررسی کنید. مطمئن شوید که ارتقا ارزش افزوده‌ای ایجاد می‌کند و بررسی کنید که نگهدارنده همچنان طرفی باشد که به آن اعتماد دارید.
نصب کتابخانه‌های watchdog به‌عنوان وابستگی‌های توسعه‌دهنده یا آزمایشی
از کتابخانه‌ای مثل Snyk برای اسکن کردن پروژه‌تان ازنظر وابستگی‌های ناامن استفاده کنید.
راه‌اندازی پایش برای Cloud Functions؛ پس‌از به‌روزرسانی‌های کتابخانه آن را بررسی کنید
اگر از کیت توسعه نرم‌افزار ثبت‌کننده Cloud Functions استفاده می‌کنید، می‌توانید بر رفتار غیرعادی نظارت کنید و هشدار دریافت کنید، ازجمله رفتاری که به‌دلیل به‌روزرسانی‌های کتابخانه ایجاد شده است.