AI से बनी ऐप्स के लिए सुरक्षा चेकलिस्ट: लॉन्च से पहले क्या जाँचें

असली लोगों के आपकी AI से बनी ऐप इस्तेमाल करने से पहले सात चीज़ें जाँचें: हर पेज और API यह जाँचे कि यूज़र कौन है और उसे क्या करने की अनुमति है; secret keys सर्वर पर रहें, browser या चैट में कभी नहीं; सारा input सर्वर पर validate हो; हर यूज़र सिर्फ अपने records तक पहुँच सके; लॉग-इन और महँगे endpoints rate-limited हों; dependencies अपडेट हों; और कुछ गड़बड़ होने पर आप डेटा वापस ला सकें। नीचे की चेकलिस्ट इनमें से हर एक को ऐसे ठोस टेस्ट में बदलती है जिन्हें आप कोड पढ़े बिना चला सकते हैं।

AI app builders फीचर चलाने में अच्छे हैं। वे अपने आप सावधान नहीं होते, क्योंकि "सावधानी" शायद ही कभी prompt में होती है। नीचे की ज़्यादातर समस्याएँ उन चीज़ों से आती हैं जो किसी ने माँगी ही नहीं, इसलिए आम तौर पर हल यह है कि माँगा जाए।

इस चेकलिस्ट का उपयोग कैसे करें

इसे क्रम से पूरा करें, और हर आइटम के लिए दो काम करें: AI से पूछें कि यह सँभाला गया है, और खुद टेस्ट करें। AI अनुमति जाँच लिख सकता है; यह सिर्फ टेस्ट बताता है कि वह काम करती है। आइटम इस तरह चिह्नित हैं:

• Must — ऐप का उपयोग किसी और के करने से पहले यह करें।
• Should — असली यूज़र या असली डेटा आने से पहले यह करें।
• Later — ऐप बढ़ने के साथ इसे करना उचित है।

अगर आपके पास सिर्फ एक घंटा है, तो हर Must करें।

1. Authentication: यह कौन है?

Authentication का मतलब है यह पक्का करना कि कोई कौन है, आम तौर पर लॉग-इन। बुनियादी बातों के लिए authentication क्या है देखें और विकल्पों के लिए अपनी ऐप में लॉग-इन कैसे जोड़ें।

• Must: निजी डेटा दिखाने वाले हर पेज के लिए लॉग-इन ज़रूरी है। टेस्ट: लॉग आउट करें, फिर किसी निजी पेज का URL सीधे browser में चिपकाएँ।
• Must: उन पेजों के पीछे के हर API endpoint के लिए भी लॉग-इन ज़रूरी है, सिर्फ पेज के लिए नहीं। टेस्ट: लॉग आउट करें, browser का network tab खोलें, और लॉग-इन रहते हुए ऐप द्वारा किया गया कोई request दोबारा भेजें।
• Must: पासवर्ड hash करके और धीमे password-hashing algorithm से स्टोर होते हैं, कभी plain text में नहीं। OWASP की पासवर्ड स्टोरेज गाइडेंस पहले Argon2id की सलाह देती है, विकल्प के रूप में scrypt, bcrypt या PBKDF2। पूछें: "पासवर्ड कैसे स्टोर होते हैं?"
• Should: पासवर्ड रीसेट लिंक समय-सीमा के बाद खत्म हों और सिर्फ एक बार काम करें।
• Should: Session cookies पर Secure, HttpOnly और SameSite लगे हों, और लॉग आउट करने पर server पर session खत्म हो।
• Later: दो-चरणीय प्रमाणीकरण (two-factor authentication) दें, या ऐसे provider से sign-in दें जिसमें यह हो।

हर API route और पेज की जाँच करें जो यूज़र का डेटा लौटाता है। हर एक को उन यूज़रों के अनुरोध ठुकराने चाहिए जो लॉग-इन नहीं हैं, server पर, सिर्फ पेज के कोड में नहीं। जिन routes की आपने जाँच की, उनकी सूची बनाएँ।

