Firebase की सुरक्षा के लिए चेकलिस्ट

bookmark_border संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

अपने Firebase संसाधनों और उपयोगकर्ताओं के डेटा को सुरक्षित रखने के लिए, इन दिशा-निर्देशों का पालन करें. ऐसा ज़रूरी नहीं है कि हर आइटम आपकी ज़रूरतों पर लागू हो. हालांकि, ऐप्लिकेशन बनाते समय इन बातों को ध्यान में रखें.

गलत इस्तेमाल से जुड़े ट्रैफ़िक से बचना

बैकएंड सेवाओं के लिए, मॉनिटरिंग और सूचना देने की सुविधा सेट अप करना

गलत इस्तेमाल वाले ट्रैफ़िक का पता लगाने के लिए, Cloud Firestore, Realtime Database, Cloud Storage, और Hosting के लिए, मॉनिटरिंग और सूचना देने की सुविधा सेट अप करें. जैसे, सेवा में रुकावट (डीओएस) वाले हमले

अगर आपको लगता है कि आपके ऐप्लिकेशन पर हमला हुआ है, तो जल्द से जल्द सहायता टीम से संपर्क करें और उन्हें बताएं कि क्या हो रहा है.

App Check चालू करें

यह पक्का करने के लिए कि सिर्फ़ आपके ऐप्लिकेशन आपकी बैकएंड सेवाओं को ऐक्सेस कर सकें, उन सभी सेवाओं के लिए Firebase App Check को चालू करें जिन पर यह सुविधा काम करती है.

सामान्य ट्रैफ़िक के लिए स्केल करने के लिए, अपने Cloud Functions को कॉन्फ़िगर करना

Cloud Functions आपके ऐप्लिकेशन की ज़रूरतों के हिसाब से अपने-आप स्केल होता है. हालांकि, हमले की स्थिति में, इसका मतलब ज़्यादा खर्च हो सकता है. इसे रोकने के लिए, अपने ऐप्लिकेशन के सामान्य ट्रैफ़िक के आधार पर, किसी फ़ंक्शन के एक साथ चलने वाले इंस्टेंस की संख्या को सीमित किया जा सकता है.

सीमाएं पूरी होने पर सूचना पाने के लिए, सूचनाएं सेट अप करना

अगर आपकी सेवा के लिए अनुरोधों की संख्या में अचानक बढ़ोतरी होती है, तो अक्सर कोटा लागू हो जाएगा और आपके ऐप्लिकेशन पर आने वाले ट्रैफ़िक को अपने-आप कम कर दिया जाएगा. अपने इस्तेमाल और बिलिंग डैशबोर्ड पर नज़र रखना न भूलें. इसके अलावा, अपने प्रोजेक्ट पर बजट से जुड़ी सूचनाएं सेट भी की जा सकती हैं, ताकि संसाधन के इस्तेमाल की उम्मीद से ज़्यादा होने पर आपको सूचना मिल सके.

डिवाइस को खुद डीओएस होने से रोकना: एमुलेटर की मदद से, फ़ंक्शन को स्थानीय तौर पर टेस्ट करना

Cloud Functions को डेवलप करते समय, अनजाने में खुद को डीओएस किया जा सकता है: उदाहरण के लिए, अनलिमिटेड ट्रिगर-लिखने वाला लूप बनाकर. Firebase Local Emulator Suite का इस्तेमाल करके डेवलपमेंट करने पर, इन गलतियों से लाइव सेवाओं पर असर नहीं पड़ता.

अगर आपने गलती से खुद को डीओएस कर लिया है, तो index.js से फ़ंक्शन को मिटाकर उसे फिर से डिप्लॉय करें. इसके बाद, firebase deploy --only functions को चलाएं.

जहां रीयल-टाइम में जवाब देना कम ज़रूरी होता है, वहां स्ट्रक्चर को सुरक्षा के लिहाज़ से बनाया जाता है

अगर आपको किसी फ़ंक्शन का नतीजा रीयल टाइम में दिखाने की ज़रूरत नहीं है, तो नतीजों को एक साथ प्रोसेस करके, गलत इस्तेमाल से जुड़े ट्रैफ़िक को कम किया जा सकता है: नतीजों को Pub/Sub विषय पर पब्लिश करें और शेड्यूल किए गए फ़ंक्शन की मदद से, नतीजों को नियमित अंतराल पर प्रोसेस करें.

एपीआई कुंजियों के बारे में जानकारी

Firebase की सेवाओं के लिए एपीआई पासकोड, गुप्त नहीं होते

