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

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

आपत्तिजनक ट्रैफ़िक से बचें

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

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

खुद के सिस्टम पर होने वाले 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 एचटीटीपी एपीआई इस्तेमाल करता है) संवेदनशील होते हैं और इन्हें गुप्त रखा जाना चाहिए.

Cloud Messaging के लिए ऑडिट लॉगिंग की सुविधा चालू करना

Cloud Messaging के लिए क्लाउड ऑडिट लॉगिंग चालू करें, ताकि आप अपने एफ़सीएम संसाधनों में एडमिन से जुड़ी गतिविधियों और ऐक्सेस इवेंट को रिकॉर्ड कर सकें.

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

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

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

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

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

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

अगर आपको अपने फ़ंक्शन में संवेदनशील जानकारी देनी ही है, तो आपको जानकारी को एन्क्रिप्ट (सुरक्षित) करने के लिए, अपने हिसाब से कस्टम समाधान तैयार करना होगा.

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

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

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

एनवायरमेंट मैनेजमेंट

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

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

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

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

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

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

लाइब्रेरी की गलत स्पेलिंग या नए मेंटेनर पर नज़र रखें

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

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

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

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

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

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

Cloud Functions लॉगर एसडीके का इस्तेमाल करने पर, आपको असामान्य गतिविधि की निगरानी करने और उसकी सूचना पाने की सुविधा मिलती है. इसमें लाइब्रेरी के अपडेट की वजह से होने वाली असामान्य गतिविधि भी शामिल है.