Firebase की सेवाओं के SDK, नियंत्रण और मूल्य शर्तें अलग हैं। उपयोगकर्ता पहचानना सभी डेटा की अनुमति देना नहीं है। हर सेवा की सुरक्षा और लागत जाँचें।
प्रमाणीकरण और प्राधिकरण
Firebase Authentication लॉगिन संभालता है; अधिकार अलग निर्धारित होते हैं। Cloud Firestore के वेब और मोबाइल क्लाइंट Security Rules इस्तेमाल करते हैं। सर्वर लाइब्रेरी इन्हें बायपास करके IAM इस्तेमाल करती हैं; एक नियंत्रण दोनों रास्ते नहीं ढकता। दस्तावेज़ित वेब MFA के लिए Firebase Authentication with Identity Platform चाहिए।
डेटा और फ़ाइलें
Cloud Firestore और Realtime Database अलग डेटाबेस सेवाएँ हैं; Cloud Storage फ़ाइल जैसे ऑब्जेक्ट रखता है। इनका एक साझा सुरक्षा नियम नहीं है। वर्तमान FAQ के अनुसार मौजूदा बकेट सहित Cloud Storage for Firebase के लिए Blaze चाहिए; बिना शुल्क उपयोग सीमाएँ फिर भी हो सकती हैं। मुफ़्त संरचना का दावा करने से पहले कोटा और बिलिंग जाँचें।
FCM सूचनाएँ
FCM HTTP v1 सर्वर प्राधिकरण इस्तेमाल करता है, जिसमें अल्पकालिक OAuth 2.0 एक्सेस टोकन शामिल हैं। विश्वसनीय वातावरण से भेजें और क्लाइंट में प्रशासनिक क्रेडेंशियल न रखें। डिवाइस पंजीकरण टोकन लक्ष्य पहचानता है; वह उपयोगकर्ता ID token या व्यावसायिक अनुमति नहीं है।
सत्र और संचालन
ID token, refresh token और निरस्तीकरण अलग समझें। क्रिप्टोग्राफ़िक वैधता जारी अधिकारों का प्रमाण नहीं है। उपयोगी लॉग, संग्रह अवधि, लागत अलर्ट और संसाधन नियंत्रण तय करें। Firebase अपने आप GDPR अनुपालन नहीं देता।
स्रोत
- Firebase · Firestore Security Rules
- Firebase · Web multi-factor authentication
- Firebase · Cloud Storage billing requirements
- Firebase · FCM HTTP v1
- Firebase · Manage User Sessions
संपादकीय जाँच: 1 नवंबर 2026।
आइडेंटिटी डिसीजन को रिज़ॉल्वर में ले जाएं।
एक सफल साइन-इन ग्राफ में हर फील्ड को ऑथराइज़ नहीं करता है। हर रिज़ॉल्वर तक पहुंचने वाले आइडेंटिटी कॉन्टेक्स्ट को रिक्वेस्टेड ऑब्जेक्ट और सेंसिटिव डेटा पर चेक को सपोर्ट करना चाहिए।
- एक ही फील्ड को कई रोल और ओनर के तहत टेस्ट करें।
- नेस्टेड फ़ील्ड्स को कंप्यूट करने से पहले ऑब्जेक्ट एक्सेस को मना करें।
- रोल बदलने या सेशन रद्द होने के बाद रिप्ले करें।
प्राथमिक स्रोत: OWASP — GraphQL Cheat Sheet. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
API पृष्ठ विभाजन और संगत निर्यात
बदलता डेटा निर्यात में गायब या दोहराए रिकॉर्ड बना सकता है।
- फ़िल्टर, क्रम और बराबर मानों का क्रम तय करने वाली कुंजी लिखें। जाँचें कि API स्नैपशॉट देता है या बदलते समूह को पढ़ता है। पढ़ते समय नया रिकॉर्ड और हटाना जाँचें; कर्सर होना डेटा स्थिर होने की गारंटी नहीं है।
- AIP-158 में खाली next_page_token अंत बताता है, छोटा या खाली परिणाम पृष्ठ नहीं। काल्पनिक पृष्ठ [A,B] और [B,C] में चार पंक्तियाँ पर तीन अद्वितीय पहचानकर्ता हैं। बिना प्रगति वही कर्सर भी पहचानें और वास्तविक API अनुबंध मानें।
- बैच को स्थायी रूप से सहेजकर ही आगे की स्थिति तय करें। स्थिर पहचानकर्ताओं से बाधित बैच दोहराएँ और हर अनुरोध पर अनुमति जाँचें; कर्सर पहुँच का अधिकार नहीं है। स्नैपशॉट खत्म होने पर फिर शुरू करें या स्पष्ट नीति से मिलान करें; अलग अवस्थाएँ चुपचाप न जोड़ें।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"page_1_ids": [
"A",
"B"
],
"page_2_ids": [
"B",
"C"
],
"next_cursor": "c2",
"empty_page_has_next_cursor": true
}अपेक्षित निर्णय
B दोहराया गया है। पहचान जाँचें और खाली पृष्ठ के बाद भी अगला कर्सर हो तो जारी रखें।
सत्यापन प्रक्रिया
- फ़िल्टर, स्थिर क्रम और पहचान तय करें।
- दोहराव और अगले कर्सर वाला खाली पृष्ठ जाँचें।
- पहचान और असली समाप्ति शर्त रखें। प्राप्त ऑब्जेक्ट और अद्वितीय पहचानकर्ता मिलाएँ; दोहराया कर्सर चिह्नित करें और आगे पृष्ठ वाली खाली प्रतिक्रिया को संग्रह का अंत न मानें।
क्या अपेक्षित पंक्ति संख्या निर्यात की पूर्णता साबित करती है?
नहीं। गायब और दोहरा पहचानकर्ता संख्या में एक-दूसरे को संतुलित कर सकते हैं। पहचानकर्ता, दायरा और कटऑफ तुलना करें और अनसुलझे अंतर लिखें।
प्राथमिक स्रोत: Google AIP-158 — Pagination. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
पासकी: डोमेन और RP ID बदलने की तैयारी
खाते, वेब ओरिजिन और RP ID को अलग रखें ताकि क्रेडेंशियल चुपचाप फिर न बाँधे जाएँ।
- पुराने तथा नए ओरिजिन, RP ID और जुड़े खाते लिखें। वही खाता नाम किसी पासकी को दूसरे RP ID के लिए वैध नहीं बनाता। WebAuthn के अनुमत संयोजन और बदलाव के दौरान उपलब्ध प्रवेश मार्ग जाँचें।
- अधिकृत परीक्षण वातावरण में उपयुक्त लाइब्रेरी से चैलेंज, ओरिजिन, RP ID और खाते का जुड़ाव जाँचें। अप्रत्याशित ओरिजिन और दोहराया चैलेंज आजमाएँ। RP ID बदले तो प्रमाणित नया पंजीकरण तैयार करें; डेटाबेस की पंक्ति कॉपी करना कुंजी का स्थानांतरण नहीं है।
- केवल पुराना क्रेडेंशियल रखने वाला उपयोगकर्ता, बहाली और खुले सत्र जाँचें। जाँची वापसी के साथ मार्ग खोलने और हटाने का क्रम तय करें। नए डोमेन पर पंजीकरण सफल होना सभी पुराने सत्रों का निरस्तीकरण साबित नहीं करता।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: खाता वही है, लेकिन old.example से अलग RP ID वाला new.example होता है। पुराने क्रेडेंशियल को चुपचाप नहीं बाँध सकते; नया पंजीकरण नियोजित प्रमाणित मार्ग से होना चाहिए।
प्राथमिक स्रोत: W3C — Web Authentication Level 2. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
पहचान: कारक, सत्र और पुनर्प्राप्ति
Firebase: छोटा टोकन पूरे सत्र को खत्म नहीं करता
दस्तावेज़ ID token की अवधि एक घंटा बताते हैं; refresh token से नए टोकन मिलते हैं। refresh token निरस्त करना और ID token का निरस्तीकरण पहचानना अलग नियंत्रण हैं।
- निरस्तीकरण संबंधित खाते से जोड़ें।
- SDK का दस्तावेज़ित निरस्तीकरण परीक्षण, जैसे checkRevoked, इस्तेमाल करें।
- हर सुरक्षित बैकएंड पर पुराना टोकन तथा अधिकार जाँचें।
पहचान नियंत्रण विस्तार से देखें →
स्रोत जाँच की तारीख · NIST · Authenticator Event Management NIST · Session Management Firebase · Manage User Sessions