क्या Firebase apiKey को जनता के सामने उजागर करना सुरक्षित है?

Question

Firebase वेब-ऐप गाइड में कहा गया है मैं रखना चाहिए दिया apiKeyमेरी एचटीएमएल में Firebase प्रारंभ करने में:

// TODO: Replace with your project's customized code snippet
<script src="https://www.gstatic.com/firebasejs/3.0.2/firebase.js"></script>
<script>
  // Initialize Firebase
  var config = {
    apiKey: '<your-api-key>',
    authDomain: '<your-auth-domain>',
    databaseURL: '<your-database-url>',
    storageBucket: '<your-storage-bucket>'
  };
  firebase.initializeApp(config);
</script>

ऐसा करने से, apiKeyप्रत्येक आगंतुक के सामने आ जाता है। उस कुंजी का उद्देश्य क्या है और क्या यह वास्तव में सार्वजनिक होना है?

Comments

मुझे लगता है कि जब तक आप Firebase Auth और Firebase डेटाबेस नियमों को सेट करते हैं, आप उस जानकारी को सार्वजनिक रूप से दे सकते हैं।

— abbaf33f

उपयोगकर्ता क्रिस्टोफ़ क्विंटार्ड ने फायरबेस एपीआई की सुरक्षा के बारे में अतिरिक्त जानकारी के साथ एक बहुत ही उपयोगी लेख के लिए एक लिंक जोड़ा था, इसलिए मैं इसे यहां रीपोस्ट कर रहा हूं: javebratt.com/hide-firebase-api (टिप्पणी गायब होने जा रही है क्योंकि यह किसी अन्य उपयोगकर्ता से जुड़ी हुई है उत्तर जो खराब गुणवत्ता के कारण हटाने के लिए चिह्नित किया गया है)

— ओलिवर शेफेल्ड

मैं केवल यह बताना चाहता हूं कि सिर्फ इसलिए कि यह विशेष ढांचा एपीआई को उजागर करने के साथ ठीक है, इसका मतलब यह नहीं है कि अन्य ढांचे इसके लिए ठीक हैं। इस पोस्ट से कोई भी इस विचार से दूर नहीं जाना चाहेगा कि "सामान्य रूप से एपीआई कीज़ को उजागर करना ठीक है"।

— युंगगुन

आप कोई समस्या नहीं के साथ चाबियाँ बेनकाब। इसे सुरक्षित बनाने के लिए, आप इसे उत्पादन में विशिष्ट डोमेन के साथ प्रतिबंधित कर सकते हैं ताकि कोई भी किसी भी यादृच्छिक डोमेन नाम से कॉल एपीआई कॉल न कर सके। इसे अधिक सुरक्षित बनाने के लिए प्रोडक्शन ऐप से लोकलहोस्ट को हटा दें।

— बीएल Λ सीके

मुझे नहीं लगता कि आपके रेफरर्स व्हाइटलाइटिस्ट से लोकलहोस्ट को हटाना परीक्षण को कठिन बनाने के अलावा कुछ भी करने वाला है। वह कॉन्फ़िगरेशन IP श्वेतसूची जैसा नहीं है; इसे एक कॉर्स कॉन्फिग की तरह अधिक समझें। फायरबेस जिस तरह से काम करता है वह यह है कि उन एपीआई मार्गों को सीधे ग्राहकों से कहा जाता है, वे अनुमानित नहीं हैं। इसलिए आपके वेबपेज को एपीआई कुंजी की आवश्यकता है। यदि एक बुरा अभिनेता पोस्टमैन से आपके एपीआई मार्गों को कॉल करना चाहता है, तो आपका रेफरल व्हाइटलिस्ट उन्हें रोकने नहीं जा रहा है। यह केवल अन्य सार्वजनिक साइटों को आपके सर्वर को बंद करने से रोकने के लिए उपयोगी है।

— forresthopkinsa

Answer 1

इस कॉन्फ़िगरेशन स्निपेट में एपीकेआई Google सर्वर पर आपके फायरबेस प्रोजेक्ट की पहचान करता है। इसे जानना किसी के लिए सुरक्षा जोखिम नहीं है। वास्तव में, उनके लिए यह जानना आवश्यक है, ताकि वे आपके फायरबेस प्रोजेक्ट के साथ बातचीत कर सकें। यह वही कॉन्फ़िगरेशन डेटा हर iOS और Android ऐप में भी शामिल है जो Firebase को अपने बैकेंड के रूप में उपयोग करता है।

