अपने फायरबेस संसाधनों और अपने उपयोगकर्ताओं के डेटा को सुरक्षित रखने के लिए इन दिशानिर्देशों का पालन करें। ज़रूरी नहीं है कि हर आइटम आपकी ज़रूरतों पर लागू हो, लेकिन अपना ऐप विकसित करते समय उन्हें ध्यान में रखें।
अपमानजनक यातायात से बचें
बैकएंड सेवाओं के लिए मॉनिटरिंग और अलर्ट सेट करें
अपमानजनक ट्रैफ़िक का पता लगाने के लिए, जैसे कि डिनायल-ऑफ़-सर्विस (DOS) हमले, क्लाउड फायरस्टोर , रीयलटाइम डेटाबेस , क्लाउड स्टोरेज और होस्टिंग के लिए निगरानी और अलर्ट सेट अप करें
यदि आपको अपने आवेदन पर हमले का संदेह है, तो जितनी जल्दी हो सके सहायता से संपर्क करें ताकि उन्हें पता चल सके कि क्या हो रहा है।
ऐप चेक सक्षम करें
यह सुनिश्चित करने में सहायता के लिए कि केवल आपके ऐप्स आपकी बैकएंड सेवाओं तक पहुंच सकते हैं, इसका समर्थन करने वाली प्रत्येक सेवा के लिए ऐप चेक सक्षम करें।
सामान्य ट्रैफ़िक के लिए स्केल करने के लिए अपने क्लाउड फ़ंक्शंस को कॉन्फ़िगर करें
क्लाउड फ़ंक्शंस स्वचालित रूप से आपके ऐप की मांगों को पूरा करने के लिए स्केल करता है, लेकिन हमले की स्थिति में, इसका मतलब एक बड़ा बिल हो सकता है। इसे रोकने के लिए, आप अपने ऐप के सामान्य ट्रैफ़िक के आधार पर किसी फ़ंक्शन के समवर्ती उदाहरणों की संख्या को सीमित कर सकते हैं।
जब सीमाएँ लगभग पूरी हो जाएँ तो अधिसूचित होने के लिए अलर्ट सेट करें
यदि आपकी सेवा में स्पाइक्स का अनुरोध है, तो अक्सर कोटा शुरू हो जाएगा, और स्वचालित रूप से आपके एप्लिकेशन पर ट्रैफ़िक को थ्रॉटल कर देगा। अपने उपयोग और बिलिंग डैशबोर्ड की निगरानी करना सुनिश्चित करें, लेकिन संसाधनों का उपयोग अपेक्षाओं से अधिक होने पर आप अपने प्रोजेक्ट पर बजट अलर्ट भी सेट कर सकते हैं।
स्व-डॉस को रोकें: इम्यूलेटर के साथ स्थानीय रूप से कार्यों का परीक्षण करें
क्लाउड फ़ंक्शंस विकसित करते समय गलती से खुद को डॉस करना आसान हो सकता है: उदाहरण के लिए, एक अनंत ट्रिगर-राइट लूप बनाकर। आप फायरबेस इम्यूलेटर सूट के साथ अपना विकास करके इन गलतियों को लाइव सेवाओं को प्रभावित करने से रोक सकते हैं।
(और यदि आप गलती से स्वयं डॉस करते हैं, तो इसे index.js से हटाकर फिर से
जहां वास्तविक समय की जवाबदेही कम महत्वपूर्ण है, संरचना रक्षात्मक रूप से कार्य करती है
यदि आपको वास्तविक समय में किसी फ़ंक्शन का परिणाम प्रस्तुत करने की आवश्यकता नहीं है, तो आप परिणामों को बैचों में संसाधित करके अपमानजनक ट्रैफ़िक के विरुद्ध कम कर सकते हैं: परिणामों को एक प्रकाशन /उप विषय पर प्रकाशित करें, और एक निर्धारित फ़ंक्शन के साथ नियमित अंतराल पर परिणामों को संसाधित करें .
एपीआई कुंजियों को समझें
फायरबेस सेवाओं के लिए एपीआई कुंजियां गुप्त नहीं हैं
फायरबेस केवल आपके ऐप के फायरबेस प्रोजेक्ट को फायरबेस सेवाओं की पहचान करने के लिए एपीआई कुंजी का उपयोग करता है, और डेटाबेस या क्लाउड स्टोरेज डेटा तक पहुंच को नियंत्रित करने के लिए नहीं, जो कि फायरबेस सुरक्षा नियमों का उपयोग करके किया जाता है। इस कारण से, आपको फायरबेस सेवाओं के लिए एपीआई कुंजियों को रहस्य के रूप में मानने की आवश्यकता नहीं है, और आप उन्हें क्लाइंट कोड में सुरक्षित रूप से एम्बेड कर सकते हैं। Firebase के लिए API कुंजियों के बारे में और जानें।
एपीआई कुंजी स्कूपिंग सेट करें
नकली अनुरोधों के लिए आपकी API कुंजी का उपयोग करने का प्रयास करने वाले हमलावर के विरुद्ध एक अतिरिक्त निवारक के रूप में, आप अपने ऐप क्लाइंट के लिए API कुंजियां बना सकते हैं।
FCM सर्वर कुंजियों को गुप्त रखें
Firebase सेवाओं के लिए API कुंजियों के विपरीत, FCM सर्वर कुंजियाँ ( विरासत FCM HTTP API द्वारा प्रयुक्त) संवेदनशील होती हैं और उन्हें गुप्त रखा जाना चाहिए।
सेवा खाता कुंजियों को गुप्त रखें
Firebase सेवाओं के लिए API कुंजियों के विपरीत, सेवा खाता निजी कुंजियाँ ( व्यवस्थापक SDK द्वारा उपयोग की जाती हैं ) संवेदनशील होती हैं और उन्हें गुप्त रखा जाना चाहिए।
सुरक्षा नियम
उत्पादन या लॉक मोड में नियमों को प्रारंभ करें
जब आप क्लाउड फायरस्टोर, रीयलटाइम डेटाबेस और क्लाउड स्टोरेज सेट करते हैं, तो डिफ़ॉल्ट रूप से सभी एक्सेस को अस्वीकार करने के लिए अपने सुरक्षा नियमों को प्रारंभ करें, और ऐसे नियम जोड़ें जो आपके ऐप को विकसित करते समय विशिष्ट संसाधनों तक पहुंच प्रदान करते हैं।
यह Cloud Firestore (प्रोडक्शन मोड) और रीयलटाइम डेटाबेस (लॉक मोड) के नए इंस्टेंस के लिए डिफ़ॉल्ट सेटिंग में से एक है। नया डेटाबेस इंस्टेंस सेट अप करते समय इस विकल्प को चुनें।
क्लाउड स्टोरेज के लिए, निम्न जैसे सुरक्षा नियम कॉन्फ़िगरेशन से प्रारंभ करें:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
सुरक्षा नियम एक स्कीमा हैं; जब आप दस्तावेज़ जोड़ते हैं तो नियम जोड़ें
एक प्रकार के पूर्व-लॉन्च कार्य के रूप में, अपना ऐप लिखने के बाद सुरक्षा नियम न लिखें। इसके बजाय, जब आप अपना ऐप लिखते हैं तो सुरक्षा नियम लिखें, उन्हें डेटाबेस स्कीमा की तरह मानते हुए: जब भी आपको किसी नए दस्तावेज़ प्रकार या पथ संरचना का उपयोग करने की आवश्यकता हो, तो पहले उसका सुरक्षा नियम लिखें।
एमुलेटर सूट के साथ यूनिट टेस्ट सुरक्षा नियम; इसे सीआई में जोड़ें
यह सुनिश्चित करने के लिए कि आपके सुरक्षा नियम आपके ऐप के विकास के साथ तालमेल बिठा रहे हैं, Firebase एमुलेटर सूट के साथ अपने नियमों का यूनिट परीक्षण करें और इन परीक्षणों को अपने CI पाइपलाइन में जोड़ें। Cloud Firestore और Realtime Database के लिए ये गाइड देखें।
प्रमाणीकरण
कस्टम प्रमाणीकरण: एक विश्वसनीय (सर्वर-साइड) वातावरण से मिंट JWTs
यदि आपके पास पहले से ही एक सुरक्षित साइन-इन सिस्टम है, चाहे कस्टम सिस्टम हो या तृतीय-पक्ष सेवा, तो आप फायरबेस सेवाओं के साथ प्रमाणित करने के लिए अपने मौजूदा सिस्टम का उपयोग कर सकते हैं। एक विश्वसनीय वातावरण से कस्टम JWTs बनाएं , फिर अपने क्लाइंट को टोकन पास करें, जो प्रमाणित करने के लिए टोकन का उपयोग करता है ( iOS+ , Android , Web , Unity , C++ )।
तृतीय-पक्ष प्रदाता के साथ कस्टम प्रमाणीकरण का उपयोग करने के उदाहरण के लिए, ब्लॉग पोस्ट देखें, ओक्टा का उपयोग करके फायरबेस के साथ प्रमाणीकरण करें ।
प्रबंधित प्रमाणीकरण: OAuth 2.0 प्रदाता सबसे सुरक्षित हैं
यदि आप फायरबेस की प्रबंधित प्रमाणीकरण सुविधाओं का उपयोग करते हैं, तो OAuth 2.0 / OpenID कनेक्ट प्रदाता विकल्प (Google, Facebook, आदि) सबसे सुरक्षित हैं। यदि आप कर सकते हैं तो आपको इनमें से एक या अधिक प्रदाताओं का समर्थन करना चाहिए (आपके उपयोगकर्ता आधार के आधार पर)।
ईमेल-पासवर्ड प्रमाणीकरण: क्रूर बल के हमलों को रोकने के लिए साइन-इन एंडपॉइंट के लिए तंग कोटा सेट करें
यदि आप फायरबेस की प्रबंधित ईमेल-पासवर्ड प्रमाणीकरण सेवा का उपयोग करते हैं, तो क्रूर बल के हमलों को रोकने के लिए identitytoolkit.googleapis.com एंडपॉइंट्स के डिफ़ॉल्ट कोटा को कस लें। आप Google क्लाउड कंसोल में एपीआई के पेज से ऐसा कर सकते हैं।
ईमेल-पासवर्ड प्रमाणीकरण: ईमेल गणना सुरक्षा सक्षम करें
यदि आप फायरबेस की प्रबंधित ईमेल-पासवर्ड प्रमाणीकरण सेवा का उपयोग करते हैं, तो ईमेल गणना सुरक्षा सक्षम करें , जो दुर्भावनापूर्ण अभिनेताओं को खाता नामों का अनुमान लगाने के लिए आपके प्रोजेक्ट के प्रमाणीकरण समापन बिंदुओं का दुरुपयोग करने से रोकती है।
मल्टी-फैक्टर ऑथेंटिकेशन के लिए क्लाउड आइडेंटिटी प्लेटफॉर्म में अपग्रेड करें
साइन-इन पर अतिरिक्त सुरक्षा के लिए, आप क्लाउड आइडेंटिटी प्लेटफ़ॉर्म में अपग्रेड करके बहु-कारक प्रमाणीकरण समर्थन जोड़ सकते हैं। अपग्रेड करने के बाद आपका मौजूदा फायरबेस ऑथेंटिकेशन कोड काम करना जारी रखेगा।
अनाम प्रमाणीकरण
वार्म ऑनबोर्डिंग के लिए केवल अनाम प्रमाणीकरण का उपयोग करें
उपयोगकर्ताओं के वास्तव में साइन इन करने से पहले उनकी बुनियादी स्थिति को बचाने के लिए केवल अनाम प्रमाणीकरण का उपयोग करें। अनाम प्रमाणीकरण उपयोगकर्ता साइन-इन का प्रतिस्थापन नहीं है।
यदि उपयोगकर्ता अपना फ़ोन खो देने पर डेटा चाहते हैं, तो उन्हें किसी अन्य साइन-इन विधि में रूपांतरित करें
यदि उपयोगकर्ता स्थानीय संग्रहण को साफ़ करता है या उपकरणों को स्विच करता है, तो अनाम प्रमाणीकरण डेटा बना नहीं रहेगा। यदि आपको एक डिवाइस पर ऐप के पुनरारंभ होने के बाद भी डेटा जारी रखने की आवश्यकता है, तो उपयोगकर्ता को एक स्थायी खाते में बदलें ।
उन सुरक्षा नियमों का उपयोग करें जिनके लिए उपयोगकर्ताओं को एक साइन इन प्रदाता में बदलने या अपने ईमेल को सत्यापित करने की आवश्यकता होती है
कोई भी आपके प्रोजेक्ट में एक अनाम खाता बना सकता है। इसे ध्यान में रखते हुए, सुरक्षा नियमों के साथ सभी गैर-सार्वजनिक डेटा की सुरक्षा करें, जिसके लिए विशिष्ट साइन-इन विधियों या सत्यापित ईमेल पतों की आवश्यकता होती है ।
उदाहरण के लिए:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
पर्यावरण प्रबंधन
विकास और मंचन परियोजनाओं की स्थापना करें
विकास, मंचन और उत्पादन के लिए अलग-अलग Firebase प्रोजेक्ट सेट अप करें। स्टेजिंग प्रोजेक्ट के खिलाफ परीक्षण किए जाने तक क्लाइंट कोड को उत्पादन में विलय न करें।
उत्पादन डेटा तक टीम की पहुंच सीमित करें
यदि आप एक बड़ी टीम के साथ काम करते हैं, तो आप पूर्वनिर्धारित भूमिकाओं या कस्टम IAM भूमिकाओं का उपयोग करके उत्पादन डेटा तक पहुँच को सीमित करके गलतियों और उल्लंघनों के परिणामों को कम कर सकते हैं।
यदि आपकी टीम विकास के लिए एमुलेटर सूट का उपयोग करती है, तो आपको उत्पादन परियोजना के लिए व्यापक पहुँच प्रदान करने की आवश्यकता नहीं हो सकती है।
पुस्तकालय प्रबंधन
लाइब्रेरी की गलत स्पेलिंग या नए मेंटेनर से सावधान रहें
अपने प्रोजेक्ट में लाइब्रेरी जोड़ते समय, लाइब्रेरी के नाम और उसके रख-रखाव पर पूरा ध्यान दें। आप जिस लाइब्रेरी को इंस्टॉल करना चाहते हैं, उसके समान नामित लाइब्रेरी में दुर्भावनापूर्ण कोड हो सकता है।
परिवर्तनों को समझे बिना पुस्तकालयों को अद्यतन न करें
अपग्रेड करने से पहले आपके द्वारा उपयोग की जाने वाली किसी भी लाइब्रेरी के परिवर्तन लॉग देखें। सुनिश्चित करें कि अपग्रेड मूल्य जोड़ता है, और जांचें कि अनुरक्षक अभी भी एक पार्टी है जिस पर आप भरोसा करते हैं।
वॉचडॉग लाइब्रेरी को देव या परीक्षण निर्भरता के रूप में स्थापित करें
असुरक्षित निर्भरताओं के लिए अपनी परियोजना को स्कैन करने के लिए Snyk जैसी लाइब्रेरी का उपयोग करें।
कार्यों के लिए निगरानी स्थापित करें; लाइब्रेरी अपडेट के बाद इसे जांचें
यदि आप क्लाउड फ़ंक्शंस लॉगर SDK का उपयोग करते हैं, तो आप लाइब्रेरी अपडेट के कारण होने वाले व्यवहार सहित असामान्य व्यवहार की निगरानी कर सकते हैं और सतर्क हो सकते हैं।
क्लाउड फंक्शन सुरक्षा
संवेदनशील जानकारी को क्लाउड फ़ंक्शन के पर्यावरण चर में कभी न रखें
अक्सर स्व-होस्ट किए गए Node.js ऐप में, आप निजी कुंजी जैसी संवेदनशील जानकारी रखने के लिए पर्यावरण चर का उपयोग करते हैं। क्लाउड फ़ंक्शंस में ऐसा न करें । क्योंकि क्लाउड फ़ंक्शंस फ़ंक्शन इनवोकेशन के बीच वातावरण का पुन: उपयोग करता है, संवेदनशील जानकारी को पर्यावरण में संग्रहीत नहीं किया जाना चाहिए।
- Firebase API कुंजियों को संग्रहीत करने के लिए, जो गुप्त नहीं हैं, बस उन्हें कोड में एम्बेड करें।
- यदि आप किसी क्लाउड फ़ंक्शन में Firebase व्यवस्थापक SDK का उपयोग कर रहे हैं, तो आपको सेवा खाता क्रेडेंशियल्स को स्पष्ट रूप से प्रदान करने की आवश्यकता नहीं है, क्योंकि SDK आरंभीकरण के दौरान उन्हें स्वचालित रूप से प्राप्त कर सकता है।
- यदि आप Google और Google क्लाउड API को कॉल कर रहे हैं जिसके लिए सेवा खाता क्रेडेंशियल्स की आवश्यकता होती है, तो Node.js के लिए Google प्रामाणिक लाइब्रेरी इन क्रेडेंशियल्स को एप्लिकेशन डिफ़ॉल्ट क्रेडेंशियल्स से प्राप्त कर सकती है, जो स्वचालित रूप से क्लाउड फ़ंक्शंस में पॉप्युलेट हो जाते हैं।
- अपने क्लाउड फ़ंक्शंस के लिए गैर-Google सेवाओं के लिए निजी कुंजियाँ और क्रेडेंशियल्स उपलब्ध कराने के लिए, क्लाउड सीक्रेट मैनेजर का उपयोग करें।
संवेदनशील जानकारी को एन्क्रिप्ट करें
यदि आप संवेदनशील जानकारी को अपने क्लाउड फंक्शन में भेजने से नहीं बच सकते हैं, तो आपको जानकारी को एन्क्रिप्ट करने के लिए अपने स्वयं के कस्टम समाधान के साथ आना होगा।
सरल कार्य सुरक्षित हैं; यदि आपको जटिलता की आवश्यकता है, तो क्लाउड रन पर विचार करें
अपने क्लाउड फ़ंक्शंस को यथासंभव सरल और समझने योग्य रखने का प्रयास करें। आपके कार्यों में जटिलता अक्सर हार्ड-टू-स्पॉट बग या अप्रत्याशित व्यवहार का कारण बन सकती है।
यदि आपको जटिल तर्क या पर्यावरण विन्यास की आवश्यकता है, तो क्लाउड फ़ंक्शंस के बजाय क्लाउड रन का उपयोग करने पर विचार करें।