तेज़ वेब ऐप स्पॉट-चेक्स के लिए Claude Code सुरक्षा चेकलिस्ट

एक हल्का सुरक्षा स्पॉट-चेक क्या है

एक हल्का सुरक्षा स्पॉट-चेक एक तेज़ समीक्षा है (अक्सर 30–60 मिनट) जिसका उद्देश्य रिलीज़ से पहले स्पष्ट, उच्च-प्रभाव वाले मुद्दों को पकड़ना है। यह एक पूरा ऑडिट नहीं है। इसे एक सुरक्षा निरीक्षण की तरह सोचें: आप उन रास्तों को स्कैन करते हैं जो असल ऐप्स में सबसे अधिक टूटते हैं और अनुमान नहीं बल्कि सबूत ढूँढते हैं।

यह Claude Code सुरक्षा चेकलिस्ट उन क्षेत्रों पर केंद्रित है जो रोज़मर्रा की वेब ऐप्स में सबसे अक्सर टूटते हैं:

• ऑथेंटिकेशन अनुमान (आप किसी उपयोगकर्ता को कैसे पहचानते हैं)
• प्राधिकरण अंतर (वे क्या कर सकते हैं)
• इनपुट वैलिडेशन
• सीक्रेट्स हैंडलिंग
• सामान्य इंजेक्शन सतहें (SQL, कमांड निष्पादन, टेम्पलेट रेंडरिंग, रीडायरेक्ट, अपलोड)

यह बग्स की अनुपस्थिति सिद्ध करने, जटिल खतरे मॉडल करने, या पेन-टेस्ट की जगह लेने की कोशिश नहीं करता।

“ठोस निष्कर्ष” का मतलब है कि हर मुद्दे के साथ ऐसा सबूत जुड़ा होना चाहिए जिस पर डेवलपर तुरंत कार्रवाई कर सके। प्रत्येक निष्कर्ष के लिए, निम्न लिखें:

• सही फ़ाइल(ओं) और फ़ंक्शन/हैंडलर का नाम
• एक वाक्य में जोखिमपूर्ण व्यवहार
• एक न्यूनतम repro स्टेप (अनुरोध, पेलोड, या क्लिक पथ)
• यह क्यों महत्वपूर्ण है (प्रभाव) और कौन इसे ट्रिगर कर सकता है
• एक सुरक्षित समाधान दिशा (पूरा री-राइट नहीं)

AI एक सहायक है, प्राधिकृत नहीं। इसका उपयोग खोजने, संक्षेप करने और परीक्षण प्रस्तावित करने के लिए करें। फिर कोड पढ़कर और संभव होने पर असली अनुरोध से reproduce करके सत्यापित करें। यदि मॉडल विशिष्ट स्थानों और स्टेप्स की तरफ संकेत नहीं कर सकता, तो दावे को अप्रमाणित मानें।

10 मिनट में स्कोप तय करें

एक तेज़ समीक्षा तभी काम करती है जब आप लक्ष्य को संकुचित करें। Claude Code से कुछ भी देखने के लिए कहने से पहले तय करें कि आप आज क्या साबित करना चाहते हैं और क्या नहीं देख रहे।

1–3 असली उपयोगकर्ता यात्राओं (user journeys) से शुरू करें जहाँ गलतियाँ पैसों का नुकसान, डेटा का खुलासा, या पावर देना हो सकती हैं। अच्छे उम्मीदवार: लॉगिन, पासवर्ड रीसेट, चेकआउट, और एडमिन एडिट स्क्रीन।

फिर उन एसेट्स के नाम लिखें जिन्हें आपको बचाना है। विशिष्ट रहें: उपयोगकर्ता खाते, पेमेंट क्रियाएँ, व्यक्तिगत डेटा, एडमिन-ओनली ऑपरेशन्स।

उसके बाद अपनी थ्रेट धारणाएँ सादे शब्दों में लिखें। क्या आप एक जिज्ञासु उपयोगकर्ता, बाहरी स्क्रिप्ट-लेखन अटैकर, या एक अंदरूनी व्यक्ति से बचाव कर रहे हैं? आपका उत्तर तय करेगा कि “पर्याप्त” क्या दिखता है।

अंत में, पास और फेल को परिभाषित करें ताकि आपका स्पॉट-चेक निष्कर्षों के साथ बंद हो, महसूसों के साथ नहीं। सरल नियम काम करते हैं:

• पास: हर संवेदनशील क्रिया पर स्पष्ट authn और authz चेक दिखें।
• फेल: कोई भी endpoint क्लाइंट पर user ID या रोल भरोसा करता है।
• पास: इनपुट्स सर्वर-साइड वैलिडेट किए जाते हैं, सिर्फ UI में नहीं।
• फेल: सीक्रेट्स लॉग्स, कॉन्फ़िग या क्लाइंट कोड में दिखें।