इस संदर्भ में यह बहुत डेटाबेस यूआरएल के समान है कि पहचान करता है पीछे के अंत में एक ही स्निपेट में अपनी परियोजना के साथ जुड़े डेटाबेस: https://<app-id>.firebaseio.com। यह सवाल देखें कि यह सुरक्षा जोखिम क्यों नहीं है: फायरबेस डेटा संशोधन को कैसे प्रतिबंधित किया जाए? सहित, Firebase के सर्वर साइड सुरक्षा नियमों का उपयोग केवल यह सुनिश्चित करने के लिए कि अधिकृत उपयोगकर्ता बैकएंड सेवाओं का उपयोग कर सकते हैं।

यदि आप सीखना चाहते हैं कि आपकी फायरबेस बैकएंड सेवाओं के लिए सभी डेटा एक्सेस को कैसे सुरक्षित किया जाए, तो फायरब्रिगेड सुरक्षा नियमों पर प्रलेखन पर पढ़ें ।

---

यदि आप इस कॉन्फ़िगरेशन डेटा को संस्करण नियंत्रण में करने के जोखिम को कम करना चाहते हैं, तो फायरबेस होस्टिंग के एसडीके ऑटो-कॉन्फ़िगरेशन का उपयोग करने पर विचार करें । जबकि चाबियाँ अभी भी उसी प्रारूप में ब्राउज़र में समाप्त हो जाएंगी, वे अब आपके कोड में हार्ड-कोड नहीं होंगे।

Comments

तो इसका मतलब है कि अन्य लोग मेरे फायरबेस डेटाबेस में सभी डेटा तक पहुंच पाएंगे?

— इमैनुएल कैंपोस

@EmmanuelCampos उत्तर हाँ और नहीं है। यदि आप डेटाबेस में सभी डेटा तक पहुँचने के लिए अन्य लोगों को अनुमति देते हैं या चाहते हैं। और नहीं, अगर आप उन्हें नहीं चाहते हैं। फायरबेस डेटाबेस में नियम, नियम हैं जिन्हें आप नियंत्रित करते हैं

— खोई

मेरे अंतिम प्रश्न support.google.com/firebase/answer/6400741 के लिए मेरा जवाब यहाँ मिला मदद के लिए धन्यवाद। यह लिंक भविष्य में किसी की मदद कर सकता है।

— इमैनुएल कैंपोस

@ m.rufca, आपका डेटा उपयोगकर्ताओं के लिए उपलब्ध होना चाहिए, जो प्रमाणित हैं। और यहाँ चाल है। डिफ़ॉल्ट रूप से, आपकी फायरबेस सेटिंग्स में केवल लोकलहोस्ट और आपके प्रोजेक्ट डोमेन ही उनसे प्रमाणीकरण करने के लिए अधिकृत होते हैं। तो कोई और ऐप नहीं बना सकता है जो सामान्य रूप से आपके फायरबेस के साथ काम करेगा।

— आर्टेम अर्किपोव

क्या होगा अगर बॉट मेरे ऐप पर असीमित उपयोगकर्ता बना रहा है। मुझे कैप्चा की आवश्यकता कैसे हो सकती है।

— मुहम्मद उमेर

Answer 2

यहां प्रूफ्रोफ्रो और फ्रैंक वैन पफलेन के उत्तर पर निर्माण , मैंने इस सेटअप को एक साथ रखा है जो स्क्रैपिंग को रोकता नहीं है, लेकिन आपकी एपीआई कुंजी का उपयोग करने के लिए इसे थोड़ा कठिन बना सकता है।

चेतावनी: अपना डेटा प्राप्त करने के लिए, इस विधि के साथ भी, उदाहरण के लिए, Chrome में जेएस कंसोल को आसानी से खोल सकते हैं और टाइप करें:

firebase.database().ref("/get/all/the/data").once("value", function (data) {
    console.log(data.val());
});

केवल डेटाबेस सुरक्षा नियम आपके डेटा की सुरक्षा कर सकते हैं।

फिर भी, मैंने अपने उत्पादन एपीआई कुंजी का उपयोग इस तरह अपने डोमेन नाम तक सीमित रखा:

1. https://console.developers.google.com/apis
2. अपना फायरबेस प्रोजेक्ट चुनें
3. साख
4. एपीआई कुंजी के तहत, अपनी ब्राउज़र कुंजी चुनें। यह इस तरह दिखना चाहिए: " ब्राउज़र कुंजी (Google सेवा द्वारा बनाया गया ऑटो) "
5. में " इन HTTP सन्दर्भदाता से अनुरोध (वेब साइटों) स्वीकार करें ", अपने ऐप्लिकेशन का URL जोड़ने (उदाहरण के लिए: projectname.firebaseapp.com/*)

अब ऐप केवल इस विशिष्ट डोमेन नाम पर काम करेगा। इसलिए मैंने एक और API कुंजी बनाई जो स्थानीयहोस्ट डेवलपमेंट के लिए निजी होगी।

1. क्रेडेंशियल बनाएँ> एपीआई कुंजी पर क्लिक करें

डिफ़ॉल्ट रूप से, जैसा कि इमैनुएल कैंपोस ने उल्लेख किया है, फायरबेस केवल श्वेतसूची localhostऔर आपके फायरबेस होस्टिंग डोमेन है ।

---

यह सुनिश्चित करने के लिए कि मैं गलती से गलत एपीआई कुंजी प्रकाशित नहीं करता हूं, मैं उत्पादन में अधिक प्रतिबंधित एक का उपयोग करने के लिए निम्न विधियों में से एक का उपयोग करता हूं।

Create-React-App के लिए सेटअप

इन /env.development:

REACT_APP_API_KEY=###dev-key###

इन /env.production:

REACT_APP_API_KEY=###public-key###

में /src/index.js

const firebaseConfig = {
  apiKey: process.env.REACT_APP_API_KEY,
  // ... 
};

---

वेबपैक के लिए मेरा पिछला सेटअप:

मैं अपने प्रोडक्शन ऐप का निर्माण करने के लिए वेबपैक का उपयोग करता हूं और मैं अपनी देव एपीआई कुंजी को अपने अंदर रखता हूं index.html, जैसा कि आप सामान्य रूप से करते हैं। फिर, अपनी webpack.production.config.jsफ़ाइल के अंदर , मैं कुंजी को हर बार index.htmlउत्पादन बिल्ड में कॉपी किया जाता हूं :

plugins: [
    new CopyWebpackPlugin([
      {
        transform: function(content, path) {
          return content.toString().replace("###dev-key###", "###public-key###");
        },
        from: './index.html'
      }
    ])
  ]

Comments

क्या वह आपके लिए ठीक है? एंड्रॉइड ऐप के लिए एक ही काम करने के लिए सोच रहा था। मुझे आश्चर्य है कि क्यों Firebase सुरक्षा अनुभाग में शामिल नहीं है।

— स्टेलियोसेफ

मुझे अब तक कोई समस्या नहीं है, लेकिन शायद कोई हमला भी नहीं हुआ है

— अब

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

— थुलबेकर्स

@thoutbeckers आप सही हैं, धन्यवाद। मैंने उत्तर को संपादित किया, लेकिन विधि को छोड़ दिया क्योंकि यह अभी भी उपयोगी हो सकता है।

— अब 21

@FrankvanPuffelen मैं जो समझता हूं, उससे कोई बड़ा फर्क नहीं पड़ता है, लेकिन यह आपके कोटे का दुरुपयोग करने के लिए थोड़ा अधिक कष्टप्रद बना सकता है, क्योंकि एक अच्छी तरह से व्यवहार किए गए ब्राउज़र में, HTML / JS के साथ दी गई एपीआई कुंजी केवल इच्छित उद्देश्य पर काम करेगी। डोमेन (ओं) और नहीं localhost या कुछ और। लेकिन मैं मानता हूं कि फायरबेस पहले से जो उपलब्ध कराता है, उसकी तुलना में अतिरिक्त सुरक्षा मामूली है। मैं कुछ कम नाटकीय के उत्तर को फिर से लिखूंगा।

— अब

Answer 3

मैं ग्राहक के लिए सुरक्षा / कॉन्फिग कुंजी का खुलासा करने के लिए आश्वस्त नहीं हूं। मैं इसे सुरक्षित नहीं कहूंगा, इसलिए नहीं कि कोई पहले दिन से सभी निजी जानकारी चुरा सकता है, क्योंकि कोई व्यक्ति अत्यधिक अनुरोध कर सकता है, और आपके कोटा को खत्म कर सकता है और आपको Google का बहुत पैसा दे सकता है।

आपको कई अवधारणाओं के बारे में सोचने की ज़रूरत है ताकि लोगों को प्रतिबंधित न किया जा सके, जहां वे नहीं जा सकते हैं, डॉस के हमले आदि।

मैं अधिक पसंद करूंगा कि ग्राहक पहले आपके वेब सर्वर से टकराएगा, वहां आपने पहले हाथ फ़ायरवॉल, कैप्चा, क्लाउडफ़ेयर, ग्राहक और सर्वर के बीच कस्टम सुरक्षा या सर्वर और फ़ायरबेस के बीच क्या रखा है और आप जाने के लिए अच्छे हैं। फायरबेस पहुंचने से पहले कम से कम आप संदिग्ध गतिविधि को रोक सकते हैं। आपके पास और अधिक लचीलापन होगा।

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

Comments

लेकिन क्या यह किसी अन्य REST API को "उजागर" करने के समान नहीं है? मेरा मतलब है कि REST API URL उपयोगकर्ता के लिए उपलब्ध है। वे URL का उपयोग किसी भी अनुरोध को करने के लिए कर सकते हैं जो वे चाहते हैं और आपका कोटा समाप्त कर सकते हैं। आपके बैकएंड के भाग को पहचानने के लिए एपीआई कुंजियों के साथ फायरबस क्या कर रहा है और यह है और इसे उपयोगकर्ता से अनुरोध करने के लिए उपलब्ध होना चाहिए।

— म्बोचेंस्की

@ म्बोचिनस्की लेकिन आप कुछ संसाधनों के लिए सीधे अनुरोध कर सकते हैं जो आपके बिल का भुगतान करते हैं। और फायरबेस साइड में डीडीओएस हमलों आदि को रोकने के लिए इतना अधिक नियंत्रण तंत्र नहीं है। मेरा सुझाव यह होगा कि अपने क्लाइंट को अपने REST API को कॉल करने दें, लेकिन REST API को API कीज़ को निजी रूप से रखना चाहिए, और इससे पहले कि आप Firebase संसाधनों को हिट करें, उन्हें मान्य करें। यदि वे वैध अनुरोध हैं। (क्लाउडफ़ेयर आदि के माध्यम से)। या कैश से परिणाम प्राप्त करते हैं। तब आपको अपने फायरबेस संसाधनों से केवल तभी टकराएगा जब आपको आवश्यकता होगी। यह वही है जो मैं firebase.google.com/docs/admin/setup

— Teoman shipahi

ब्राउज़र पर चाबियाँ उजागर करना एक बुरा विचार है। उन सभी गाइड / लेख लिखने के लिए, वे क्या सोच रहे थे? सुरक्षा के लिए http रेफरर? यह आसानी से खराब हो जाता है

— निक चान अब्दुल्ला

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

— forresthopkinsa

@forresthopkinsa टिप्पणी के ऊपर लिंक है कि क्या दृष्टिकोण लेना है। यह बताने के लिए पर्याप्त नहीं है कि इसमें कोई भी नहीं है।

— तेमन शिपाही

Answer 4

मेरा मानना ​​है कि एक बार डेटाबेस नियम सही लिखे जाने के बाद, यह आपके डेटा की सुरक्षा के लिए पर्याप्त होगा। इसके अलावा, ऐसे दिशानिर्देश हैं जो आपके डेटाबेस को उसी के अनुसार तैयार कर सकते हैं। उदाहरण के लिए, उपयोगकर्ताओं के तहत एक यूआईडी नोड बनाना और इसके तहत सभी जानकारी डालना। उसके बाद, आपको नीचे के रूप में एक सरल डेटाबेस नियम को लागू करना होगा

  "rules": {
    "users": {
      "$uid": {
        ".read": "auth != null && auth.uid == $uid",
        ".write": "auth != null && auth.uid == $uid"
      }
    }
  }
}

कोई अन्य उपयोगकर्ता अन्य उपयोगकर्ताओं के डेटा को पढ़ने में सक्षम नहीं होगा, इसके अलावा, डोमेन नीति अन्य डोमेन से आने वाले अनुरोधों को प्रतिबंधित करेगी। फायरबेस सुरक्षा नियमों पर इसके बारे में अधिक पढ़ सकते हैं

Answer 5

जब उपयोगकर्ता / पासवर्ड साइन अप सक्षम होता है तो एपीआई कुंजी एक्सपोज़र एक भेद्यता बनाता है। एक खुला एपीआई एंडपॉइंट है जो एपीआई कुंजी लेता है और किसी को भी एक नया उपयोगकर्ता खाता बनाने की अनुमति देता है। वे तब इस नए खाते का उपयोग अपने फायरबेस प्रामाणिक संरक्षित ऐप में लॉग इन करने के लिए कर सकते हैं या उपयोगकर्ता / पास और प्रश्नों को चलाने के लिए एसडीके का उपयोग कर सकते हैं।

मैंने Google को इसकी सूचना दी है, लेकिन वे कहते हैं कि यह इच्छानुसार काम कर रहा है।

यदि आप उपयोगकर्ता / पासवर्ड खातों को अक्षम नहीं कर सकते हैं, तो आपको निम्नलिखित कार्य करने चाहिए: नए उपयोगकर्ताओं को अक्षम करने के लिए ऑटो में क्लाउड फ़ंक्शन बनाएं और उनकी पहुंच को प्रबंधित करने के लिए एक नया DB प्रविष्टि बनाएं।

Ex: MyUsers / {userId} / Access: 0

exports.addUser = functions.auth.user().onCreate(onAddUser);
exports.deleteUser = functions.auth.user().onDelete(onDeleteUser);

केवल>> 1 वाले उपयोगकर्ताओं के लिए रीड्स की अनुमति देने के लिए अपने नियमों को अपडेट करें।

बंद मौका पर श्रोता फ़ंक्शन खाते को तेज़ी से अक्षम नहीं करता है, तो पढ़ने के नियम उन्हें किसी भी डेटा को पढ़ने से रोकेंगे।

Answer 6

इसे पढ़ने के बाद और संभावनाओं के बारे में कुछ शोध करने के बाद, मैं अनधिकृत उपयोगकर्ताओं द्वारा डेटा उपयोग को प्रतिबंधित करने के लिए थोड़ा अलग दृष्टिकोण के साथ आया:

मैं अपने उपयोगकर्ताओं को अपने DB में भी सहेजता हूं (और वहां प्रोफ़ाइल डेटा सहेजता हूं)। तो मैं बस इस तरह डीबी नियम सेट:

".read": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()",
".write": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()"

इस तरह से केवल एक पिछले सहेजे गए उपयोगकर्ता DB में नए उपयोगकर्ता जोड़ सकते हैं, इसलिए कोई तरीका नहीं है कि कोई भी खाता DB पर संचालन नहीं कर सकता है। नए उपयोगकर्ताओं को जोड़ना भी तभी संभव होता है जब उपयोगकर्ता की एक विशेष भूमिका हो और केवल व्यवस्थापक या उस उपयोगकर्ता द्वारा ही संपादित किया जाए (ऐसा कुछ):

"userdata": {
  "$userId": {
    ".write": "$userId === auth.uid || root.child('/userdata/'+auth.uid+'/userRole').val() === 'superadmin'",
   ...

Answer 7

आपको इस जानकारी को उजागर नहीं करना चाहिए। सार्वजनिक रूप से, विशेष रूप से एपीआई कुंजी। यह एक गोपनीयता रिसाव हो सकता है।

वेबसाइट को सार्वजनिक करने से पहले आपको इसे छिपाना चाहिए। आप इसे 2 या अधिक तरीकों से कर सकते हैं

1. जटिल कोडिंग / छुपा
2. बस अपनी वेबसाइट या ऐप के निचले भाग में फायरबेस एसडीके कोड डालें और इस प्रकार फायरबेस अपने आप सभी काम करता है। आपको कहीं भी एपीआई कीज़ डालने की आवश्यकता नहीं है

Comments

मैं Firebase से उद्धृत करता हूं, "इन लिपियों को अपने <body> टैग के नीचे कॉपी और पेस्ट करें, लेकिन इससे पहले कि आप किसी भी Firebase सेवाओं का उपयोग करें," जिसमें एपीआई कुंजी शामिल है

— ल्यूक-झांग-04