AI ने बनवलेल्या अ‍ॅप्ससाठी सुरक्षा चेकलिस्ट: लाँचपूर्वी काय तपासायचे

खऱ्या लोकांनी तुम्ही AI सह बनवलेले अ‍ॅप वापरण्यापूर्वी सात गोष्टी तपासा: प्रत्येक पान आणि API वापरकर्ता कोण आहे आणि त्याला काय करण्याची परवानगी आहे हे तपासते; गुप्त की सर्व्हरवर राहतात, ब्राउझर किंवा चॅटमध्ये नाही; सर्व इनपुट सर्व्हरवर पडताळले जाते; प्रत्येक वापरकर्ता फक्त स्वतःच्या नोंदींपर्यंत पोहोचू शकतो; लॉग-इन आणि महागड्या एंडपॉइंट्सवर रेट लिमिट आहे; डिपेंडन्सी अद्ययावत आहेत; आणि काही चुकल्यास तुम्ही डेटा पुनर्संचयित करू शकता. खालील चेकलिस्ट या प्रत्येक गोष्टीला कोड न वाचता चालवता येईल अशा ठोस चाचण्यांमध्ये रूपांतरित करते.

AI अ‍ॅप बिल्डर्स फीचर्स चालवण्यात चांगले आहेत. ते आपोआप काळजीपूर्वक नसतात, कारण "काळजीपूर्वक" हे प्रॉम्प्टमध्ये क्वचितच असते. खाली दिलेल्या बहुतेक समस्या अशा गोष्टींमधून येतात ज्या कोणी मागितल्या नव्हत्या, त्यामुळे उपाय सहसा विचारणे हाच असतो.

ही चेकलिस्ट कशी वापरायची

ती क्रमाने पूर्ण करा, आणि प्रत्येक मुद्द्यासाठी दोन गोष्टी करा: ते हाताळले गेले आहे याची खात्री करण्यासाठी AI ला विचारा, आणि स्वतः चाचणी करा. परवानगी तपासणी AI लिहू शकतो; ती काम करते की नाही हे फक्त चाचणीच सांगते. मुद्दे अशा प्रकारे चिन्हांकित केले आहेत:

• अत्यावश्यक — अन्य कोणी अ‍ॅप वापरण्यापूर्वी हे करा.
• शिफारस — तुमच्याकडे खरे वापरकर्ते किंवा खरा डेटा येण्यापूर्वी हे करा.
• नंतर — अ‍ॅप वाढत असताना करण्यासारखे.

तुमच्याकडे फक्त एक तास असेल, तर सर्व अत्यावश्यक मुद्दे करा.

1. ऑथेंटिकेशन: हा कोण आहे?

ऑथेंटिकेशन म्हणजे एखादी व्यक्ती कोण आहे याची खात्री करणे — सहसा लॉग-इन. मूलभूत माहितीसाठी ऑथेंटिकेशन म्हणजे काय आणि पर्यायांसाठी तुमच्या अ‍ॅपमध्ये लॉग-इन कसे जोडायचे पहा.

• अत्यावश्यक: खाजगी डेटा दाखवणाऱ्या प्रत्येक पानासाठी लॉग-इन आवश्यक आहे. चाचणी: लॉग आउट करा, मग खाजगी पानाचा URL थेट ब्राउझरमध्ये पेस्ट करा.
• अत्यावश्यक: त्या पानांमागील प्रत्येक API एंडपॉइंटलाही लॉग-इन आवश्यक आहे — फक्त पानाला नव्हे. चाचणी: लॉग आउट करा, ब्राउझरचा नेटवर्क टॅब उघडा, आणि तुम्ही लॉग-इन असताना अ‍ॅपने केलेली विनंती पुन्हा करा.
• अत्यावश्यक: पासवर्ड हॅश करून, हळू पासवर्ड-हॅशिंग अल्गोरिदमने साठवलेले असतात, कधीही साध्या मजकुरात नाही. OWASP च्या पासवर्ड साठवणूक मार्गदर्शनात प्रथम Argon2id सुचवले आहे, आणि scrypt, bcrypt किंवा PBKDF2 पर्याय आहेत. विचारा: "पासवर्ड कसे साठवले जातात?"
• शिफारस: पासवर्ड रीसेट लिंक कालबाह्य होतात आणि फक्त एकदाच काम करतात.
• शिफारस: सेशन कुकीज Secure, HttpOnly आणि SameSite म्हणून चिन्हांकित आहेत, आणि लॉग आउट केल्यावर सर्व्हरवरचे सेशन संपते.
• नंतर: दोन-घटक ऑथेंटिकेशन द्या, किंवा ते असलेल्या प्रदात्याद्वारे साइन-इन करण्याची सोय द्या.