Firebase, एपीआई पासकोड का इस्तेमाल सिर्फ़ Firebase की सेवाओं के लिए, आपके ऐप्लिकेशन के Firebase प्रोजेक्ट की पहचान करने के लिए करता है. इसका इस्तेमाल डेटाबेस या Cloud Storage डेटा के ऐक्सेस को कंट्रोल करने के लिए नहीं किया जाता. डेटा के ऐक्सेस को कंट्रोल करने के लिए, Firebase Security Rules का इस्तेमाल किया जाता है. इस वजह से, आपको Firebase की सेवाओं के लिए एपीआई पासकोड को गुप्त पासवर्ड के तौर पर ट्रीट करने की ज़रूरत नहीं है. साथ ही, उन्हें क्लाइंट कोड में सुरक्षित तरीके से एम्बेड किया जा सकता है. Firebase के लिए एपीआई कुंजियों के बारे में ज़्यादा जानें.

एपीआई कुंजी से जुड़ी पाबंदियां सेट अप करना

अगर कोई हमलावर आपके एपीआई पासकोड का इस्तेमाल करके, अनुरोधों को स्पूफ करने की कोशिश करता है, तो उसे रोकने के लिए एपीआई पासकोड पर पाबंदियां लगाई जा सकती हैं. इससे, एपीआई पासकोड का इस्तेमाल सिर्फ़ आपके ऐप्लिकेशन क्लाइंट और इस्तेमाल किए जा रहे एपीआई के लिए किया जा सकेगा.

FCM सर्वर कुंजियों को गुप्त रखना

Firebase की सेवाओं के लिए एपीआई पासकोड के उलट, FCM सर्वर पासकोड (जिसका इस्तेमाल लेगसी FCM एचटीटीपी एपीआई करता है) संवेदनशील होते हैं और उन्हें गुप्त रखना ज़रूरी होता है.

सेवा खाते की कुंजियों को गुप्त रखना

साथ ही, 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 की मदद से, यूनिट टेस्ट के लिए सुरक्षा नियम तय करना; इसे सीआई में जोड़ना

यह पक्का करने के लिए कि आपके सुरक्षा नियम, आपके ऐप्लिकेशन के डेवलपमेंट के साथ अप-टू-डेट हैं, Firebase Local Emulator Suite के साथ अपने नियमों की यूनिट टेस्ट करें और इन टेस्ट को अपनी सीआई पाइपलाइन में जोड़ें. Cloud Firestore और Realtime Database के लिए ये गाइड देखें.

पुष्टि करना

कस्टम पुष्टि: भरोसेमंद (सर्वर-साइड) इनवायरनमेंट से JWT जारी करना

अगर आपके पास पहले से ही कोई सुरक्षित साइन-इन सिस्टम है, चाहे वह कस्टम सिस्टम हो या तीसरे पक्ष की सेवा, तो Firebase की सेवाओं की पुष्टि करने के लिए, अपने मौजूदा सिस्टम का इस्तेमाल किया जा सकता है. भरोसेमंद प्लैटफ़ॉर्म से कस्टम JWT बनाएं. इसके बाद, अपने क्लाइंट को टोकन पास करें. क्लाइंट, पुष्टि करने के लिए टोकन का इस्तेमाल करता है (iOS+, Android, वेब, Unity, C++).

तीसरे पक्ष के किसी प्रोवाइडर के साथ कस्टम पुष्टि करने की सुविधा का इस्तेमाल करने का उदाहरण देखने के लिए, Okta का इस्तेमाल करके Firebase से पुष्टि करना ब्लॉग पोस्ट देखें.

मैनेज की गई पुष्टि: OAuth 2.0 प्रोवाइडर सबसे सुरक्षित हैं

अगर Firebase की मैनेज की गई पुष्टि करने की सुविधाओं का इस्तेमाल किया जाता है, तो OAuth 2.0 / OpenID Connect की सेवा देने वाली कंपनियों के विकल्प (Google, Facebook वगैरह) सबसे सुरक्षित होते हैं. अगर हो सके, तो आपको इनमें से एक या एक से ज़्यादा सेवा देने वाली कंपनियों के साथ काम करना चाहिए.

ईमेल-पासवर्ड की मदद से पुष्टि करना: ब्रूट-फ़ोर्स अटैक से बचने के लिए, साइन-इन एंडपॉइंट के लिए कम कोटा सेट करें

अगर Firebase की मैनेज की गई ईमेल-पासवर्ड की पुष्टि करने वाली सेवा का इस्तेमाल किया जा रहा है, तो ब्रूट-फ़ोर्स अटैक को रोकने के लिए, identitytoolkit.googleapis.com एंडपॉइंट के डिफ़ॉल्ट कोटे को ज़्यादा सख्त करें. ऐसा करने के लिए, Google Cloud कंसोल में Identity Toolkit API पेज पर जाएं.

ईमेल और पासवर्ड की मदद से पुष्टि करना: ईमेल की जानकारी को सुरक्षित रखने की सुविधा चालू करना

अगर 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 एपीआई पासकोड (जो गुप्त नहीं हैं) को सेव करने के लिए, उन्हें कोड में एम्बेड करें.

