برای ایمن نگه داشتن منابع Firebase و دادههای کاربران خود، این دستورالعملها را دنبال کنید. همه موارد لزوماً مطابق با الزامات شما نیستند، اما هنگام توسعه برنامه خود آنها را در نظر داشته باشید.
از ترافیکهای بیمورد جلوگیری کنید
تنظیم نظارت و هشدار برای سرویسهای backend
برای شناسایی ترافیک سوءاستفادهگر، مانند حملات انکار سرویس (DOS)، نظارت و هشدار را برای Cloud Firestore ، Realtime Database ، Cloud Storage و Hosting تنظیم کنید.
اگر به حملهای به برنامه خود مشکوک هستید، در اسرع وقت با پشتیبانی تماس بگیرید تا آنها را از آنچه اتفاق میافتد مطلع کنید.
فعال کردن App Check
برای اطمینان از اینکه فقط برنامههای شما میتوانند به سرویسهای backend شما دسترسی داشته باشند، Firebase App Check برای هر سرویسی که از آن پشتیبانی میکند، فعال کنید.
Cloud Functions خود را برای مقیاسپذیری در ترافیک عادی پیکربندی کنید
Cloud Functions به طور خودکار برای برآورده کردن خواستههای برنامه شما مقیاسبندی میشوند، اما در صورت حمله، این میتواند به معنای هزینه زیادی باشد. برای جلوگیری از این امر، میتوانید تعداد نمونههای همزمان یک تابع را بر اساس ترافیک عادی برنامه خود محدود کنید .
هشدار را تنظیم کنید تا وقتی به محدودیتها نزدیک میشوید، مطلع شوید
اگر سرویس شما با افزایش ناگهانی درخواست مواجه شود، اغلب سهمیهبندیها اعمال میشوند و به طور خودکار ترافیک برنامه شما را کاهش میدهند. حتماً داشبورد مصرف و صورتحساب خود را رصد کنید، اما میتوانید هشدارهای بودجه را نیز روی پروژه خود تنظیم کنید تا در صورت فراتر رفتن مصرف منابع از انتظارات، مطلع شوید.
جلوگیری از خود-دوزی: تست توابع به صورت محلی با شبیهسازها
هنگام توسعه Cloud Functions به راحتی میتوان به طور تصادفی خودتان را دچار DOS کرد: برای مثال، با ایجاد یک حلقه بینهایت trigger-write. میتوانید با انجام توسعه خود با Firebase Local Emulator Suite از تأثیرگذاری این اشتباهات بر سرویسهای زنده جلوگیری کنید.
و اگر خودتان تصادفاً DOS انجام دادید، تابع خود را با حذف آن از index.js و سپس اجرا، از حالت استقرار خارج کنید.firebase deploy --only functions . (توابع فقط توابع فایربیس)
جایی که پاسخگویی بلادرنگ اهمیت کمتری دارد، ساختار به صورت تدافعی عمل میکند
اگر نیازی به ارائه نتیجه یک تابع به صورت بلادرنگ ندارید، میتوانید با پردازش نتایج به صورت دستهای، از ترافیک غیرمجاز جلوگیری کنید: نتایج را در یک موضوع Pub/Sub منتشر کنید و نتایج را در فواصل منظم با یک تابع زمانبندی شده پردازش کنید.
درک کلیدهای API
کلیدهای API برای سرویسهای فایربیس محرمانه نیستند
کلیدهای API برای سرویسهای Firebase فقط پروژه و برنامه Firebase شما را به آن سرویسها معرفی میکنند . مجوزدهی از طریق مجوزهای Google Cloud IAM، Firebase Security Rules و Firebase App Check انجام میشود.
تمام کلیدهای API ارائه شده توسط Firebase به طور خودکار به APIهای مرتبط با Firebase محدود میشوند. اگر تنظیمات برنامه شما از دستورالعملهای این صفحه پیروی کند، نیازی نیست کلیدهای API محدود شده به سرویسهای Firebase به عنوان اطلاعات محرمانه در نظر گرفته شوند و میتوان آنها را با خیال راحت در کد یا فایلهای پیکربندی خود قرار داد.
محدودیتهای کلید API را تنظیم کنید
اگر از کلیدهای API برای سایر سرویسهای گوگل استفاده میکنید، مطمئن شوید که محدودیتهای کلید API را برای محدودهی کلیدهای API خود در کلاینتهای برنامه و APIهایی که استفاده میکنید، اعمال میکنید.
از کلیدهای API ارائه شده توسط Firebase خود فقط برای APIهای مرتبط با Firebase استفاده کنید. اگر برنامه شما از APIهای دیگری استفاده میکند (مثلاً Places API برای نقشهها یا Gemini Developer API )، از یک کلید API جداگانه استفاده کنید و آن را به API مربوطه محدود کنید.
کلیدهای سرور FCM را مخفی نگه دارید
برخلاف کلیدهای API برای سرویسهای Firebase، کلیدهای سرور FCM (که توسط FCM HTTP API قدیمی استفاده میشوند) حساس هستند و باید مخفی نگه داشته شوند.
کلیدهای حساب سرویس را مخفی نگه دارید
برخلاف کلیدهای 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+ ، اندروید ، وب ، یونیتی ، C++ ).
برای مثالی از استفاده از احراز هویت سفارشی با یک ارائهدهنده شخص ثالث، به پست وبلاگ « احراز هویت با Firebase با استفاده از Okta» مراجعه کنید.
احراز هویت مدیریتشده: ارائهدهندگان OAuth 2.0 امنترین هستند
اگر از ویژگیهای احراز هویت مدیریتشدهی فایربیس استفاده میکنید، گزینههای ارائهدهندهی OAuth 2.0 / OpenID Connect (گوگل، فیسبوک و غیره) امنترین گزینهها هستند. در صورت امکان (بسته به پایگاه کاربری خود)، باید از یک یا چند مورد از این ارائهدهندگان پشتیبانی کنید.
احراز هویت از طریق ایمیل و رمز عبور: برای جلوگیری از حملات جستجوی فراگیر، سهمیهبندی دقیقی برای نقطه پایانی ورود تعیین کنید.
اگر از سرویس احراز هویت ایمیل-رمز عبور مدیریتشدهی فایربیس استفاده میکنید، سهمیهی پیشفرض نقاط پایانی identitytoolkit.googleapis.com را محدود کنید تا از حملات جستجوی فراگیر جلوگیری شود. میتوانید این کار را از صفحهی API ابزار هویت در کنسول Google Cloud انجام دهید.
احراز هویت ایمیل با رمز عبور: فعال کردن حفاظت از شمارش ایمیل
اگر از سرویس احراز هویت ایمیل-رمز عبور مدیریتشدهی فایربیس استفاده میکنید، گزینهی email enumeration protection را فعال کنید تا از سوءاستفادهی عوامل مخرب از نقاط پایانی احراز هویت پروژهی شما برای حدس زدن نام حسابها جلوگیری شود.
برای احراز هویت چند عاملی، به Google Cloud Identity Platform ارتقا دهید
برای امنیت بیشتر هنگام ورود به سیستم، میتوانید با ارتقا به Google Cloud Identity Platform ، پشتیبانی از احراز هویت چند عاملی را اضافه کنید. کد Firebase Authentication فعلی شما پس از ارتقا نیز به کار خود ادامه خواهد داد.
احراز هویت ناشناس
فقط از احراز هویت ناشناس برای ورود گرم (Warm Onboarding) استفاده کنید.
فقط از احراز هویت ناشناس برای ذخیره وضعیت اولیه کاربران قبل از ورود واقعی آنها استفاده کنید. احراز هویت ناشناس جایگزینی برای ورود کاربر نیست.
اگر کاربران میخواهند دادههایشان روی دستگاههای دیگر باشد، روش ورود به سیستم را به روش دیگری تغییر دهند.
دادههای احراز هویت ناشناس در صورتی که کاربر حافظه محلی را پاک کند یا دستگاه خود را تغییر دهد، باقی نمیمانند . اگر نیاز دارید که دادهها پس از راهاندازی مجدد برنامه در یک دستگاه واحد، حفظ شوند، حساب کاربری را به یک حساب دائمی تبدیل کنید .
از قوانین امنیتی استفاده کنید که کاربران را ملزم به استفاده از یک ارائه دهنده ورود به سیستم یا تأیید ایمیل خود میکند.
هر کسی میتواند یک حساب کاربری ناشناس در پروژه شما ایجاد کند. با توجه به این نکته، از تمام دادههای غیرعمومی با قوانین امنیتی که نیاز به روشهای ورود خاص یا آدرسهای ایمیل تأیید شده دارند، محافظت کنید.
برای مثال:
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 بین فراخوانیهای تابع، از محیطها استفاده مجدد میکنند، اطلاعات حساس نباید در محیط ذخیره شوند.
برای ذخیره کلیدهای API فایربیس (که مخفی نیستند )، کافیست آنها را در کد جاسازی کنید.
اگر از Firebase Admin SDK در Cloud Functions استفاده میکنید، نیازی به ارائه صریح اعتبارنامههای حساب سرویس ندارید، زیرا Admin SDK میتواند به طور خودکار آنها را در حین مقداردهی اولیه دریافت کند.
اگر APIهای گوگل و Google Cloud را فراخوانی میکنید که به اعتبارنامههای حساب سرویس نیاز دارند، کتابخانه Google Auth برای Node.js میتواند این اعتبارنامهها را از اعتبارنامههای پیشفرض برنامه که بهطور خودکار در Cloud Functions ذخیره میشوند، دریافت کند.
برای اینکه کلیدهای خصوصی و اعتبارنامههای مربوط به سرویسهای غیر گوگل را در دسترس Cloud Functions خود قرار دهید، از Secret Manager استفاده کنید.
رمزگذاری اطلاعات حساس
اگر نمیتوانید از ارسال اطلاعات حساس به توابع خود اجتناب کنید، باید راهحل سفارشی خودتان را برای رمزگذاری اطلاعات ارائه دهید.
توابع ساده امنتر هستند؛ اگر به پیچیدگی نیاز دارید، Cloud Run در نظر بگیرید.
سعی کنید توابع خود را تا حد امکان ساده و قابل فهم نگه دارید. پیچیدگی در توابع شما اغلب میتواند منجر به اشکالات غیرقابل تشخیص یا رفتارهای غیرمنتظره شود.
اگر به پیکربندیهای پیچیده منطقی یا محیطی نیاز دارید، به جای Cloud Functions ، استفاده از Cloud Run را در نظر بگیرید.
مدیریت محیط زیست
راهاندازی پروژههای توسعه و مرحلهبندی
پروژههای Firebase جداگانهای را برای توسعه، مرحلهبندی و تولید راهاندازی کنید. کد کلاینت را تا زمانی که در پروژه مرحلهبندی آزمایش نشده است، با کد تولید ادغام نکنید.
محدود کردن دسترسی تیم به دادههای تولید
اگر با یک تیم بزرگتر کار میکنید، میتوانید با محدود کردن دسترسی به دادههای عملیاتی با استفاده از نقشهای IAM از پیش تعریف شده یا نقشهای IAM سفارشی ، عواقب اشتباهات و نقضها را کاهش دهید.
اگر تیم شما از Firebase Local Emulator Suite (که توصیه میشود) برای توسعه استفاده میکند، ممکن است نیازی به اعطای دسترسی گستردهتر به پروژه عملیاتی نداشته باشید.
مدیریت کتابخانه
مراقب غلطهای املایی کتابخانه یا تغییرات جدید در کدها باشید
هنگام افزودن کتابخانهها به پروژه خود، به نام کتابخانه و نگهدارندگان آن توجه زیادی داشته باشید. کتابخانهای با نام مشابه با کتابخانهای که قصد نصب آن را دارید، میتواند حاوی کد مخرب باشد.
کتابخانهها را بدون درک تغییرات بهروزرسانی نکنید
قبل از ارتقا، به گزارش تغییرات هر کتابخانهای که استفاده میکنید نگاهی بیندازید. مطمئن شوید که ارتقا ارزش افزوده ایجاد میکند و بررسی کنید که نگهدارنده هنوز طرف مورد اعتماد شماست.
کتابخانههای watchdog را به عنوان وابستگیهای dev یا test نصب کنید
از کتابخانهای مانند Snyk برای اسکن پروژه خود جهت یافتن وابستگیهای ناامن استفاده کنید.
مانیتورینگ را برای Cloud Functions تنظیم کنید؛ پس از بهروزرسانیهای کتابخانه، آن را بررسی کنید
اگر از SDK ثبتکننده Cloud Functions استفاده میکنید، میتوانید رفتارهای غیرمعمول، از جمله رفتارهای ناشی از بهروزرسانیهای کتابخانه، را رصد کرده و از آنها مطلع شوید .