वापरकर्ता डेटा परत करणारा प्रत्येक API मार्ग आणि पान तपासा. प्रत्येकाने लॉग-इन नसलेल्या वापरकर्त्यांच्या विनंत्या नाकारल्या पाहिजेत, फक्त पानाच्या कोडमध्ये नव्हे तर सर्व्हरवर. तुम्ही तपासलेल्या मार्गांची यादी द्या.

2. ऑथरायझेशन: त्यांना काय करण्याची परवानगी आहे?

ऑथरायझेशन म्हणजे लॉग-इननंतरचा टप्पा: हा विशिष्ट वापरकर्ता काय पाहू आणि बदलू शकतो हे ठरवणे. AI ने बनवलेल्या अ‍ॅप्समध्ये इथेच सर्वात गंभीर त्रुटी असतात, कारण अ‍ॅप योग्य दिसतो — प्रत्येक वापरकर्त्याच्या डॅशबोर्डवर फक्त त्यांचा स्वतःचा डेटा दिसतो — पण थेट विनंती केल्यास सर्व्हर कोणाचाही डेटा सहज देतो.

• अत्यावश्यक: प्रत्येक वाचन, अपडेट आणि हटवण्याच्या वेळी सर्व्हरवर तपासा की नोंद सध्याच्या वापरकर्त्याची (किंवा त्यांच्या टीमची) आहे.
• अत्यावश्यक: चाचणी करा: दोन खाती, A आणि B तयार करा. A म्हणून A ची एक नोंद उघडा आणि URL किंवा नेटवर्क विनंतीमधील ID नोंदवा. B म्हणून लॉग-इन करा आणि तोच ID मागवा. B ला त्रुटी मिळाली पाहिजे, A चा डेटा नव्हे.
• अत्यावश्यक: अ‍ॅडमिन पाने आणि अ‍ॅडमिन API एंडपॉइंट्स सर्व्हरवर वापरकर्त्याची भूमिका तपासतात. अ‍ॅडमिन लिंक लपवणे हे संरक्षण नाही.
• अत्यावश्यक: वापरकर्ते विनंती संपादित करून स्वतःची भूमिका, किंमत, शिल्लक किंवा मालक फील्ड बदलू शकत नाहीत. चाचणी: नेटवर्क टॅबमध्ये प्रोफाइल अपडेट काय पाठवते ते पाहा. त्यात role किंवा isAdmin सारखे फील्ड असतील तर AI ला क्लायंटकडून ते दुर्लक्षित करायला सांगा.
• शिफारस: URL मधील ID अंदाज लावण्यास कठीण असावेत (1, 2, 3 ऐवजी यादृच्छिक ID). हे परवानगी तपासणीचा पर्याय नाही, पण ती गहाळ असताना नुकसान मर्यादित करते.

नोंद वाचणारा किंवा बदलणारा प्रत्येक एंडपॉइंट तपासा: लॉग-इन वापरकर्त्याकडे ती नोंद आहे किंवा तिला प्रवेश आहे, हे सर्व्हरवर तपासा. नसेल तर 404 परत करा. मग दोन खात्यांसह ही चाचणी कशी कराल ते दाखवा.

3. डेटाबेसमधील रो-स्तरीय प्रवेश

"रो-स्तरीय प्रवेश" म्हणजे टेबलमधील प्रत्येक रो (एक बुकिंग, एक इनव्हॉइस) फक्त ज्या वापरकर्त्यांची आहे त्यांनाच दिसते. हे लागू करण्याचे दोन सामान्य मार्ग आहेत:

दोन्हीही चांगल्या प्रकारे करता येतात. महत्त्वाचे हे आहे:

• अत्यावश्यक: ब्राउझर डेटाबेसशी थेट बोलत असेल (काही होस्टेड डेटाबेस उत्पादने हे परवानगी देतात), तर प्रत्येक टेबलसाठी रो-स्तरीय नियम चालू आहेत. ते नसतील तर सार्वजनिक की असलेला कोणीही संपूर्ण टेबल वाचू शकतो.
• अत्यावश्यक: क्वेरी ब्राउझरने पाठवलेल्या ID ने नव्हे, तर सध्याच्या वापरकर्ता किंवा टीमनुसार फिल्टर होतात.
• शिफारस: सामायिक डेटा (टीमचे प्रकल्प) यासाठी टीममध्ये कोण आहे याचा स्पष्ट नियम आहे, जो एकाच ठिकाणी लागू होतो.

4. सीक्रेट्स आणि API की

API की ही सेवेसाठीचा पासवर्ड असतो. Stripe, ईमेल आणि AI प्रदाते सर्व त्या वापरतात. पार्श्वभूमीसाठी एन्व्हायर्नमेंट व्हेरिएबल्स आणि सीक्रेट्स म्हणजे काय पहा.

• अत्यावश्यक: की प्रोजेक्टच्या एन्व्हायर्नमेंट व्हेरिएबल्स किंवा सीक्रेट्समध्ये साठवलेल्या आहेत, कोडमध्ये कधीही लिहिलेल्या नाहीत.
• अत्यावश्यक: पैसे खर्च करू शकणाऱ्या किंवा खाजगी डेटा वाचू शकणाऱ्या की फक्त सर्व्हरवर वापरल्या जातात. चाचणी: तुमची लाइव्ह साइट उघडा, डेव्हटूल्समध्ये पेज सोर्स आणि JavaScript फाइल्स पाहा, आणि तुमच्या की ची सुरुवात शोधा (उदा. sk_). ती दिसता कामा नये.
• अत्यावश्यक: की कधीही चॅटमध्ये, सार्वजनिक रेपॉझिटरीमध्ये किंवा स्क्रीनशॉटमध्ये पेस्ट झाल्या नव्हत्या. झाल्या असतील तर प्रदात्याकडे ती रोटेट करा (नवीन तयार करा, जुनी हटवा).
• शिफारस: प्रदाता देत असेल तेथे मर्यादित किंवा स्कोप्ड की वापरा. उदाहरणार्थ, Stripe अशा मर्यादित की सुचवते ज्यांना फक्त तुमच्या इंटिग्रेशनला लागणारी परवानगी असते.
• शिफारस: चाचणी आणि लाइव्ह की वेगळ्या आहेत, आणि तुम्ही तयार असाल तेव्हाच लाइव्ह अ‍ॅप लाइव्ह की वापरतो.

काही की सार्वजनिक असण्यासाठी बनवलेल्या असतात — Stripe ची publishable की (pk_…) किंवा फक्त तुमच्या डोमेनसाठी मर्यादित नकाशा की. नियम शक्ती देणाऱ्या की साठी आहे, की सारखे दिसणाऱ्या प्रत्येक स्ट्रिंगसाठी नाही.

5. इनपुट पडताळणी

वापरकर्ता पाठवतो ते काहीही — फॉर्म फील्ड, फाइल अपलोड, URL पॅरामीटर्स — तुमचा फॉर्म परवानगी देतो तेवढेच नव्हे तर काहीही असू शकते.

• अत्यावश्यक: पडताळणी ब्राउझरमध्ये नव्हे तर सर्व्हरवर होते. ब्राउझर तपासण्या सोयीसाठी असतात; कोणीही त्या वगळू शकतो.
• अत्यावश्यक: डेटाबेस क्वेरी वापरकर्त्याच्या इनपुटमधून एकत्र चिकटवलेल्या मजकुराऐवजी पॅरामीटर्स वापरतात (हे SQL injection रोखते). AI ला पुष्टी करायला सांगा.
• अत्यावश्यक: वापरकर्ते टाइप करतात तो मजकूर मजकूर म्हणूनच दाखवला जातो, HTML म्हणून चालवला जात नाही. चाचणी: तुमचे नाव म्हणून <b>hello</b> टाका. तुम्हाला टॅग्ज दिसायला हवेत, ठळक मजकूर नव्हे.
• शिफारस: फाइल अपलोड प्रकार आणि आकार तपासतात, आणि अपलोड केलेल्या फाइल्स तुमच्या अ‍ॅपच्या मुख्य डोमेनवरून चालवता येणारी पाने म्हणून दिल्या जात नाहीत.
• शिफारस: वापरकर्त्यांना दाखवलेल्या त्रुटी साध्या असतात ("काहीतरी चुकले"); तपशीलवार त्रुटी फक्त सर्व्हर लॉगमध्ये जातात.
• शिफारस: Stripe सारख्या सेवांचे वेबहुक कृती करण्यापूर्वी प्रदात्याची स्वाक्षरी पडताळतात. वेबहुक म्हणजे काय पहा.