• अगर Cloud Functions में Firebase Admin SDK का इस्तेमाल किया जा रहा है, तो आपको सेवा खाते के क्रेडेंशियल साफ़ तौर पर देने की ज़रूरत नहीं है. ऐसा इसलिए, क्योंकि Admin SDK, शुरू करने के दौरान उन्हें अपने-आप हासिल कर सकता है.

• अगर आपको Google और Google Cloud के ऐसे एपीआई को कॉल करना है जिनके लिए सेवा खाते के क्रेडेंशियल की ज़रूरत होती है, तो Node.js के लिए Google Auth लाइब्रेरी, ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल से ये क्रेडेंशियल पा सकती है. ये क्रेडेंशियल, Cloud Functions में अपने-आप भर जाते हैं.

• Google से बाहर की सेवाओं के लिए निजी पासकोड और क्रेडेंशियल को अपने Cloud Functions के लिए उपलब्ध कराने के लिए, Secret Manager का इस्तेमाल करें.

संवेदनशील जानकारी को एन्क्रिप्ट (सुरक्षित) करना

अगर आपको अपने फ़ंक्शन में संवेदनशील जानकारी भेजनी है, तो आपको जानकारी को एन्क्रिप्ट करने के लिए, अपने हिसाब से कोई समाधान ढूंढना होगा.

आसान फ़ंक्शन ज़्यादा सुरक्षित होते हैं. अगर आपको जटिल फ़ंक्शन चाहिए, तो Cloud Run का इस्तेमाल करें

अपने फ़ंक्शन को ज़्यादा से ज़्यादा आसान और समझने लायक बनाएं. फ़ंक्शन में जटिलता होने पर, अक्सर गड़बड़ियां दिखना मुश्किल हो जाती हैं या फ़ंक्शन अनचाहे तरीके से काम करने लगता है.

अगर आपको जटिल लॉजिक या एनवायरमेंट कॉन्फ़िगरेशन की ज़रूरत है, तो Cloud Functions के बजाय Cloud Run का इस्तेमाल करें.

पर्यावरण मैनेजमेंट

डेवलपमेंट और स्टैजिंग प्रोजेक्ट सेट अप करना

डेवलपमेंट, स्टेजिंग, और प्रोडक्शन के लिए अलग-अलग Firebase प्रोजेक्ट सेट अप करें. क्लाइंट कोड को प्रोडक्शन में तब तक मर्ज न करें, जब तक उसकी जांच स्टैजिंग प्रोजेक्ट के साथ न की गई हो.

टीम को प्रोडक्शन डेटा का सीमित ऐक्सेस देना

अगर बड़ी टीम के साथ काम किया जा रहा है, तो पहले से तय की गई IAM भूमिकाओं या पसंद के मुताबिक बनाई गई IAM भूमिकाओं का इस्तेमाल करके, प्रोडक्शन डेटा के ऐक्सेस को सीमित किया जा सकता है. इससे, गड़बड़ियों और उल्लंघनों के असर को कम किया जा सकता है.

अगर आपकी टीम डेवलपमेंट के लिए Firebase Local Emulator Suite (सुझाया गया) का इस्तेमाल करती है, तो हो सकता है कि आपको प्रोडक्शन प्रोजेक्ट का ज़्यादा ऐक्सेस देने की ज़रूरत न पड़े.

लाइब्रेरी मैनेजमेंट

लाइब्रेरी में गलत स्पेलिंग या नए मैनेजर के बारे में सावधान रहें

अपने प्रोजेक्ट में लाइब्रेरी जोड़ते समय, लाइब्रेरी के नाम और उसे मैनेज करने वाले लोगों पर ध्यान दें. जिस लाइब्रेरी को इंस्टॉल करना है उससे मिलते-जुलते नाम वाली लाइब्रेरी में नुकसान पहुंचाने वाला कोड हो सकता है.

बदलावों को समझे बिना लाइब्रेरी अपडेट न करें

अपग्रेड करने से पहले, इस्तेमाल की जा रही लाइब्रेरी के बदलाव लॉग देखें. पक्का करें कि अपग्रेड से कोई फ़ायदा हो. साथ ही, यह भी देखें कि उसे मैनेज करने वाला व्यक्ति अब भी भरोसेमंद है या नहीं.

डेवलपर या टेस्ट डिपेंडेंसी के तौर पर वॉचडॉग लाइब्रेरी इंस्टॉल करना

अपने प्रोजेक्ट को असुरक्षित डिपेंडेंसी के लिए स्कैन करने के लिए, Snyk जैसी लाइब्रेरी का इस्तेमाल करें.

Cloud Functions के लिए मॉनिटरिंग सेट अप करें; लाइब्रेरी के अपडेट होने के बाद इसे देखें

अगर Cloud Functions लॉगर SDK टूल का इस्तेमाल किया जाता है, तो लाइब्रेरी के अपडेट से जुड़े व्यवहार के साथ-साथ, ऐप्लिकेशन के असामान्य व्यवहार को निगरानी में रखा जा सकता है और इसकी सूचना भी मिल सकती है.