यदि आप यह बताने में असमर्थ हैं कि विफलता कैसी दिखेगी, तो स्कोप अभी भी बहुत अस्पष्ट है।

Claude Code को देने के लिए संदर्भ तैयार करें

एक स्पॉट-चेक तभी काम करता है जब मॉडल सही जगहों को देख रहा हो। एक छोटा कोड और नोट्स का बंडल इकट्ठा करें ताकि समीक्षा अनुमान नहीं बल्कि सबूत दे सके।

सिक्योरिटी-क्रिटिकल पाथ शेयर करने से शुरू करें: रीक्वेस्ट एंट्री पॉइंट्स और वह कोड जो तय करता है कि उपयोगकर्ता कौन है और वह क्या कर सकता है। डेटा फ्लो दिखाने के लिए आसपास का जितना कोड आवश्यक हो उतना शामिल करें।

एक व्यवहारिक बंडल आमतौर पर शामिल करता है:

• ऑथ एंट्री: session/JWT पार्सिंग, कुकी सेटिंग्स, लॉगिन कॉलबैक, auth middleware
• रूट्स + हैंडलर्स: कंट्रोलर्स, RPC मेथड्स, GraphQL resolvers, बैकग्राउंड जॉब हैंडलर्स
• डेटा लेयर: ORM क्वेरीज, रॉ SQL हेल्पर, क्वेरी बिल्डर, संवेदनशील टेबल्स के माइग्रेशन
• पॉलिसी चेक्स: रोल चेक्स, ownership चेक्स, फीचर फ्लैग्स, एडमिन-ओनली एंडपॉइंट्स
• वैलिडेशन: रिक्वेस्ट स्कीमा वेलिडेटर, फ़ाइल अपलोड हैंडलर, डीसिरीयलाइज़ेशन कोड

कुछ लाइनों के वातावरण नोट्स जोड़ें ताकि धारणाएँ स्पष्ट हों: session बनाम JWT, टोकन कहाँ रहते हैं (कुकी या हेडर), रिवर्स प्रॉक्सी या API गेटवे का व्यवहार, क्यूज़/क्रोन वर्कर्स, और कोई “इन्टरनल-ओनली” एंडपॉइंट।

बग्स को खोजने से पहले इन्वेंटरी माँगें: एंट्री पॉइंट्स, प्रिविलेज्ड एंडपॉइंट्स, और डेटा स्टोर्स जिन्हें टच किया जाता है। इससे सतहें छूटती नहीं हैं।

एक आउटपुट फ़ॉर्मेट पर भी सहमति करें जो ठोस निष्कर्ष देता है। एक सरल तालिका काम करती है: Finding, Severity, Affected endpoint/file, Evidence (सटीक स्निपेट या लाइन रेंज), Exploit scenario, Fix suggestion।

30–60 मिनट की समीक्षा के लिए स्टेप-बाय-स्टेप वर्कफ़्लो

समय बॉक्स करें:

• 10 मिनट ओरिएंट होने के लिए
• 15–30 मिनट फ्लोज़ ट्रेस करने के लिए
• 10 मिनट लिखने के लिए

लक्ष्य परफेक्ट कवरेज नहीं है। यह एक छोटा सेट है testable निष्कर्षों का।

जब आप पढ़ते हैं तब ऐप खुला रखें। UI में क्लिक करके देखें कि कौन से अनुरोध फायर होते हैं। नोट्स को विशेष endpoints, पैरामीटर और डेटा सोर्सेस की ओर इशारा करना चाहिए।

एक ऐसा वर्कफ़्लो जो एक ही सत्र में फिट होता है:

1. एंट्री पॉइंट्स और ट्रस्ट बाउंड्रीज़ का स्केच बनाएं। सार्वजनिक रूट्स, लॉग्ड-इन रूट्स, एडमिन रूट्स, वेबहुक्स, अपलोड्स, और थर्ड-पार्टी कॉलबैक्स नोट करें। जहाँ डेटा उपयोगकर्ता-नियंत्रित से सर्वर-ट्रस्टेड में आता है, उसे मार्क करें।
2. हर महत्वपूर्ण एंडपॉइंट के लिए लिखें कि पहचान कैसे साबित होती है और यह कहाँ होता है। अगर चेक middleware है, तो पुष्टि करें कि हर रूट वास्तव में उसे उपयोग करता है।
3. ऑथराइज़ेशन के लिए भी यही करें। एक जोखिमपूर्ण क्रिया चुनें (दूसरे उपयोगकर्ता का डेटा देखना, रोल अपडेट करना, एक्सपोर्ट, डिलीट) और परमिशन निर्णय को डाटाबेस क्वेरी तक ट्रेस करें।
4. यूज़र इनपुट को सिंगल सिंक तक ट्रेस करें। एक पैरामीटर को रिक्वेस्ट से SQL/ORM क्वेरी, टेम्पलेट रेंडरिंग, कमांड निष्पादन, URL फेच (SSRF), रीडायरेक्ट्स, और फ़ाइल पाथ्स तक फॉलो करें।
5. ट्रेस करते हुए सीक्रेट और कॉन्फ़िग फ्लोज़ को स्कैन करें। टोकन लॉग्स, क्लाइंट-साइड कोड, एरर मेसेजेस, और एनवायरनमेंट डंप्स में देखें।