प्रत्येक फॉर्म आणि API एंडपॉइंटमध्ये सर्व्हर-बाजूची पडताळणी जोडा: आवश्यक फील्ड, लांबी, स्वरूप आणि परवानगी असलेली मूल्ये. बाकी सर्व स्पष्ट संदेशासह नाकारा. वापरकर्त्यांना अंतर्गत त्रुटी तपशील दाखवू नका.

6. रेट लिमिट आणि गैरवापर

रेट लिमिट एका कालावधीत कोणीही किती विनंत्या करू शकतो याची मर्यादा ठरवते. त्याशिवाय कोणीही दिवसभर पासवर्ड अंदाजू शकतो, तुमचा साइन-अप फॉर्म भरून टाकू शकतो, किंवा सशुल्क API वर तुमचे बिल वाढवू शकतो.

• अत्यावश्यक: लॉग-इन, साइन-अप आणि पासवर्ड रीसेट IP पत्ता आणि खाते प्रति रेट-लिमिट आहेत.
• अत्यावश्यक: प्रत्येक कॉलसाठी तुम्हाला पैसे खर्च करणारी कोणतीही गोष्ट — AI मॉडेल विनंत्या, SMS, ईमेल — प्रति-वापरकर्ता मर्यादा असते आणि लॉग-इन आवश्यक असते.
• शिफारस: सार्वजनिक फॉर्म (संपर्क, वेटलिस्ट) स्पॅम संरक्षण ठेवतात: रेट लिमिट, लपलेले हनीपॉट फील्ड, किंवा CAPTCHA.
• शिफारस: तुमच्या सशुल्क प्रदात्यांवर खर्च मर्यादा किंवा अलर्ट सेट करा, जेणेकरून बग किंवा हल्लेखोर अमर्याद बिल तयार करू शकणार नाही.

7. डिपेंडन्सी

अ‍ॅप्स ओपन-सोर्स पॅकेजेसमधून बनतात, आणि पॅकेजेसमध्ये कधीकधी ज्ञात त्रुटी असतात.

• शिफारस: ज्ञात त्रुटींसाठी तपासा (JavaScript प्रकल्पांसाठी npm audit किंवा तुमच्या पॅकेज मॅनेजरसाठी समतुल्य) आणि प्रभावित असलेले अद्ययावत करा.
• शिफारस: अ‍ॅप आता वापरत नसलेली पॅकेजेस काढा.
• शिफारस: फार थोड्या वापरकर्त्यांची पॅकेजेस, किंवा लोकप्रिय पॅकेजेसच्या चुकीच्या स्पेलिंगसारखी नावे असलेल्यांबद्दल सावध राहा.
• नंतर: दर महिन्या-दोन महिन्यांनी पुन्हा तपासा, किंवा तुमचा कोड GitHub वर असेल तर स्वयंचलित अलर्ट चालू करा.

8. बॅकअप आणि पुनर्प्राप्ती

सुरक्षेत चुकांमधून सावरता येणे समाविष्ट आहे — तुमच्या, AI च्या किंवा हल्लेखोराच्या.