2. Authorization: उन्हें क्या करने की अनुमति है?

Authorization लॉग-इन के बाद का कदम है: तय करना कि यह खास यूज़र क्या देख और बदल सकता है। AI से बनी ऐप्स में बड़े छेद अक्सर यहीं होते हैं, क्योंकि ऐप सही दिखती है — हर यूज़र का डैशबोर्ड सिर्फ उसका डेटा दिखाता है — जबकि सीधे माँगे जाने पर server किसी का भी डेटा दे देता है।

• Must: हर read, update और delete server पर जाँचे कि record मौजूदा यूज़र (या उसकी टीम) का है।
• Must: टेस्ट करें: दो खाते बनाएँ, A और B। A के रूप में A का एक record खोलें और URL या network request में उसका ID नोट करें। B के रूप में लॉग-इन करें और वही ID माँगें। B को एक error मिलना चाहिए, A का डेटा नहीं।
• Must: Admin पेज और admin API endpoints server पर यूज़र की भूमिका (role) जाँचें। admin link छिपाना सुरक्षा नहीं है।
• Must: यूज़र request बदलकर अपनी role, कीमत, balance या owner fields नहीं बदल सकते। टेस्ट: network tab में देखें कि profile update क्या भेजता है। अगर उसमें role या isAdmin जैसे fields हैं, तो AI से कहें कि उन्हें client से नज़रअंदाज़ करे।
• Should: URL में IDs का अनुमान लगाना मुश्किल हो (1, 2, 3 की जगह random IDs)। यह अनुमति जाँच का विकल्प नहीं है, लेकिन जाँच न होने पर नुकसान सीमित करता है।

हर endpoint के लिए जो कोई record पढ़ता या बदलता है, server पर जाँचें कि लॉग-इन यूज़र उसका मालिक है या उस तक पहुँच की अनुमति है। न हो तो 404 लौटाएँ। फिर मुझे दिखाएँ कि आप दो खातों से इसे कैसे टेस्ट करेंगे।

3. Database में row-level access

"Row-level access" का मतलब है कि टेबल की हर row (एक booking, एक invoice) सिर्फ उन यूज़रों को दिखे जिनकी वह है। इसे लागू करने के दो आम तरीके हैं:

दोनों ठीक से किए जा सकते हैं। ज़रूरी बातें:

• Must: अगर browser सीधे database से बात करता है (कुछ hosted database products यह देते हैं), तो हर टेबल के लिए row-level नियम चालू हों। इनके बिना, public key वाला कोई भी पूरी टेबल पढ़ सकता है।
• Must: Queries मौजूदा यूज़र या टीम से फ़िल्टर हों, उस ID से नहीं जो browser भेजता है।
• Should: साझा डेटा (किसी टीम के projects) का एक साफ नियम हो कि टीम में कौन है, और वह एक ही जगह लागू हो।

4. Secrets और API keys

API key किसी service का पासवर्ड है। Stripe, email और AI providers सभी इन्हें इस्तेमाल करते हैं। पृष्ठभूमि के लिए देखें environment variables और secrets क्या हैं।

• Must: Keys प्रोजेक्ट के environment variables या secrets में रखी जाएँ, कोड में कभी लिखी न जाएँ।
• Must: जो keys पैसे खर्च करा सकती हैं या निजी डेटा पढ़ सकती हैं, वे सिर्फ server पर इस्तेमाल हों। टेस्ट: अपनी live साइट खोलें, devtools में page source और JavaScript फ़ाइलें देखें, और अपनी key की शुरुआत खोजें (जैसे sk_)। वह वहाँ नहीं होनी चाहिए।
• Must: Keys कभी chat, सार्वजनिक repository या screenshot में पेस्ट नहीं हुईं। अगर हुई हैं, तो provider पर उन्हें rotate करें (नई बनाएँ, पुरानी हटाएँ)।
• Should: जहाँ provider देता है, वहाँ restricted या scoped keys इस्तेमाल करें। उदाहरण के लिए Stripe सिर्फ उन्हीं permissions वाली restricted keys की सलाह देता है जिनकी आपकी integration को ज़रूरत है।
• Should: Test और live keys अलग हों, और live ऐप live keys तभी इस्तेमाल करे जब आप तैयार हों।