एक उपयोगी आदत: हर “ठीक लग रहा है” के लिए लिखें कि आप इसे तोड़ने के लिए क्या करेंगे। अगर आप तोड़ने का वर्णन नहीं कर सकते, तो संभवतः आपने सत्यापित नहीं किया।

Authn स्पॉट-चेक्स: साबित करें कि उपयोगकर्ता कौन है

Authentication वह जगह है जहाँ ऐप तय करता है, “यह अनुरोध इस व्यक्ति का है।” एक तेज़ स्पॉट-चेक हर लाइन पढ़ने के बारे में नहीं है। यह उस स्थान को ढूंढने के बारे में है जहाँ पहचान स्थापित होती है, फिर शॉर्टकट्स और फेल्योर पाथ्स को चेक करना है।

ट्रस्ट बाउंड्री ढूँढें: पहचान पहली बार कहाँ बनती या स्वीकृत होती है? यह session कुकी, JWT bearer टोकन, API की, या एज पर mTLS हो सकता है। Claude Code से कहें कि वह ठीक फ़ाइल और फ़ंक्शन का नाम बताए जो “anonymous” को user id में बदलता है, और हर दूसरे पथ को सूचीबद्ध करे जो वही कर सकता है।

जाँचें लायक Authn चीज़ें:

• सभी auth एंट्री पॉइंट्स पहचानें (वेब लॉगिन, API टोकन, मोबाइल ऑथ, इंटरनल सर्विस ऑथ) और पुष्टि करें कि वे एक सुसंगत पहचान मॉडल पर मिलते हैं।
• लॉगिन और पासवर्ड रीसेट के लिए रेट लिमिट, लॉकआउट, और यूज़र एनेमरेशन की जाँच करें (अलग एरर मेसेज या टाइमनig जो अकाउंट अस्तित्व का संकेत दे)।
• सेशन और कुकीज़ की समीक्षा: HttpOnly, Secure, SameSite, एक्सपायरी, लॉगिन और प्रिविलेज बदलने पर रोटेशन, और लॉगआउट इनवैलिडेशन (सर्वर-साइड, सिर्फ “कुकी डिलीट” नहीं)।
• MFA और रिकवरी की समीक्षा करें ताकि रिकवरी पाथ MFA से कमजोर न हो (उदा., सिर्फ ईमेल रीसेट जो MFA को बायपास कर दे)।
• ऑथ विफलता लॉगिंग की समीक्षा: ऑप्स के लिए उपयोगी है, लेकिन ऐसे विवरण न दें जो अटैकर्स की मदद करें (कोई “user exists” संकेत नहीं, कोई token dumps नहीं)।

एक व्यवहारिक उदाहरण: अगर रीसेट ईमेल्स “account not found” वापस करती हैं, तो यह तेज़ enumeration इशू है। यहाँ तक कि सामान्य संदेश होने पर भी समयांतराल भेद उसी तथ्य को प्रकट कर सकता है, इसलिए प्रतिक्रिया समय की भी जाँच करें।

Authz स्पॉट-चेक्स: साबित करें कि उपयोगकर्ता को अनुमति है

Authorization वह प्रश्न है जिसका गलत होना सबसे ज़्यादा नुकसान पहुंचाता है: “क्या यह उपयोगकर्ता इस सटीक रिसोर्स पर यह क्रिया करने के लिए अनुमति रखता है?” एक तेज़ स्पॉट-चेक जानबूझकर उस अनुमान को तोड़ने की कोशिश करनी चाहिए।

रोल्स और परमिशन्स को साधे मानव-भाषा में लिखें:

• Owner सदस्य आमंत्रित कर सकता है
• Member अपना प्रोफ़ाइल संपादित कर सकता है
• Support बिलिंग विवरण देख सकता है पर प्लान बदल नहीं सकता
• Admin प्रोजेक्ट्स डिलीट कर सकता है

फिर सत्यापित करें कि हर संवेदनशील क्रिया सर्वर पर authz लागू करती है, सिर्फ UI में नहीं। बटन छुपाना या क्लाइंट पर रूट ब्लॉक करना पर्याप्त नहीं है — अटैकर सीधे API कॉल कर सकता है।

एक तेज़ स्कैन जो आमतौर पर असली मुद्दे ढूँढता है:

• उन endpoints/mutations को खोजें जो बनाते, डिलीट करते, एक्सपोर्ट करते, रोल बदलते, या बिलिंग एक्सेस करते हैं
• हर एक के लिए सर्वर-साइड परमिशन चेक खोजें (फ्रंटएंड नहीं)
• उपयोगकर्ता-नियंत्रित IDs (projectId, userId, orgId) ढूँढें और ownership चेक्स की पुष्टि करें
• पुष्टि करें कि एडमिन-ओनली पाथ्स रोल मिसिंग होने पर बंद हो जाते हैं
• टेनेन्ट सीमाओं की जाँच करें: orgId/accountId सत्र संदर्भ से आना चाहिए, सिर्फ रिक्वेस्ट इनपुट से नहीं

क्लासिक IDOR की गंध सरल है: अनुरोध जैसे GET /projects/{id} जहाँ {id} उपयोगकर्ता-नियंत्रित है और सर्वर इसे लोड करता है बिना यह सत्यापित किए कि यह वर्तमान उपयोगकर्ता या टेनेन्ट का है।

एक प्रम्प्ट जो वास्तविक उत्तर ज़बरदस्त करता है:

“इस endpoint के लिए, वह सही कोड दिखाएँ जो एक्सेस तय करता है, और उन विशिष्ट शर्तों को सूचीबद्ध करें जो एक अलग orgId के उपयोगकर्ता को इसे एक्सेस करने देंगी। यदि नहीं, तो फ़ाइल और फ़ंक्शन नाम के साथ समझाएँ।”

इनपुट वैलिडेशन: गलत डेटा को जल्दी बाहर रखें

अधिकतर तेज़ वेब ऐप मुद्दे एक गैप से शुरू होते हैं: ऐप उस इनपुट को स्वीकार कर लेता है जिसकी डेवलपर ने उम्मीद नहीं की थी। “इनपुट” को कुछ भी मानें जिस पर उपयोगकर्ता या दूसरा सिस्टम प्रभाव डाल सकता है, भले ही वह हानिरहित लगे।

स्पॉट-चेक किए जा रहे एंडपॉइंट के लिए इनपुट्स का नाम लिखकर शुरू करें:

• URL क्वेरी और पाथ वैल्यूज़
• रिक्वेस्ट बॉडी फ़ील्ड्स (घने JSON सहित)
• हेडर (ऑथ हेडर, कंटेंट टाइप, फ़ॉरवर्डेड IP)
• कुकीज़
• फ़ाइल अपलोड (नाम, साइज, प्रकार, मेटाडेटा)

वैलिडेशन उस जगह हो जहाँ डेटा ऐप में प्रवेश करता है, न कि बिज़नेस लॉजिक में गहरे। बेसिक्स चेक करें: टाइप (string बनाम number), अधिकतम लंबाई, required बनाम optional, और फॉर्मेट (email, UUID, date)।

रोल्स, स्टेटस फ़ील्ड्स, या sort directions जैसे ज्ञात मानों के लिए allowlist पसंद करें। यह कुछ बुरे मानों को ब्लॉक करने से अधिक सुरक्षित है।

एरर हैंडलिंग की भी जाँच करें। अगर ऐप इनपुट रिजेक्ट करता है, तो कच्चा वैल्यू रिस्पॉन्स, लॉग या UI में इको न करें। छोटी वैलिडेशन गलतियाँ डेटा लीक या इंजेक्शन सहयोगी बन सकती हैं।

जोखिमपूर्ण एंडपॉइंट्स (लॉगिन, सर्च, अपलोड, एडमिन क्रियाएँ) के लिए एक छोटा “बुरा इनपुट” योजना:

• बहुत लंबी स्ट्रिंग्स (10,000+ कैरेक्टर)
• गलत टाइप्स (array के बजाय string)
• अनपेक्षित enum मान
• विशेष कैरेक्टर जो अर्थ बदल दें
• आवश्यक फ़ील्ड्स के लिए खाली मान

उदाहरण: एक sort पैरामीटर जो कोई भी स्ट्रिंग स्वीकार करता है बाद में SQL फ़्रैगमेंट बन सकता है। एक allowlist जैसे "date" या "price" उस क्लास की खराबियों को जल्दी रोकता है।

तेज़ स्कैन के लिए सामान्य इंजेक्शन सतहें

अधिकतर तेज़ समीक्षाएँ उन्हीं कुछ स्थानों में मुद्दे पाती हैं: जहाँ भी उपयोगकर्ता इनपुट को कोड, क्वेरी, पाथ, या URL के रूप में व्याख्यायित किया जाता है। इस सेक्शन में आप उन “इनपुट ट्रस्ट बाउंड्री पार करता है” क्षणों की तलाश करते हैं।

एंट्री पॉइंट्स (क्वेरी पैरामीटर, हेडर, कुकीज़, अपलोड, एडमिन फॉर्म) से जहाँ डेटा जाता है उसे ट्रेस करें।

तेज़ स्कैन लक्षित क्षेत्र

इन पैटर्न्स के लिए खोजें और हर एक के लिए एक ठोस कॉल साइट और पेलोड उदाहरण माँगें:

• SQL इंजेक्शन: स्ट्रिंग-निर्मित क्वेरीज, डायनामिक ORDER BY, और IN (...) बिल्डर जो उपयोगकर्ता मान जोड़ते हैं
• XSS: HTML रेंडरिंग, टेम्पलेट्स, मार्कडाउन प्रीव्यूज़, रिच टेक्स्ट एडिटर्स जहाँ “बाद में sanitize” माना गया हो
• कमांड इंजेक्शन: इमेज प्रोसेसिंग, PDF टूल्स, बैकअप या "convert" स्टेप्स जिनमें शेल कॉल्स और उपयोगकर्ता-नियंत्रित फ़्लैग पास होते हैं
• SSRF: URL फेचर जो वेबहुक्स, लिंक प्रीव्यू, import-from-URL फीचर, और internal status checks के लिए उपयोगकर्ता URL स्वीकार करते हैं
• पाथ ट्रैवर्सल: फ़ाइल डाउनलोड एंडपॉइंट्स, zip extraction, और अपलोड पाइपलाइन जहाँ बाद में नाम के द्वारा फाइल पढ़ी जाती है

डिसीरियलाइज़ेशन और टेम्पलेट इंजेक्शन पर भी ध्यान दें। कोई भी फ़ीचर जो उपयोगकर्ता-प्रदान JSON, YAML, या टेम्पलेटेड स्ट्रिंग्स पार्स करता है जोखिम छुपा सकता है, खासकर जब वह कस्टम प्रकार या expressions का समर्थन करता हो।

यदि कोई फ़ीचर URL, फ़ाइलनाम, या फ़ॉर्मेटेड टेक्स्ट स्वीकार करता है, तब तक इसे दुरुपयोग-योग्य मानें जब तक आप कोड पाथ्स और परीक्षणों के साथ गलत साबित न कर दें।

सीक्रेट्स हैंडलिंग: लीक और कमजोर भंडारण ढूँढें

सीक्रेट्स की समस्याएँ अक्सर तेज़ी से दिखती हैं जब आप जानते हैं कहां देखना है। वहाँ पर ध्यान केंद्रित करें जहाँ सीक्रेट्स रहते हैं और जहाँ वे आकस्मिक रूप से कॉपी हो जाते हैं।

सीक्रेट्स सामान्यतः इन जगहों पर दिखते हैं:

• एनवायरनमेंट वेरियेबल्स और ऐप कॉन्फ़िग फ़ाइलें
• CI आउटपुट और बिल्ड लॉग्स (किसी विफल डिप्लॉय लॉग सहित)
• क्लाइंट बंडल और मोबाइल बिल्ड (जो यूज़र्स को भेजे जाते हैं)
• डिबग एंडपॉइंट्स, हेल्थ पेजेज, और एडमिन टूल्स
• एरर पेजेज, स्टैक ट्रेसेस, और एनालिटिक्स इवेंट्स

फिर एक ठोस जवाब माँगें: अगर आज कोई सीक्रेट एक्सपोज़ हो जाता है तो अगला क्या होगा? अच्छा सिस्टम रोटेशन पाथ (नया की जारी), रिवोकेशन (पुराना की अक्षम), और जल्दी से redeploy करने का तरीका रखता है। अगर उत्तर “हम बाद में बदल देंगे” हो, तो उसे एक निष्कर्ष मानें।

लीस्ट प्रिविलेज एक और तेज़ जीत है। कीज़ ओवरपॉवर होने से घटनाएँ बिगड़ती हैं। DB उपयोगकर्ता जो टेबल ड्रॉप कर सके, थर्ड-पार्टी टोकन जो अकाउंट्स मैनेज कर सकें, या एक की जो वातावरणों में साझा हो—इन पर ध्यान दें। एक सेवा/पर्यावरण के लिए एक की और सबसे सीमित अनुमति पसंद करें।

तेज़ स्पॉट-चेक प्रम्प्ट्स जिन्हें आप Claude Code में पेस्ट कर सकते हैं:

• “हार्ड-कोडेड टोकन, पासवर्ड, और प्राइवेट कीज़ खोजें। सटीक फ़ाइल पाथ और आपने जो स्ट्रिंग पैटर्न मैच किए हैं उन्हें सूचीबद्ध करें।”
• “कोई कोड जो रिक्वेस्ट हेडर, कुकीज़, env vars, या पूरा एरर ऑब्जेक्ट लॉग करता है उसे खोजें। लॉग लाइन्स दिखाएँ और कौन से संवेदनशील फ़ील्ड प्रकट हो सकते हैं।”
• “जाँचें कि सीक्रेट्स snapshots, एक्सपोर्ट्स, या बिल्ड आर्टिफैक्ट में जा सकते हैं। पहचानें कि क्या कैप्चर होता है और कहाँ स्टोर होता है।”