• अत्यावश्यक: तुमचा डेटा कुठे आहे आणि त्याचा बॅकअप आहे का ते माहीत ठेवा. गृहितक धरू नका; तुमच्या होस्टचे दस्तऐवजीकरण तपासा.
• शिफारस: महत्त्वाच्या डेटाची तुमची स्वतःची नियतकालिक निर्यात ठेवा (उदा. CSV निर्यात सुविधा किंवा डेटाबेस डंप), वेगळ्या ठिकाणी साठवलेली.
• शिफारस: तुमचा कोड व्हर्जन कंट्रोलमध्ये ठेवा, म्हणजे कोणतीही आवृत्ती पुनर्संचयित करता येईल.
• शिफारस: विनाशकारी कृती (खाते हटवणे, प्रकल्प हटवणे) पुष्टी मागतात, आणि काही काळ परत करता येईल असे "सॉफ्ट डिलीट" विचारात घ्या.
• नंतर: एकदा प्रत्यक्ष पुनर्संचयनाची चाचणी करा. कधीही पुनर्संचयित न केलेला बॅकअप म्हणजे आशा आहे, योजना नव्हे.

9. लाँचपूर्वी

• अत्यावश्यक: लाइव्ह साइट सर्वत्र HTTPS वापरते.
• अत्यावश्यक: डेव्हलपमेंटमधील नमुना डेटा, चाचणी खाती आणि डीबग पाने काढलेली आहेत.
• शिफारस: गोपनीयता धोरणात तुम्ही कोणता डेटा गोळा करता आणि का ते सांगितले आहे — वैयक्तिक डेटा गोळा केल्यास अनेक ठिकाणी ते आवश्यक असते. तुमच्याकडे नसलेल्या प्रमाणपत्रांचा (SOC 2, HIPAA) दावा करू नका.
• शिफारस: सुरक्षा समस्यांबाबत तुमच्याशी संपर्क साधण्याचा मार्ग आहे, आणि प्रत्येक की पटकन रोटेट कशी करायची हे तुम्हाला माहीत आहे.

सुरक्षेपलीकडे व्यापक लाँचपूर्व तपासणीसाठी, AI प्रोटोटाइप प्रोडक्शनमध्ये कसा न्यायचा पहा.

व्यावसायिक पुनरावलोकन कधी घ्यावे

चेकलिस्ट सामान्य चुका पकडते; ती तज्ज्ञाची जागा घेत नाही. तुम्ही होस्टेड चेकआउटऐवजी स्वतः कार्ड नंबर हाताळत असाल, आरोग्य, आर्थिक किंवा मुलांचा डेटा साठवत असाल, सुरक्षा प्रश्नावली मागणाऱ्या कंपन्यांना विकत असाल, किंवा गळतीमुळे गंभीर हानी होणार असेल, तर पुनरावलोकनासाठी पैसे देण्याचा विचार करा. तुमचा कोड निर्यात करता येणारा असल्यास ते पुनरावलोकन खूप सोपे होते.

Mythex वर बनवताना सुरक्षा

Mythex मध्ये सुरक्षा-स्कॅन पॅनल नाही, त्यामुळे वरील चेकलिस्ट हीच पाळायची प्रक्रिया आहे. काही गोष्टी मदत करतात:

• प्रोजेक्ट सीक्रेट्स. की प्रोजेक्ट सेटिंग्ज → Secrets अंतर्गत साठवा, किंवा एजंट चॅटमध्ये दाखवणाऱ्या secrets कार्डद्वारे, म्हणजे त्या तुमच्या कोडमध्ये आणि संदेशांमध्ये राहणार नाहीत. लाइव्ह अ‍ॅपसाठी सीक्रेट बदलल्यानंतर पुन्हा प्रकाशित करा.
• Plan आणि Ask मोड. एजंटला संपादन न करता परवानग्या तपासायला सांगा: "Ask मोडमध्ये, प्रत्येक API मार्ग आणि त्याची परवानगी तपासणी यादी करा."
• /test एजंटला तुमच्या पूर्वावलोकनावर वापरकर्त्याप्रमाणे क्लिक करायला लावते — कलम 2 मधील दोन-खात्यांच्या चाचणीसाठी उपयुक्त.
• चेकपॉइंट्स तुम्हाला काहीतरी तोडणारा बदल मागे घेण्याची परवानगी देतात.

दस्तऐवजात तुम्ही बनवलेल्या अ‍ॅप्ससाठी सुरक्षा आणि एन्व्हायर्नमेंट व्हेरिएबल्स आणि सीक्रेट्स पहा. पुढे वापरकर्ता खाती जोडणार असाल, तर तुमच्या अ‍ॅपमध्ये लॉग-इन कसे जोडायचे वाचा.

प्रश्न