Lovable app सिक्योरिटी चेकलिस्ट: क्या आपका app सुरक्षित है?
Lovable प्लेटफ़ॉर्म, और उस पर बनाया गया आपका app, अलग-अलग सुरक्षित किए जाते हैं। Lovable आम ग़लतियों के लिए स्कैन करता है, लेकिन आपका app उतना ही सुरक्षित है जितने उसके अपने access नियम, keys और सर्वर कोड। जाँचें कि हर exposed table पर row-level security चालू है और तय करती है कि कौन क्या देख सकता है, कि कोई secret key ब्राउज़र तक नहीं पहुँचती, कि payments की पुष्टि सर्वर पर होती है, और कि कोई लाइव app पर नज़र रखता है।
- CVE-2025-48757 की जड़
- Row-level security बंद, या बहुत खुली
- Ship करना सुरक्षित
- Supabase की publishable (anon) key
- कभी ship न करें
- Service role या दूसरी secret keys
- दोबारा जाँचें
- डेटा या access छूने वाले हर बदलाव के बाद
क्या Lovable सुरक्षित है, और क्या इससे मेरा app सुरक्षित हो जाता है?
Lovable कहता है कि वह SOC 2 और GDPR की ज़रूरतों का समर्थन करता है और अपने trust center में अपनी security documentation प्रकाशित करता है। यह Lovable के प्लेटफ़ॉर्म को कवर करता है: उसका infrastructure, उसके access controls, उसका स्टाफ़। यह आपके app के अंदर के नियमों को कवर नहीं करता, क्योंकि उन्हें आपने (Lovable की मदद से) लिखा है।
Lovable का security scan हर publish पर एक तेज़ जाँच चलाता है: database रिव्यू, dependency audit और MCP server check। एक गहरा स्कैन, जिसे हाथ से शुरू किया जाता है (या Lovable Enterprise ग्राहकों के लिए शेड्यूल पर), access control, बिना authentication वाले endpoints, injection, लीक हुए secrets, payments, authentication और खुले निजी डेटा का भी रिव्यू करता है। Lovable की अपनी documentation साफ़ कहती है कि ये टूल पूरी सुरक्षा की गारंटी नहीं दे सकते। स्कैन को जाँच नहीं, smoke alarm मानें।
CVE-2025-48757 क्या था, और क्या इसका मेरे app पर असर है?
मई 2025 में प्रकाशित CVE-2025-48757, 15 अप्रैल 2025 तक Lovable से बनी साइटों में अपर्याप्त row-level security policies का वर्णन करता है, जिनसे बिना authentication वाले हमलावर database tables पढ़ या लिख सकते थे। US National Vulnerability Database इसे 9.3 के critical CVSS 3.1 स्कोर के साथ सूचीबद्ध करता है और नोट करता है कि Lovable इस पर विवाद करता है, इस आधार पर कि हर ग्राहक अपने app के डेटा की सुरक्षा के लिए ख़ुद ज़िम्मेदार है।
इसकी रिपोर्ट करने वाले researcher, Matt Palmer, कहते हैं कि उन्होंने 1,645 प्रोजेक्ट्स स्कैन किए और उनमें से 170 में 303 कमज़ोर endpoints पाए, और कि Lovable ने अप्रैल 2025 में Lovable 2.0 के साथ अपना security scan जारी किया। विवाद पर आपकी राय जो भी हो, व्यावहारिक सबक एक ही है: अगर आपका app उससे पहले बना था, या तब से आपने tables बदली हैं, तो अपनी policies ख़ुद जाँचें। Policy का होना और policy का सही होना एक बात नहीं है।
Lovable सिक्योरिटी चेकलिस्ट में क्या-क्या होना चाहिए?
| जाँच | यह क्यों मायने रखता है | इसे कैसे टेस्ट करें |
|---|---|---|
| किसी exposed schema की हर table पर RLS चालू | इसके बिना, Supabase grant वाले किसी भी role को पूरी table पढ़ने और लिखने देता है | Supabase का Security Advisor चलाएँ; lint 0013 (rls_disabled_in_public) इसे पकड़ता है |
| Policies आपके नियमों से मेल खाती हैं | USING (true) जैसी policy स्कैन पास कर लेती है और फिर भी सबको अंदर आने देती है | यूज़र A के रूप में sign in करें, API से यूज़र B की rows माँगें, कुछ भी वापस न आने की उम्मीद रखें |
| RLS वाली पर बिना policy की tables | वे सब कुछ मना कर देती हैं, जो लीक नहीं, टूटे फ़ीचर के रूप में दिखता है | Advisor lint 0008 (rls_enabled_no_policy); फिर वह policy लिखें जो फ़ीचर को चाहिए |
| ब्राउज़र में कोई secret key नहीं | Service role key हर RLS policy को बाईपास करती है | बने हुए JavaScript में sb_secret_ या पुरानी service_role key खोजें; जो भी key कभी ship हुई हो उसे rotate करें |
| पैसे वाली हर चीज़ पर सर्वर-साइड जाँच | Client कोड को इस्तेमाल करने वाला व्यक्ति बदल सकता है | बदली हुई कीमत या प्लान के साथ सीधे अपने edge function को call करें और इनकार की उम्मीद रखें |
| Sign-up, sign-in और AI calls पर rate limiting | असीमित requests दुरुपयोग या अचानक बड़े बिल में बदल जाती हैं | Staging पर 100 तेज़ requests की script चलाएँ और पक्का करें कि ज़्यादातर मना हो जाएँ |
| Leaked-password protection और admins के लिए MFA | दूसरे breaches से दोहराए गए पासवर्ड घुसपैठ का आम रास्ता हैं | Sign-up पर कोई जाना-माना breached पासवर्ड आज़माएँ |
| एक audit log और error monitoring | जो आपने दर्ज नहीं किया, उसकी जाँच आप नहीं कर सकते | Staging पर कोई admin बदलाव करें और उसे log में ढूँढें |
Lovable app में Supabase RLS errors कैसे ठीक करें?
RLS errors दो उलटे प्रकार के होते हैं, और यह जानना मदद करता है कि आपके पास कौन-सा है।
- Permission denied (Postgres error 42501, या ख़ाली नतीजा)। RLS चालू है और कोई policy request की इजाज़त नहीं देती। यह RLS का सही काम करना है। सबसे संकरी policy लिखें जिससे फ़ीचर चले, जैसे वे rows जहाँ owner column signed-in यूज़र की ID के बराबर हो।
- सब कुछ सबके लिए चलता है। ज़्यादा ख़तरनाक मामला। USING (true) जैसी policy, या छूटा हुआ RLS switch, किसी भी यूज़र को अंदर आने देता है। Supabase का advisor खुली policies (lint 0024, permissive_rls_policy) और RLS बंद होने पर भी मौजूद policies (lint 0007, policy_exists_rls_disabled) पकड़ता है।
- यूज़र metadata पढ़ने वाली policies। Supabase ऐसे metadata पर policies बनाने के ख़िलाफ़ चेतावनी देता है जिसे यूज़र ख़ुद बदल सकता है (lint 0015, rls_references_user_metadata)। इसके बजाय ऐसी table इस्तेमाल करें जिसे आपका सर्वर नियंत्रित करता है, जैसे team membership table।
जब आप Lovable से किसी policy को ठीक करने को कहें, तो बाद में दो-यूज़र वाला टेस्ट फिर चलाएँ। Error हटाने वाला prompt यह काम access बढ़ाकर कर सकता है, जो ठीक वही गड़बड़ी है जिसे आप रोकना चाहते हैं।
Lovable app में कौन-सी keys खुली रखना सुरक्षित है?
Supabase की documentation कहती है कि publishable (anon) key खुली रखना सुरक्षित है, क्योंकि यह सिर्फ़ वहीं तक पहुँचती है जहाँ तक row-level security इजाज़त देती है। Secret key, service role key समेत, हर RLS policy को बाईपास करती है और कभी ब्राउज़र, ship हुए app या source control में नहीं जानी चाहिए। anon key और service role key पर शब्दावली की entry फ़र्क समझाती है। थर्ड-पार्टी secrets, जैसे Stripe या ईमेल provider की keys, app के कोड में नहीं, edge function secrets में रहने चाहिए। देखें secrets management।
एक लाइव Lovable app की दोबारा जाँच कितनी बार होनी चाहिए?
डेटा, access या payments छूने वाले हर बदलाव के बाद, और बाकी सब के लिए एक तय समय पर: dependencies में नई कमज़ोरियाँ आती हैं, keys rotate होनी चाहिए, और नई tables नई policies के साथ आती हैं। इसीलिए सुरक्षा audit से ज़्यादा आदत के रूप में बेहतर काम करती है। हमारे प्लान्स पर, production तक पहुँचने से पहले हर बदलाव पर security checks, code review और regression tests चलते हैं, और लिखने वाले के अलावा कोई दूसरा इंजीनियर उसे मंज़ूर करता है।
अक्सर पूछे जाने वाले सवाल
क्या Lovable असली बिज़नेस app के लिए इस्तेमाल करना सुरक्षित है?
Lovable app बनाने और उसे आकार देने की एक ठीक जगह है, और यह आम security ग़लतियों के लिए स्कैन करता है। तैयार app सुरक्षित है या नहीं, यह उसके अपने access नियमों, keys और सर्वर कोड पर निर्भर करता है, जिन्हें असली यूज़र्स और असली डेटा आने से पहले आपको जाँचना चाहिए। Lovable की documentation कहती है कि उसके स्कैन पूरी सुरक्षा की गारंटी नहीं दे सकते।
क्या मेरे Lovable app में Supabase anon key सुरक्षा की समस्या है?
नहीं। Supabase publishable (anon) key को खुली रखने के लिए सुरक्षित बताता है, क्योंकि यह सिर्फ़ वहीं तक पहुँच सकती है जहाँ तक row-level security इजाज़त देती है। यह समस्या तभी बनती है जब RLS बंद हो या बहुत खुली हो। Service role key अलग है: यह RLS को बाईपास करती है और कभी ब्राउज़र में नहीं होनी चाहिए।
क्या CVE-2025-48757 अब भी Lovable apps पर असर डालता है?
यह CVE 15 अप्रैल 2025 तक Lovable से बनी साइटों को कवर करता है, और Lovable इस पर विवाद करता है। तब से Lovable ने एक security scan जोड़ा है। कोई भी app, पुराना या नया, फिर भी बहुत खुली policy ship कर सकता है, इसलिए तारीख़ पर भरोसा करने के बजाय दो यूज़र अकाउंट्स से अपनी tables टेस्ट करें।
Lovable security review की लागत कितनी है?
एक बार के रिव्यू कई फ़्रीलांसर और फ़र्में तय कीमत पर बेचते हैं। Plutonapps प्लान पर, security checks और code review मासिक कीमत के हिस्से के रूप में हर बदलाव पर चलते हैं, app बनाने, टेस्ट करने, release करने और चलाने के साथ। प्लान और कीमतें हमारे pricing पेज पर हैं।
क्या मैं security checks ख़ुद चला सकता हूँ?
हाँ। Publish करने पर Lovable अपना तेज़ स्कैन चलाता है, Supabase का Security Advisor आपके प्रोजेक्ट dashboard में है, और चेकलिस्ट वाले दो-यूज़र टेस्ट के लिए बस दो टेस्ट अकाउंट्स चाहिए। अकेले जो ज़्यादा मुश्किल है, वह है यह हर बदलाव पर करते रहना, जब तक app लाइव है।
हमारे काम से
इस पेज पर आए शब्द
संबंधित तुलनाएँ और गाइड
- Lovable app production में नहीं चल रहा? इसे production-ready कैसे बनाएँ — Preview में चलने वाले apps असली यूज़र्स के साथ क्यों टूटते हैं, कौन-सी जाँचें उन्हें production-ready बनाती हैं, और उन्हें चालू कौन रखता है।
- Lovable Cloud से अपने Supabase पर कैसे migrate करें — Lovable Cloud या आपका अपना Supabase, export क्या शामिल करता है और क्या छोड़ता है, और production चालू रखने वाली cutover योजना।
- Lovable डेवलपर कैसे hire करें (और उसकी लागत क्या है) — फ़्रीलांसर, Lovable partner एजेंसियाँ और इंजीनियरिंग सब्सक्रिप्शन, लागत, दायरे और बाद में app कौन चलाएगा, इन पर तुलना।
- प्लान और कीमतें
स्रोत
इस पेज का हर बाहरी तथ्य दिए गए स्रोत से इस तारीख़ को जाँचा गया: 30 September 2026। कीमतें और प्लान बदलते रहते हैं; ताज़ा आँकड़ों के लिए लिंक देखें।