GetFree टीम·19 फरवरी, 2026·5 मिनट पढ़ें
The Moltbook Breach: जब Vibe Coding सुरक्षा का बुरा सपना बन जाता है
Moltbook में वास्तव में क्या हुआ?
आइए ठीक से यह तोड़ें कि क्या गलत हुआ, क्योंकि विवरण मायने रखते हैं।
Moltbook को Supabase का उपयोग करके बनाया गया था — एक लोकप्रिय ओपन-सोर्स Firebase विकल्प जो होस्टेड PostgreSQL डेटाबेस प्रदान करता है। Supabase विब-कोडेड एप्लिकेशन के बैकएंड के रूप में विकल्प बन गया है क्योंकि यह प्रमाणीकरण, डेटाबेस और स्टोरेज को न्यूनतम कॉन्फ़िगरेशन के साथ संभालता है।
समस्या क्या है? किसी ने (या किसी AI ने) Supabase API कुंजी को सीधे क्लाइंट-साइड JavaScript कोड में रख दिया। यह एक बुनियादी सुरक्षा गलती है। API कुंजियाँ सर्वर पर होनी चाहिए, कभी भी उस कोड में नहीं जो उपयोगकर्ता के ब्राउज़र में चलता है।
लेकिन यह और बदतर होता है।
उस API की कुंजी के पास पूरे डेटाबेस तक पढ़ने और लिखने की पूर्ण पहुँच थी। और Moltbook ने Row Level Security (RLS) सक्षम नहीं किया था — यह एक Supabase सुविधा है जो नियंत्रित करती है कि कौन किस डेटा तक पहुँच सकता है। RLS सीटबेल्ट के बिना कुछ भी नहीं है। आपको लग सकता है कि आपको इसकी आवश्यकता नहीं है जब तक कि आप दुर्घटना में न शामिल हों।
Wiz के सुरक्षा शोधकर्ताओं ने वेबसाइट देखी ही एक्सपोज्ड की कुंजी को मिनटों में पाया। उनके पास हो सकता था:
- 1.5 मिलियन API कीज़ डाउनलोड किए गए (जिसमें OpenAI, Anthropic, और अन्य AI प्रदाताओं के कीज़ शामिल हैं)
- AI एजेंटों के बीच निजी संदेशों तक पहुंच
- डेटाबेस में संशोधित या हटाया गया कोई भी डेटा
- किसी भी उपयोगकर्ता खाते को हिजैक करना
- चोरी किए गए API कुंजियों का उपयोग करके विशाल बिल चलाएं
मुख्य बात? संस्थापक ने स्वीकार किया कि उसने पूरे प्लेटफॉर्म को "पूरी तरह से वाइब कोड किया"। कोड समीक्षा नहीं। सुरक्षा ऑडिट नहीं। बस AI को प्रॉम्प्ट और परिणाम कॉपी-पेस्ट करना।
यह क्यों लगातार हो रहा है
इस कहानी को लेकर निराश होने की बात यह है: यह अद्वितीय नहीं है।
याद करें जब DeepSeek के API कुंजी एक्सपोज़ हुई थी? या Base44? यह पैटर्न तब दोहराया जाता है क्योंकि vibe coding दर्शन उन प्रथाओं को सक्रिय रूप से प्रोत्साहित करता है जो इन उल्लंघनों को रोकती हैं।
वाइब कोडिंग की मूल दर्शन है: तेज़ी से आगे बढ़ें, परिणामों पर ध्यान केंद्रित करें, विवरणों पर न घबराएँ। यह आकर्षक है क्योंकि — ईमानदारी से कहें तो — यह प्रोटोटाइप बनाने के लिए काम करता है। आप घंटों में एक कार्यात्मक ऐप तैयार कर सकते हैं।
लेकिन प्रोडक्शन एप्लिकेशन एक अलग दुनिया में रहते हैं। वे असली उपयोगकर्ता डेटा, असली भुगतान, असली सुरक्षा खतरों को संभालते हैं। एक ही मानसिकता जो आपको एक सप्ताहांत में प्रोटोटाइप शिप करने में मदद करती है, आपके प्रोडक्शन ऐप को दिन एक पर हैक कर देगी।
मैंने AI-जनित कोड में विशेषज्ञता रखने वाले एक सुरक्षा शोधकर्ता से बात की। यहाँ बताया गया है कि उसे रात को क्या जगाता है:
- यह समझ में नहीं आता कि क्या हो रहा है: जब आप AI से "लॉगिन सिस्टम बनाओ" कहते हैं, तो आपको कोड मिलता है जो लॉगिन सिस्टम जैसा दिखता है लेकिन में छिपे हुए कमजोरियां हो सकती हैं जो केवल विशेषज्ञ द्वारा देखी जा सकती हैं
- AI पर भरोसा करना: उपयोगकर्ता यह मान लेते हैं कि AI-जनित कोड सुरक्षित है क्योंकि... यह AI से है? यह मान्यता पूरी तरह से गलत है
- मौलिक बातें गायब: वाइब कोडर अक्सर सुरक्षा के बारे में यह नहीं जानते कि वे क्या नहीं जानते
अपनी सब्सक्रिप्शन टियर आर्किटेक्चर बनाना
मुझे एक नंबर देता हूँ जो आपको रात भर जगाए रखना चाहिए: 45%।
Veracode के AI-जनित सॉफ्टवेयर सुरक्षा पर शोध के अनुसार, AI-जनित कोड का यह प्रतिशत सुरक्षा जोखिमों युक्त है[1]।
यह खराब AI मॉडल या अक्षम डेवलपर्स के बारे में नहीं है। यह कोड जनरेशन की मूलभूत प्रकृति के बारे में है। AI मॉडल को मौजूदा कोड पर प्रशिक्षित किया गया है—जिसमें असुरक्षित कोड शामिल है। वे उन पैटर्न को दोहराते हैं जो उन्होंने देखे हैं, जिसमें कमजोर वाले भी शामिल हैं।
AI द्वारा उत्पन्न कोड में सामान्य भेद्यताएँ शामिल हैं:
| कमजोरी | इसका मतलब क्या है | वास्तविक दुनिया का प्रभाव |
|---|
| SQL Injection | हमलावर दुर्भावनापूर्ण डेटाबेस कमांड चला सकते हैं | पूर्ण डेटाबेस अधिग्रहण |
|---|---|---|
| XSS (क्रॉस-साइट स्क्रिप्टिंग) | हमलावर दुर्भावनापूर्ण स्क्रिप्ट्स इंजेक्ट कर सकते हैं | सत्र हिजैकिंग, डेटा चोरी |
| हार्डकोडेड सीक्रेट्स | API कुंजियाँ, कोड में पासवर्ड | Account takeovers, bill padding |
| इनपुट सत्यापन लापता | उपयोगकर्ता इनपुट की जाँच नहीं की जाती | इंजेक्शन हमले, क्रैश |
| असुरक्षित प्रमाणीकरण | कमजोर लॉगिन कार्यान्वयन | अनधिकृत पहुँच |
Moltbook ब्रीच वास्तव में दो समस्याएँ थीं: एक हार्डकोडेड API कुंजी (हार्डकोडेड रहस्य) और RLS (असुरक्षित कॉन्फ़िगरेशन) का अभाव। दोनों में से कोई भी अकेले बुरा होता। मिलकर, उन्होंने एक विनाशकारी स्थिति बनाई।
वाइब कोडिंग के बारे में कोई नहीं बताता
मैं आपके साथ ईमानदार हूँ। मैंने कई प्रोजेक्ट्स vibe code किए हैं। यह वास्तव में बनाने का तरीका बदल गया है। लेकिन मैंने कठिन तरीके से कुछ कठिन सबक भी सीखे हैं।
आपको सुरक्षा को समझना अभी भी आवश्यक है
यह असुविधाजनक सच है: यदि आप सुरक्षा को खुद नहीं समझते, तो आप सुरक्षित ऐप्स बनाने के लिए AI टूल्स का उपयोग नहीं कर सकते। AI को आपका खतरा मॉडल नहीं पता है। यह नहीं जानता कि आप क्या संपत्तियों की रक्षा कर रहे हैं। यह बस ऐसा कोड जनरेट करता है जो उचित लगता है।
आपको सुरक्षा विशेषज्ञ बनने की आवश्यकता नहीं है। लेकिन आपको समझना होगा:
- कभी भी क्लाइंट-साइड कोड में रहस्य न डालें
- डेटाबेस पर हमेशा Row Level Security सक्षम करें
- संवेदनशील कॉन्फ़िगरेशन के लिए पर्यावरण चर का उपयोग करें
- उचित इनपुट सत्यापन लागू करें
- जनरेटेड कोड पर सुरक्षा स्कैन चलाएँ
प्रोटोटाइप तेज़ करें, फिर इंजीनियर करें
मेरा वर्तमान वर्कफ़्लो:
- प्रोटोटाइप के लिए Vibe कोड करें — कुछ काम करने वाला प्राप्त करें, असली उपयोगकर्ताओं के साथ विचार को मान्य करें
- उत्पाद-बाज़ार फ़िट पहचानें — कुछ भी निवेश करने से पहले
- उत्पादन के लिए रीफैक्टर करें — यहीं जहाँ आप वास्तव में सुरक्षा, प्रदर्शन और रखरखाव को इंजीनियर करते हैं
गलती है कि रिफैक्टर चरण के बिना उत्पादन में सीधे वाइब-कोडेड प्रोटोटाइप शिप करना। आप समय नहीं बचा रहे हैं — आप तकनीकी ऋण जमा कर रहे हैं जो बाद में आपकी लागत होगा।
काम के लिए सही टूल का उपयोग करें
यह विवादास्पद हो सकता है, लेकिन मुझे नहीं लगता कि वाइब कोडिंग के लिए उपयुक्त है:
- संवेदनशील उपयोगकर्ता डेटा संभालने वाले अनुप्रयोग (स्वास्थ्य सेवा, वित्त)
- प्रणालियाँ जो भुगतान प्रोसेस करती हैं
- नियामक अनुपालन आवश्यकताओं वाली कुछ भी
- ऐप्स जहां सुरक्षा विफलता का असली नुकसान हो सकता है
आंतरिक उपकरणों, MVPs, और प्रोटोटाइप के लिए? जाओ वाइल्ड। वास्तविक उपयोगकर्ता डेटा संभालने वाले प्रोडक्शन सिस्टम के लिए? इसे ठीक से इंजीनियर करें।
अपने आप की सुरक्षा कैसे करें
यदि आप वाइब कोडिंग किसी भी तरह कर रहे हैं (और ईमानदार, आपको करना चाहिए - यह अविश्वसनीय रूप से शक्तिशाली है), तो यहां बताया गया है कि अगले हेडलाइन बनने से कैसे बचें:
अपने Supabase/बैकएंड के लिए
javascript// WRONG - Never do this const supabase = createClient('https://xxx.supabase.co', 'YOUR_ANON_KEY_HERE') // Your service_role key is also exposed here! // CORRECT - Use environment variables, server-side only const supabase = createClient( process.env.SUPABASE_URL, process.env.SUPABASE_ANON_KEY )
आवश्यक सुरक्षा चेकलिस्ट
- [ ] सभी डेटाबेस टेबल पर Row Level Security सक्षम करें
- [ ] API कुंजियों को एनवायरनमेंट वेरिएबल में संग्रहीत करें, कभी भी कोड में नहीं
- [ ] सभी उत्पन्न कोड पर सुरक्षा स्कैन चलाएं (Snyk, CodeQL, या GitHub Advanced Security)
- [ ] कभी भी service_role कीज़ को क्लाइंट के सामने प्रकट न करें
- [ ] सभी उपयोगकर्ता इनपुट पर उचित इनपुट सत्यापन लागू करें
- [ ] दुरुपयोग को रोकने के लिए रेट लिमिटिंग सेट करें
- [ ] किसी भी वास्तविक यूज़र के साथ लॉन्च करने से पहले पेनेट्रेशन टेस्ट प्राप्त करें
सहायक उपकरण
| Tool | यह क्या करता है | मुफ्त टियर |
|---|
| Snyk | कोड के लिए सुरक्षा स्कैनिंग | हाँ |
|---|---|---|
| GitHub Advanced Security | संवेदनशीलता पहचान | Yes (for repos) |
| StackHawk | API सुरक्षा परीक्षण | हाँ |
| Dependabot | Dependency vulnerabilities | हाँ |
इसका उद्योग के लिए क्या मतलब है
मैं honestly चिंतित हूं कि हम कहां जा रहे हैं।
हम सॉफ्टवेयर बनाने के तरीकों में एक विशाल बदलाव के बीच हैं। गैर-तकनीकी संस्थापक अब परिष्कृत अनुप्रयोग बना सकते हैं। प्रवेश की बाधा गिर गई है। यह वास्तव में रोमांचक है।
लेकिन हम एक ऐसी पीढ़ी को भी बना रहे हैं जिसके पास स्टोर में कोई निरीक्षक नहीं है।
यहां मेरा मानना है कि क्या होना चाहिए:
- AI कोडिंग टूल्स को बेहतर सुरक्षा डिफ़ॉल्ट्स की आवश्यकता है — कमज़ोरियों के साथ कोड जनरेट करना बंद करें
- समुदायों को इसके बारे में और बात करने की ज़रूरत है — vibe coding के हर ब्लॉग पोस्ट में सुरक्षा का उल्लेख करना चाहिए
- हमें बेहतर टूलिंग चाहिए — स्वचालित सुरक्षा स्कैनिंग को हर AI कोडिंग वर्कफ़्लो में निर्मित होना चाहिए
- संस्थापकों को जिम्मेदारी लेनी होगी — कुछ गलत होने पर AI को दोष नहीं दे सकते
सॉफ्टवेयर विकास का भविष्य AI गति और सुरक्षा के बीच चुनना नहीं है। दोनों के साथ एक साथ उपयोग करना सीखना है।
अक्सर पूछे जाने वाले प्रश्न
क्या AI टूल्स अपनी सुरक्षा समस्याएं ठीक नहीं कर सकते?
वे सुधार कर सकते हैं और कर रहे हैं। लेकिन AI मॉडल को मौजूदा कोड पर प्रशिक्षित किया गया है—जिसमें असुरक्षित कोड शामिल है। वे मूल रूप से पूरे मानव सॉफ्टवेयर कोर्पस से बुरी आदतें सीख रहे हैं। हम सुरक्षित कोड पर विशेष रूप से प्रशिक्षित मॉडल देखने शुरू कर रहे हैं, लेकिन हम वहां अभी तक नहीं हैं।
क्या AI टूल्स अपनी सुरक्षा समस्याएं ठीक नहीं कर सकते?
Supabase उचित रूप से कॉन्फ़िगर किया गया हो तो ठीक है। समस्या Supabase नहीं थी—यह Moltbook की कॉन्फ़िगरेशन (या उसकी कमी) थी। Supabase में उत्कृष्ट सुरक्षा सुविधाएँ हैं (जैसे Row Level Security)। समस्या यह थी कि वाइब कोडिंग ने उन सुविधाओं को छोड़ने का कारण बना।
क्या Supsecure नहीं है?
बिल्कुल नहीं। यह बिल्ड और इटरेट करने का एक अविश्वसनीय रूप से शक्तिशाली तरीका है। बस समझें कि "इसे वाइब कोड किया गया था" सुरक्षा विफलताओं के लिए बहाना नहीं है। तेज़ी से प्रोटोटाइप बनाएँ, अपने विचार को मान्य करें, फिर प्रोडक्शन के लिए इंजीनियर करें।
क्या मुझे वाइब कोडिंग बंद करनी चाहिए?
सुरक्षा-केंद्रित प्रथाओं के साथ पारंपरिक विकास। या: AI-जनित कोड को स्वयं समीक्षा करने के लिए पर्याप्त समझना सीखें। या: लॉन्च से पहले सुरक्षा ऑडिट के लिए किसी को काम पर रखें। या: मजबूत सुरक्षा डिफ़ॉल्ट्स के साथ बने टूल्स और फ्रेमवर्क का उपयोग करें।
वाइब कोडिंग का विकल्प क्या है?
निष्कर्ष
Moltbook कोई विशिष्ट मामला नहीं है। यह आने वाले कुछ की एक पूर्वावलोकन है।
जैसे ही फाउंडर्स सुरक्षा मूलभूत सिद्धांतों को समझे बिना वाइब-कोडेड अनुप्रयोग भेजते हैं, हमें और अधिक ब्रीच देखने को मिलेंगे। अधिक लीक हुई API कुंजियाँ। अधिक उजागर हुए डेटाबेस। अधिक पीड़ित।
यह vibe coding के खिलाफ एक तर्क नहीं है। इसकी सीमाओं के बारे में ईमानदार होने का तर्क है।
तेज़ी से शिप करें। विचारों की कोशिश करें। जल्दी बढ़ें। लेकिन असली उपयोगकर्ता डेटा को जोखिम में डालने से पहले, धीमा हो जाएं और सुरक्षा का काम करें। आपके उपयोगकर्ता आपकी जानकारी के साथ भरोसा कर रहे हैं। उस भरोसे को vibe-coded नहीं होना चाहिए।
संबंधित पोस्ट
- विब कोडिंग क्या है? 2026 की पूरी गाइड
- Cursor बनाम Windsurf for Vibe Coding: 2026 में कौन जीतता है?
- 7 दिनों में AI ऐप कैसे बनाएं (चरण दर चरण)
- 100 बीटा उपयोगकर्ता कैसे जल्दी पाएँ
सुरक्षित रूप से अपना ऐप लॉन्च करने के लिए तैयार? अपने ऐप को GetFree पर सूचीबद्ध करें — एक क्यूरेटेड निर्देशिका जहां डेवलपर्स हजारों लक्षित परीक्षकों के साथ प्रोमो कोड और बीटा एक्सेस साझा करते हैं।
स्रोत
मूल रूप से GetFree.APP ब्लॉग पर प्रकाशित — अंतिम अपडेट: 17 फरवरी, 2026
अद्भुत ऐप खोजने के लिए तैयार?
GetFree.APP के साथ सर्वश्रेष्ठ मुफ्त iOS ऐप्स खोजें और साझा करें