कुछ keys सार्वजनिक होने के लिए बनी हैं — Stripe की publishable key (pk_…) या आपके domain तक सीमित maps key। नियम उन keys के बारे में है जो शक्ति देती हैं, हर उस string के बारे में नहीं जो key जैसी दिखती है।

5. Input validation

यूज़र जो भी भेजता है — form fields, file uploads, URL parameters — वह कुछ भी हो सकता है, सिर्फ वह नहीं जो आपका form अनुमति देता है।

• Must: Validation server पर होती है, सिर्फ browser में नहीं। Browser की जाँचें सुविधा के लिए हैं; कोई भी उन्हें छोड़ सकता है।
• Must: Database queries parameters इस्तेमाल करती हैं, यूज़र के input से जोड़े गए text से नहीं (यह SQL injection रोकता है)। AI से पुष्टि करवाएँ।
• Must: यूज़र का लिखा text text के रूप में दिखे, HTML के रूप में नहीं चले। टेस्ट: अपने नाम की जगह <b>hello</b> डालें। आपको tags दिखने चाहिए, bold text नहीं।
• Should: File uploads का type और size जाँचा जाए, और अपलोड की गई फ़ाइलें आपके ऐप के मुख्य domain से चलने योग्य पेज के रूप में न दी जाएँ।
• Should: यूज़रों को दिखाए गए errors सादे हों ("कुछ गड़बड़ हो गई"); विस्तृत errors सिर्फ server logs में जाएँ।
• Should: Stripe जैसी सेवाओं के webhooks कार्रवाई करने से पहले provider का signature जाँचें। देखें webhook क्या है।

हर form और API endpoint पर server-side validation जोड़ें: ज़रूरी fields, लंबाई, formats और मान्य values। बाकी सब साफ संदेश के साथ ठुकराएँ। यूज़रों को internal error विवरण न दिखाएँ।

6. Rate limits और दुरुपयोग

Rate limit तय करता है कि कोई एक अवधि में कितने requests कर सकता है। इसके बिना कोई दिन भर पासवर्ड का अनुमान लगा सकता है, आपके signup form में बाढ़ ला सकता है, या paid API पर आपका बिल बढ़ा सकता है।

• Must: लॉग-इन, signup और password reset पर प्रति IP address और प्रति खाता rate limit हो।
• Must: हर कॉल पर जो पैसा लगाता है — AI model requests, SMS, email — उसके लिए प्रति यूज़र सीमा हो और लॉग-इन ज़रूरी हो।
• Should: सार्वजनिक forms (contact, waitlist) पर spam सुरक्षा हो: rate limit, छिपा हुआ honeypot field, या CAPTCHA।
• Should: अपने paid providers पर spending caps या alerts लगाएँ, ताकि कोई bug या हमलावर असीमित बिल न बना सके।

7. Dependencies

ऐप्स open-source packages से बनती हैं, और packages में कभी-कभी ज्ञात कमज़ोरियाँ होती हैं।

• Should: AI से ज्ञात कमज़ोरियों की जाँच करवाएँ (JavaScript projects के लिए npm audit या आपके package manager का समकक्ष) और प्रभावित चीज़ें अपडेट करें।
• Should: वे packages हटाएँ जिनका ऐप अब इस्तेमाल नहीं करता।
• Should: बहुत कम यूज़र वाले packages से सावधान रहें, और ऐसे नामों से जो लोकप्रिय packages की गलत वर्तनी लगें।
• Later: हर महीने या दो महीने में दोबारा जाँचें, या अगर आपका कोड GitHub पर है तो स्वचालित alerts चालू करें।

