900 साइटें, 125M खाते, 1 भेद्यता

मूल लेख ↗ Hacker News चर्चा ↗

Firebase का सुरक्षा मॉडल और उसकी कमियाँ

  • कई लोगों को Firebase के security rules अवधारणात्मक रूप से सही लगते हैं, लेकिन व्यावहारिक रूप से इन्हें सही तरीके से इस्तेमाल करना कठिन है, खासकर Realtime Database के लिए।
  • Rules “set and forget” होते हैं: business logic बदलने पर नए fields/collections अक्सर जरूरत से ज़्यादा permissive rules inherit कर लेते हैं।
  • सुरक्षा समस्याएँ इन कारणों से पैदा होती हैं:
    • पारंपरिक backends की तुलना में नया rule-based model।
    • जब बहुत सारे apps एक ही platform इस्तेमाल करते हैं, तो mass scanning आसान हो जाती है।
    • insecure defaults / “allow by default” patterns और developers का काम चलाने के लिए read/write true का उपयोग करना।
  • UX पर आलोचना: Firebase का ज़्यादातर हिस्सा polished UI है, लेकिन rules एक साधारण config file हैं, जिसे कई नए developer ठीक से छूना ही नहीं चाहते।

Google Support और संगठनात्मक समस्याएँ

  • कई टिप्पणियों में Firebase/Google support को अनुत्तरदायी और भारी मात्रा में outsourced बताया गया है।
  • ऐसा महसूस होता है कि Google developer products के लिए human-centric, high-skill support में पर्याप्त निवेश नहीं करता।
  • कुछ लोगों का तर्क है कि यह “bot-first, human-last” संस्कृति लंबे समय में Google को नुकसान पहुँचा सकती है; दूसरों के अनुसार regulation या साधारण inertia ज़्यादा महत्वपूर्ण हैं।

Architecture: Frontend से सीधे DB Access

  • बहुत से लोग frontend के सीधे database में लिखने को लेकर असहज हैं, भले ही rules हों:
    • validation, content checks, और बदलती privacy requirements सुनिश्चित करना कठिन हो जाता है।
    • एक centralized backend की तुलना में “भूल जाने” वाला surface area बड़ा होता है।
  • Defenders का कहना है कि यह simple “user-only data” apps (जैसे notes/sync) के लिए काम करता है, और mature projects अक्सर writes को Cloud Functions या traditional servers पर ले जाते हैं, जबकि reads client-side रखते हैं।

Mitigations और Best Practices

  • सुझाए गए उपायों में शामिल हैं:
    • template-based “simple security modes” और अनिवार्य rule tests।
    • हर collection को एक स्पष्ट security profile देना (public, per-user, admin-only) और sensitivities को कभी न मिलाना।
    • default-deny transpilers जो नए fields के लिए explicit rules लागू करने को मजबूर करें।
    • implicit schema changes के लिए बेहतर audit logs और notifications।
    • RLS-like mechanisms (जैसे Postgres/Supabase में) ताकि auth को familiar language में express किया जा सके।

Impact, Ethics, और User Security

  • कई vulnerable sites disclosure प्रयासों के बावजूद unfixed रहते हैं; emails अक्सर अनदेखी कर दी जाती हैं, और dashboards शायद ही कभी check किए जाते हैं।
  • प्रभावित sites की सूची प्रकाशित करने पर बहस है: इससे users की मदद हो सकती है, लेकिन attackers को भी फायदा मिल सकता है।
  • व्यापक चिंता यह है कि low-bar cloud tools कम security competence वाली संस्थाओं को बड़ी मात्रा में PII इकट्ठा करने देते हैं।
  • Users को सलाह दी जाती है कि password managers और unique/aliased emails का उपयोग करें ताकि inevitable breaches से होने वाले नुकसान को सीमित किया जा सके.