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

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

बुरे बर्ताव वाले ट्रैफ़िक से बचना

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

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

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

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

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

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

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

सीमाएं पार होने पर सूचना पाने की सुविधा सेट अप करें

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

सेल्फ़-डोस रोकें: एम्युलेटर के साथ स्थानीय तौर पर फ़ंक्शन की जांच करें

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

और अगर आपसे गलती से 'DOS' हो जाता है, तो अपने फ़ंक्शन को मिटाकर उसे डिप्लॉय न करें index.js से और फिर चल रहा है firebase deploy --only functions.

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

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

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

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 को सेट अप करने के बाद, अपने सुरक्षा नियम, डिफ़ॉल्ट रूप से सभी ऐक्सेस अस्वीकार करते हैं और ऐक्सेस देने वाले नियम जोड़ते हैं खास संसाधनों को इकट्ठा और इस्तेमाल करने के लिए डिज़ाइन किया गया है.

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

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

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

ईमेल-पासवर्ड की पुष्टि करना: ईमेल इन्यूमरेशन सुरक्षा चालू करें

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

बहु-स्तरीय पुष्टि (MFA) के लिए, Google Cloud Identity Platform पर अपग्रेड करें

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

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

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

• Google से बाहर की सेवाओं के लिए, अपने Cloud Functions, इस्तेमाल करें Secret Manager.

संवेदनशील जानकारी एन्क्रिप्ट करें

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

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

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

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

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

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

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

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

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

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

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

लाइब्रेरी की गलत वर्तनी या रखरखाव करने वाले नए लोगों से सावधान रहना

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

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

अपग्रेड करने से पहले, इस्तेमाल की जाने वाली किसी भी लाइब्रेरी के बदलाव लॉग देखें. पक्का करें कि अपग्रेड से वैल्यू बढ़ जाती है और यह जांच की जा सकती है कि मेंटेनर अब भी एक पक्ष के तौर पर भरोसा.

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

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

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

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