अंत में, गार्डरिल्स की पुष्टि करें: सोर्स कंट्रोल में सीक्रेट्स ब्लॉक करें (pre-commit/CI चेक), और सुनिश्चित करें कि बैकअप या स्नैपशॉट्स प्लेन-टेक्स्ट क्रेडेंशियल्स नहीं शामिल करते। यदि आपका प्लेटफ़ॉर्म स्नैपशॉट और रोलबैक सपोर्ट करता है, तो सुनिश्चित करें कि सीक्रेट्स रनटाइम में इंजेक्ट होते हैं, इमेज में बेक नहीं होते।

ठोस निष्कर्ष ज़बरदस्त करने वाले प्रम्प्ट्स (कॉपी-पेस्ट पैटर्न)

अस्पष्ट प्रम्प्ट अस्पष्ट उत्तर लाते हैं। मॉडल से सबूत के लिए कमिट करने को कहें: सटीक स्थान, एक ट्रेस जिसे आप फ़ॉलो कर सकें, एक repro जो आप चला सकें, और क्या चीज़ दावे को गलत साबित करेगी।

एक बार में एक पैटर्न यूज़ करें, फिर पुष्टि या अस्वीकृति के बाद संशोधन माँगें।

• फ़ाइल-स्तर सबूत: “रिपो में auth, sessions, tokens, और middleware खोजें। सटीक फ़ाइलें, फ़ंक्शन, और लाइन रेंज नाम दें। संबंधित स्निपेट उद्धरण करें। यदि आप कोड की तरफ इशारा नहीं कर सकते, तो 'no evidence found' कहें।”
• इनपुट से सिंक तक ट्रेस: “एक उपयोगकर्ता-नियंत्रित इनपुट चुनें (हेडर, क्वेरी, बॉडी, कुकी)। एंट्री पॉइंट से लेकर जहाँ इसका उपयोग होता है (SQL, HTML, शेल, टेम्पलेट, रीडायरेक्ट, फ़ाइल पथ) तक कदम-दर-कदम डेटा फ़्लो दिखाएँ। हर फ़ंक्शन की सूची दें।”
• Repro स्टेप्स: “एक न्यूनतम repro curl के साथ दें (मेथड, URL आकार, हेडर, बॉडी)। अपेक्षित स्टेटस कोड और सफलता/विफलता प्रतिक्रिया उदाहरण शामिल करें। धारणाएँ बताएं (रोल, ऑथ स्टेट)।”
• False-positive नियंत्रण: “क्या चीज़ इस निष्कर्ष को खारिज करेगी? 2–3 चेक सूचीबद्ध करें: कॉन्फ़िग फ़्लैग्स, middleware ऑर्डर, allowlist वैलिडेशन, पैरामीटराइज़्ड क्वेरीज, फ्रेमवर्क एस्केपिंग। यदि कोई मौजूद है, तो समझाएं कि जोखिम कैसे बदलता है।”
• सबसे छोटा सुरक्षित फिक्स + टेस्ट: “एक छोटा सा परिवर्तन सुझाएँ जो मुद्दे को बिना वैध केस तोड़े ब्लॉक करे। फिर जोड़ने के लिए एक टेस्ट लिखें (नाम, इरादा, इनपुट्स, अपेक्षित परिणाम)। यदि tradeoffs हैं, उन्हें बताएं।”

यदि आउटपुट अभी भी धुंधला लगे, तो पिन करें:

“सिर्फ उत्तर दें: file path, function name, risky line, और एक-वाक्य असर।”

एक यथार्थवादी उदाहरण: धारणा को सत्यापित समस्या में बदलना

प्रोफ़ाइल अपडेट एंडपॉइंट्स अक्सर एक्सेस कंट्रोल बग छुपाते हैं। यहाँ एक छोटा केस है जिसे आप इस चेकलिस्ट के साथ चला सकते हैं।

परिदृश्य: एक API एंडपॉइंट उपयोगकर्ता प्रोफ़ाइल अपडेट करता है:

PATCH /api/profile?accountId=123 JSON जैसा { "displayName": "Sam" } के साथ।

आप Claude Code से हैंडलर ढूँढने, यह ट्रेस करने, और यह साबित करने को कहते हैं कि accountId कैसे उपयोग होता है और क्या सर्वर ownership लागू करता है।

अक्सर जो दिखाई देता है:

• Authn: अनुरोध को सेशन या टोकन की आवश्यकता होती है, इसलिए यह संरक्षित लगता है।
• Authz: हैंडलर क्वेरी स्ट्रिंग से accountId पर भरोसा करता है और उस अकाउंट को अपडेट कर देता है बिना यह जाँच किए कि यह लॉग्ड-इन उपयोगकर्ता का है।
• Input validation: displayName ट्रिम किया जाता है, पर accountId को integer के रूप में वैलिडेट नहीं किया गया है।
• Injection surface: SQL स्ट्रिंग concatenation से बनती है जैसे "... WHERE account_id=" + accountId।