8. Backups और recovery

सुरक्षा में गलतियों से उबर पाना भी शामिल है — आपकी, AI की, या किसी हमलावर की।

• Must: जानें कि आपका डेटा कहाँ रहता है और उसका backup है या नहीं। मान न लें; अपने host के documentation में जाँचें।
• Should: महत्वपूर्ण डेटा का अपना समय-समय पर export रखें (जैसे CSV export सुविधा या database dump), और उसे कहीं अलग रखें।
• Should: अपना कोड version control में रखें, ताकि कोई भी संस्करण वापस लाया जा सके।
• Should: विनाशकारी कार्रवाइयाँ (खाता हटाना, प्रोजेक्ट हटाना) पुष्टि माँगें, और एक "soft delete" पर विचार करें जो कुछ समय तक पलटा जा सके।
• Later: एक बार सच में restore करके देखें। जो backup आपने कभी restore नहीं किया, वह योजना नहीं, उम्मीद है।

9. लॉन्च से पहले

• Must: लाइव साइट हर जगह HTTPS इस्तेमाल करे।
• Must: development के sample डेटा, test खाते और debug पेज हटा दिए गए हों।
• Should: एक privacy policy बताए कि आप कौन-सा डेटा क्यों इकट्ठा करते हैं — अगर आप व्यक्तिगत डेटा इकट्ठा करते हैं तो कई जगहों पर यह ज़रूरी है। ऐसे प्रमाणपत्र (SOC 2, HIPAA) का दावा न करें जो आपके पास नहीं हैं।
• Should: सुरक्षा समस्याओं पर संपर्क का तरीका हो, और आप हर key को जल्दी rotate करना जानते हों।

सुरक्षा से आगे लॉन्च-पूर्व की व्यापक जाँच के लिए देखें AI prototype को production तक कैसे ले जाएँ।

पेशेवर समीक्षा कब लें

चेकलिस्ट आम गलतियाँ पकड़ती है; वह किसी विशेषज्ञ की जगह नहीं लेती। पेशेवर समीक्षा पर पैसे खर्च करने पर विचार करें अगर आप hosted checkout के बजाय खुद card numbers संभालते हैं, स्वास्थ्य, वित्तीय या बच्चों का डेटा रखते हैं, ऐसी कंपनियों को बेचते हैं जो सुरक्षा प्रश्नावली माँगती हैं, या लीक से गंभीर नुकसान होगा। आपका कोड export होने योग्य हो तो यह समीक्षा कहीं आसान होती है।

Mythex पर बनाते समय सुरक्षा

Mythex में सुरक्षा-स्कैन का कोई panel नहीं है, इसलिए ऊपर की चेकलिस्ट ही पालन करने वाली प्रक्रिया है। कुछ बातें मदद करती हैं:

• प्रोजेक्ट secrets। Keys को project settings → Secrets के अंतर्गत रखें, या agent चैट में जो secrets card दिखाता है उसके ज़रिए, ताकि वे आपके कोड और संदेशों से बाहर रहें। लाइव ऐप के लिए secret बदलने के बाद दोबारा publish करें।
• Plan और Ask modes। Agent से बिना संपादन के अनुमतियों की समीक्षा करवाएँ: "Ask mode में हर API route की सूची बनाओ और वह कौन-सी अनुमति जाँच करता है।"
• /test agent से आपके preview में एक यूज़र की तरह क्लिक करवाता है — सेक्शन 2 के दो-खाते वाले टेस्ट के लिए उपयोगी।
• Checkpoints आपको वह बदलाव वापस लेने देते हैं जिससे कुछ टूटा।

दस्तावेज़ों में देखें अपनी बनाई ऐप की सुरक्षा और Environment variables और secrets। अगला कदम यूज़र खाते जोड़ना है, तो अपनी ऐप में लॉग-इन कैसे जोड़ें पढ़ें।

सवाल