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

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

गलत तरीके से जनरेट किए गए ट्रैफ़िक से बचें

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

गलत तरीके से जनरेट किए गए ट्रैफ़िक का पता लगाने के लिए, जैसे, सेवा में रुकावट (DOS) वाले हमले, के लिए मॉनिटरिंग और सूचनाएं सेट अप करें 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 डेवलप करते समय, गलती से खुद पर DOS हमला करना आसान हो सकता है Cloud Functions. उदाहरण के लिए, ट्रिगर-राइट लूप को हमेशा के लिए बनाना. Firebase Local Emulator SuiteFirebase Local Emulator Suite की मदद से डेवलपमेंट करके, इन गड़बड़ियों को लाइव सेवाओं पर असर डालने से रोका जा सकता है.

अगर गलती से खुद पर DOS हमला हो जाता है, तो अपने फ़ंक्शन को अनडिप्लॉय करें. इसके लिए, उसे मिटाएं 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 HTTP 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 SuiteLocal Emulator Suite की मदद से, सुरक्षा के नियमों की यूनिट टेस्टिंग करें. इसे सीआई में जोड़ें

यह पक्का करने के लिए कि सुरक्षा के नियम, आपके ऐप्लिकेशन के डेवलपमेंट के साथ-साथ अपडेट हो रहे हैं, Firebase 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 एंडपॉइंट के डिफ़ॉल्ट कोटे को सख्त करें. ऐसा Identity Toolkit API पेज Google Cloud console में किया जा सकता है.

ईमेल-पासवर्ड से पुष्टि: ईमेल की गिनती की सुरक्षा की सुविधा चालू करना

अगर Firebase की मैनेज की गई ईमेल-पासवर्ड से पुष्टि करने की सेवा का इस्तेमाल किया जाता है, तो ईमेल की गिनती की सुरक्षा की सुविधा चालू करें. इससे, नुकसान पहुंचाने वाले लोग, खाते के नाम का अनुमान लगाने के लिए, आपके प्रोजेक्ट के पुष्टि करने वाले एंडपॉइंट का गलत इस्तेमाल नहीं कर पाएंगे.

कई चरणों में पुष्टि के लिए, Google Cloud Identity Platform पर अपग्रेड करना

साइन-इन के दौरान ज़्यादा सुरक्षा के लिए, 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 को छोड़कर अन्य सेवाओं की निजी कुंजियां और क्रेडेंशियल उपलब्ध कराने के लिए, Cloud Functionsका इस्तेमाल करें Secret Manager.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cloud Functions के लिए मॉनिटरिंग सेट अप करना. लाइब्रेरी अपडेट के बाद इसकी जांच करना

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