एक अच्छा लिखित निष्कर्ष ठोस होगा:

• Severity: High (IDOR + संभावित SQL injection)
• Evidence: वैध लॉगिन के साथ एक अनुरोध दूसरे उपयोगकर्ता को बदल देता है जब accountId बदला जाता है; SQL अनट्रस्टेड इनपुट से बन रही है
• Fix: क्लाइंट से accountId को अनदेखा करें, सर्वर पर authenticated user का account id उपयोग करें; क्वेरी को पैरामीटराइज़ करें
• Test: दूसरे अकाउंट को अपडेट करने का प्रयास करें और 403 अपेक्षित करें; non-numeric accountId रिजेक्ट करें

फ़िक्स के बाद, तेज़ री-चेक करें:

• वही अनुरोध अलग accountId के साथ आज़माएं और पुष्टि करें कि यह फेल होता है।
• पुष्टि करें कि लॉग्स दिखाते हैं कि सर्वर authenticated id का उपयोग कर रहा है, क्वेरी पैरामीटर से नहीं।
• पुष्टि करें कि क्वेरी placeholders/params का उपयोग करती है, न कि स्ट्रिंग बिल्डिंग।
• एक नेगेटिव टेस्ट चलाएँ malformed इनपुट (अक्षर, बहुत बड़ा नंबर) के लिए।

सामान्य जाल जो स्पॉट-चेक्स को असली मुद्दे से चूकने देते हैं

सबसे तेज़ तरीका जिससे आप किसी भेद्यता को मिस कर देते हैं, वह है UI पर दिख रहे नियंत्रणों पर भरोसा कर लेना। एक बटन जो छुपा या डिसेबल है, परमिशन चेक नहीं है। अगर सर्वर अनुरोध स्वीकार कर लेता है, तो कोई भी इसे दूसरे user ID, रोल, या डायरेक्ट API कॉल के साथ replay कर सकता है।

एक और सामान्य चूक अस्पष्ट अनुरोध है। “सुरक्षा समीक्षा करें” आमतौर पर सामान्य रिपोर्ट देता है। एक स्पॉट-चेक को टाइट स्कोप (कौन से एंडपॉइंट्स, कौन से रोल्स, कौन सा डेटा) और सख्त आउटपुट फॉर्मेट (फ़ाइल नाम, फ़ंक्शन, जोखिम भरी लाइन, न्यूनतम repro) चाहिए।

AI आउटपुट के लिए वही नियम लागू होते हैं: दावों को pointers के बिना स्वीकार न करें। यदि किसी निष्कर्ष में ठोस कोड स्थान और ट्रिगर करने का चरण-दर-चरण तरीका नहीं है, तो उसे अप्रमाणित मानें।

स्पॉट-चेक्स के भटकने के सामान्य तरीके

ये जाल बार-बार दिखते हैं:

• किसी पेज को “admin-only” मान लेना क्योंकि यह admin पेज है, न कि इसलिए कि सर्वर इसे लागू करता है
• व्यापक समीक्षा परिणाम मांगना बजाय “यह X को bypass करने वाला सटीक अनुरोध दिखाएँ” कहने के
• “संभव SQL इंजेक्शन” को स्वीकार कर लेना बिना उस क्वेरी निर्माण बिंदु और इनपुट पथ के
• वेबहुक्स, शेड्यूल्ड जॉब्स, इम्पोर्ट टूल्स, और इंटरनल एडमिन क्रियाओं जैसे कम दिखने वाले एंट्री पॉइंट्स को स्किप करना
• हर नए एज केस के बाद फिल्टर जोड़ना जबकि मूल कारण वैलिडेशन या परमिशन मिसिंग होना है

यदि आप खुद को हर नए एज केस के लिए और फ़िल्टर जोड़ते हुए पाएँ, तो रुकें। फिक्स अक्सर पहले और सरल होता है: बाउंड्री पर इनपुट वैलिडेट करें, और authorization चेक्स को स्पष्ट व केंद्रीकृत बनाएं ताकि हर कोड पाथ उन्हें उपयोग करे।

शिप करने से पहले आप जो तेज़ जाँचें चला सकते हैं

ये एक पूर्ण समीक्षा की जगह नहीं लेते, पर वे अशांतियों को पकड़ लेते हैं जो थके हुए समय में छूट जाती हैं। इन्हें उस पर फोकस रखें जिसे आप तेज़ी से साबित कर सकते हैं: एक अनुरोध जिसे आप भेज सकते हैं, एक पेज जिसे आप लोड कर सकते हैं, एक लॉग लाइन जिसे आप ढूँढ सकते हैं।

अकसर फायदा देने वाली पाँच तेज़ स्पॉट-चेक्स:

• Authn friction: 10 गलत लॉगिन्स आज़माएँ। क्या आप रेट लिमिट्स, लॉकआउट, या कम-से-कम धीमा पड़ने देखते हैं? क्या किसी ईमेल के अस्तित्व का पता त्रुटि संदेशों या टाइमिंग से चलता है?
• Authz by ID swap: एक असली रिसोर्स चुनें (order, invoice, profile)। URL, JSON बॉडी, या GraphQL वैरिएबल्स में ID बदलें। क्या आपको कोई ऐसा डेटा मिलता है जो आपका नहीं है, भले वह सिर्फ metadata ही क्यों न हो?
• Input guardrails: प्रमुख फ़ील्ड्स (email, name, search, file upload) के लिए बहुत लंबे स्ट्रिंग्स, अजीब यूनिकोड, और अनपेक्षित टाइप्स आज़माएँ (नंबर के बजाय स्ट्रिंग)। क्या आप लंबाई सीमाएँ और allowlists लागू करते हैं जहाँ ज़रूरी हैं?
• Secrets exposure: हाल के लॉग्स और क्लाइंट बंडल्स में टोकन, API कीज़, JWTs, या "Authorization: Bearer" खोजें। एरर पेजेज़ भी चेक करें। “यह सिर्फ स्टेजिंग में था” अक्सर “यह शिप हो गया” बन जाता है।
• Injection surfaces: SQL, फिल्टर, टेम्पलेट रेंडरिंग, शेल कमांड, या रीडायरेक्ट URLs में स्ट्रिंग कंकैट लगे होने की तलाश करें। यदि इनपुट बिना मजबूत वैलिडेशन के किसी एक तक पहुँचता है, तो जोखिम मानें जब तक कि कोड न दिखा दे कि सुरक्षित है।

अगले सप्ताह में आप जो तीन शीर्ष फिक्स शिप कर सकते हैं उनकी सूची लिखें, न कि एक इच्छा-सूची। उदाहरण: (1) लॉगिन और पासवर्ड रीसेट पर रेट लिमिट जोड़ें, (2) "get by id" एंडपॉइंट पर सर्वर-साइड ownership चेक लागू करें, (3) search फ़ील्ड के लिए इनपुट लंबाई सीमित करें और अप्रत्याशित कैरेक्टर्स रिजेक्ट करें।

अगले कदम: इस चेकलिस्ट को अपने बिल्ड प्रोसेस का हिस्सा बनाएं

एक स्पॉट-चेक तभी फायदेमंद है जब निष्कर्ष शिपिंग पर असर डालें। इस चेकलिस्ट को एक छोटे, दोहराए जाने योग्य बिल्ड स्टेप की तरह ट्रीट करें, न कि एक बार का बचाव मिशन।

हर निष्कर्ष को एक बैकलॉग आइटम में बदलें जो समझने में मुश्किल न हो:

• Fix: कोड या कॉन्फ़िग में क्या बदलेगा
• Test: आप इसे कैसे साबित करेंगे (एक अनुरोध, एक यूनिट टेस्ट, एक QA स्टेप)
• Owner: एक जिम्मेदार व्यक्ति
• Target date: अगला रिलीज़ या एक निश्चित दिन
• Evidence: फ़ाइल/एंडपॉइंट और वह सटीक अनुरोध या पेलोड जिसने मुद्दा दिखाया

ऐसा कैडेंस चुनें जो आपके जोखिम और टीम साइज से मेल खाता हो। कई टीमों के लिए हर रिलीज़ सबसे अच्छा होता है। अगर रिलीज़ अक्सर हैं, तो मासिक 30–60 मिनट समीक्षा और शिप करने से पहले एक छोटा चेक करें।

दोहराने में आसान बनाने के लिए एक reusable prompt pack और चेकलिस्ट टेम्पलेट बनाएं। प्रॉम्प्ट्स को ठोस आउटपुट की ओर केंद्रित रखें: रूट दिखाएँ, गार्ड दिखाएँ, विफल अनुरोध दिखाएँ, और अपेक्षित व्यवहार बताएं। पैक को वहीं स्टोर करें जहाँ आपकी टीम पहले से काम करती है ताकि यह छोड़ा न जाए।

यदि आप चैट के माध्यम से ऐप बनाते हैं, तो प्लानिंग में चेकलिस्ट को शामिल करें। ऑथन/ऑथज, इनपुट्स, और सीक्रेट्स के लिए एक छोटा “सिक्योरिटी धारणाएँ” नोट जोड़ें, फिर पहले काम करने वाले वर्जन के तुरंत बाद स्पॉट-चेक चलाएँ।

Platforms like Koder.ai (koder.ai) ऐसे अभ्यासों के साथ अच्छा मेल खा सकते हैं क्योंकि वे आपको जल्दी इटरेट करने देते हैं जबकि समीक्षा चेकपॉइंट बनाए रखते हैं। स्नैपशॉट और रोलबैक का उपयोग जोखिम भरे बदलावों के चारों ओर सुरक्षा फ़िक्स शिप करने को आसान बनाता है।