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

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

अपमानजनक ट्रैफ़िक से बचना

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

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

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

App Check को चालू करें

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

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

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

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

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

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

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

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

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

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

एपीआई पासकोड के बारे में जानकारी

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

Firebase सेवाओं के लिए एपीआई कुंजियां, सिर्फ़ उन सेवाओं के लिए आपके Firebase प्रोजेक्ट और ऐप्लिकेशन की पहचान करती हैं. अनुमति को Google Cloud IAM अनुमतियों, Firebase Security Rules, और Firebase App Check के ज़रिए मैनेज किया जाता है.

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

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

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

Firebase से मिले एपीआई कुंजियों का इस्तेमाल सिर्फ़ Firebase से जुड़े एपीआई के लिए करें. अगर आपका ऐप्लिकेशन किसी अन्य एपीआई का इस्तेमाल करता है (उदाहरण के लिए, Maps के लिए Places API या Gemini Developer API), तो अलग एपीआई कुंजी का इस्तेमाल करें और उसे लागू होने वाले एपीआई तक सीमित रखें.

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, Web, Unity, C++).

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

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

अगर Firebase की मैनेज की गई पुष्टि करने की सुविधाओं का इस्तेमाल किया जाता है, तो OAuth 2.0 / OpenID Connect provider के विकल्प (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 API पासकोड (जो गुप्त नहीं होते) सेव करने के लिए, उन्हें कोड में एम्बेड करें.

• अगर Firebase Admin SDK का इस्तेमाल Cloud Functions में किया जा रहा है, तो आपको सेवा खाते के क्रेडेंशियल देने की ज़रूरत नहीं है. ऐसा इसलिए, क्योंकि 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 (सुझाया गया) का इस्तेमाल करती है, तो आपको प्रोडक्शन प्रोजेक्ट को ज़्यादा ऐक्सेस देने की ज़रूरत नहीं पड़ सकती.

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

लाइब्रेरी के नाम में हुई गलतियों या नए रखरखाव करने वालों पर नज़र रखें

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

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

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

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

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

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

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