इसे मेरी अपनी साइट में एक खुला दरवाज़ा मिला। ये रहा फ़िक्स

कोई और आपके ऐप को खोलकर देखे, उससे पहले REA को अपने ही ऐप पर चलाइए। हमने इसे अपनी लाइव साइट पर चलाया, एक throwaway क्लाउड सैंडबॉक्स से, जो मिला उसे ठीक किया और pull request भेज दी।

REA वह reverse engineering skill है जिसे पूरी एक लहर के वीडियो किसी और के सॉफ़्टवेयर पर चला रहे थे। हमारी साइट पर इसे तेरह मिनट से कम लगे और एक भी write request नहीं भेजनी पड़ी, फिर भी इसने दिखा दिया कि कोई भी वेबसाइट हमारी मेलिंग लिस्ट भर सकती थी। इसे हमारे कमेंट बॉट की रोज़ की सीमा भी मिली, जो हमारी साइट से डाउनलोड होने वाले JavaScript के अंदर रखी थी। फ़िक्स के बाद, जो request पहले निकल जाती थी, अब वह रोक दी जाती है।

नतीजा छह नियम हैं, ताकि आप अपने ऐप पर यही ऑडिट चला सकें: throwaway सैंडबॉक्स, सटीक टारगेट, नतीजों की छँटाई, bundle में बैठा config, endpoint के ब्रेक, और फ़िक्स को साबित करना।

REA का मतलब है Reverse Engineer Anything: टूल्स का एक सेट जो Claude Code को वह ऐप खोलकर देखने देता है जिसे आप शिप करते हैं। Reverse engineering का मतलब है तैयार चीज़ से यह समझना कि वह कैसे बनी है, जैसे कोई मैकेनिक फ़ैक्टरी की ड्रॉइंग के बिना कार को पढ़ ले।

आपका सोर्स कोड पढ़ने के बजाय REA bundle पढ़ता है, यानी वह JavaScript जो आपकी साइट हर विज़िटर को असल में भेजती है। उस bundle से यह routes की सूची बनाता है, उन endpoints की जिन्हें आपके पेज बुलाते हैं, और उस हर चीज़ की जो आपने ग़लती से वहाँ छोड़ दी। यह आपको सोर्स वापस नहीं दे सकता, क्योंकि आपके हाथ सिर्फ़ सबूत लगता है, और इसके अपने डॉक्स कहते हैं कि यह sandbox भी नहीं है।

इंस्टॉल करने के लिए:

1. REA को उसके आधिकारिक पैकेज से इंस्टॉल कीजिए और वर्ज़न पिन कीजिए, क्योंकि इसने एक हफ़्ते में छह रिलीज़ निकाली हैं।
2. Claude Code के लिए इसका setup चलाइए।
3. compact profile चालू कीजिए, क्योंकि यह आपके सेशन में सौ से कहीं ज़्यादा टूल लोड करता है।
4. सिर्फ़ आधिकारिक repo से इंस्टॉल कीजिए, क्योंकि मालवेयर वाली नकली कॉपियाँ पहले ही घूम चुकी हैं।

हमारे सैंडबॉक्स में इंस्टॉल चलाने पर एजेंट ने कुछ भी छूने से पहले जाँचा कि पैकेज आधिकारिक repo की ओर इशारा करता है। फिर setup ने skill तो इंस्टॉल कर दी लेकिन कोई टूल सर्वर नहीं, इसलिए Claude Code ने उन्हीं टूल्स के REA के कमांड लाइन वर्ज़न इस्तेमाल किए। अगर setup के बाद आपके टूल नहीं दिखते, तो कुछ रीस्टार्ट करने की ज़रूरत नहीं: वही स्टेप टर्मिनल से चलाइए।

पहला नियम इस बारे में है कि आप इसे कहाँ चलाते हैं। आप एक एजेंट को ब्राउज़र चलाने देने वाले हैं और अपने प्रोडक्शन ऐप पर डाउनलोड किए गए टूल चलाने वाले हैं। आपके लैपटॉप पर वह एजेंट आपकी keys, आपके बाक़ी प्रोजेक्ट्स और हर उस अकाउंट के बगल में बैठा है जिसमें आप साइन इन हैं। REA के अपने सुरक्षा नोट साफ़ कहते हैं: यह sandbox नहीं है।

सैंडबॉक्स एक throwaway मशीन है, इसलिए जो भी बिगड़े वह उसी के अंदर रहता है और आप उसे मिटा देते हैं। अपनी repo पर एक throwaway सैंडबॉक्स खोलिए और पूरा ऑडिट वहीं चलाइए, कभी अपनी मशीन पर नहीं।

हमने Kosuke इस्तेमाल किया, जो Claude Code को आपकी अपनी सब्सक्रिप्शन पर एक डिस्पोज़ेबल क्लाउड मशीन के अंदर चलाता है। आप अपनी repo चुनते हैं, deploy एजेंट को बताते हैं कि आपका ऐप कैसे शुरू होता है, और वह आपको एक preview देता है, यानी एक लिंक जहाँ आपका चलता हुआ ऐप दिखता है। हर चैट को अपनी branch भी मिलती है, यानी कोड की अपनी कॉपी, और वह pull request पर ख़त्म होती है। जब हमने अपनी साइट इम्पोर्ट की, एजेंट ने पैकेज मैनेजर और एक headless ब्राउज़र इंस्टॉल किया, मेमोरी नापी, और मशीन का साइज़ ख़ुद चुना। कुछ मिनट बाद हमारी असली साइट चैट के बगल में चल रही थी, एक ऐसी branch पर जिसे कोई और नहीं छूता।

एक पिछले टेस्ट का जाल: preview में एक नया Next.js ऐप दिखा, लेकिन पेज पर कुछ भी जवाब नहीं दे रहा था। फ़िक्स आपके Next config में एक लाइन है जो preview के पते को अनुमति देती है, और पेज जाग उठता है।

सीमा यह है कि यह वही Claude Code है जिसके चारों ओर एक डिब्बा लगा दिया गया है, इसलिए लोकल वर्चुअल मशीन या कंटेनर भी यही काम करता है। मायने डिब्बे का है, ब्रांड का नहीं।

खुलासा: Kosuke ने हमें अपने टॉप प्लान की मुफ़्त पहुँच दी। साइन-अप के ठीक बाद «Promo code» फ़ील्ड में कोड AIDIVE2026 डालें, आपको सामान्य दस डॉलर की जगह तीस डॉलर के क्रेडिट मिलेंगे।

दूसरा नियम यह है कि आप असल में REA से क्या कहते हैं। अगर आप बस कहें "मेरे ऐप का ऑडिट करो", तो REA की skill रुककर पूछती है कि कौन सा ऐप।

REA ख़ुद कभी ब्राउज़र नहीं खोलता, इसलिए आप उसे debug port के साथ शुरू करते हैं, एक ऐसा दरवाज़ा जो किसी टूल को पेज की हर हरकत देखने देता है। इसे इसी क्रम में सेट कीजिए:

1. debug port को loopback पर रखिए, यानी वह पता जहाँ सिर्फ़ आपकी अपनी मशीन पहुँच सकती है, और ब्राउज़र को नई प्रोफ़ाइल दीजिए।
2. कोई भी पेज लोड होने से पहले हर write request ब्लॉक कीजिए, ताकि ऑडिट आपकी साइट पढ़ सके लेकिन कोई फ़ॉर्म सबमिट न कर सके और कुछ बदल न सके।
3. उसके बाद ही REA को वे सटीक पेज दीजिए जो आप उससे पढ़वाना चाहते हैं।

अपने प्रॉम्प्ट में हमने अपने फ़्री क्लब के दो पेजों के नाम लिए और एक नियम सीधे शब्दों में लिखा: लाइव साइट पर कभी write मत भेजो। यह मायने रखता था, क्योंकि उन पेजों का फ़ॉर्म एक असली मेलिंग लिस्ट में जाता है, जिसमें असली लोग हैं। एजेंट ने नियम को गंभीरता से लिया और अपना एक छोटा सा गार्ड ख़ुद लिखा जो reads को निकलने देता था और बाक़ी सब रोक देता था। ऑडिट के दौरान उस गार्ड ने analytics स्क्रिप्ट की छह कोशिशें रोकीं, और हमारे signup फ़ॉर्म तक एक भी request कभी नहीं पहुँची।

फिर REA ने अपना काम किया: हर पेज की जाँच, हर bundle पढ़ना, स्क्रीनशॉट लेना और स्क्रिप्ट्स को repo के बाहर एक्सपोर्ट करना।

सीमा यह है कि REA सिर्फ़ वही देखता है जो उसके जुड़े रहने के दौरान लोड होता है, इसलिए जो पहले हो चुका वह रिपोर्ट में unknown रहता है। फिर भी अब आपके पास अपने लाइव ऐप की रिपोर्ट है, जो उसके डेटा के एक भी टुकड़े को छुए बिना लिखी गई।

तीसरा नियम है फ़िक्स से पहले छाँटना। ऐसी रिपोर्ट डरावनी लाइनों से भरी होती है और आपका मन करेगा कि सब एक साथ ठीक कर दें।

REA की अपनी skill चाहती है कि हर निष्कर्ष एक evidence ID के साथ observation, inference या unknown के रूप में चिह्नित हो। यानी उसने क्या देखा, क्या अंदाज़ा लगाया, और क्या नहीं देख सका, और evidence ID एक रसीद है जिसे आप जाँच सकते हैं। पहले हर नतीजे को इसी तरह छाँटिए, सिर्फ़ बाहर वाले के नज़रिए से, और किसी भी सोर्स फ़ाइल को खोलने से पहले वह वर्ज़न commit कर दीजिए। फिर अपना सोर्स पढ़िए और हर लाइन को असली लीक, by design, या false positive के रूप में चिह्नित कीजिए।

हमारी रिपोर्ट में पंद्रह नतीजे थे:

नतीजा	REA ने क्या देखा	हमारा फ़ैसला
Signup endpoint	कोई सीमा नहीं और यह जाँच नहीं कि कौन सी साइट बुला रही है, इसलिए कोई भी वेबसाइट किसी विज़िटर के ब्राउज़र से किसी भी पते को हमारी लिस्ट में सब्सक्राइब करा सकती थी	असली लीक, सबसे बुरा
फ़्री पैक पर ईमेल गेट	पूरा पैक उसी पेज में पहले से मौजूद है जो आप लोड करते हैं; ब्राउज़र कंसोल की एक लाइन गेट हटा देती है, या reader mode टेक्स्ट दिखा देता है	By design
Source maps, keys, cookies	bundles में कोई नहीं, और कहीं कोई cookie नहीं	अच्छी ख़बर

गेट by design है क्योंकि पैक जानबूझकर फ़्री हैं, और हमारा अपना कोड कहता है कि टूटा हुआ फ़ॉर्म कभी किसी फ़्री पेज को नहीं छिपाना चाहिए।

सीमा unknown वाला कॉलम है। REA नहीं देख सकता कि आपका सर्वर क्या करता है, इसलिए उन लाइनों को आप अपना सर्वर कोड पढ़कर तय करते हैं।

चौथा नियम इस बारे में है कि आपका bundle क्या ढोता है, क्योंकि एक साझा सेटिंग्स फ़ाइल आपको पता चले बिना हर विज़िटर तक पहुँच सकती है।

ऐसा होता ऐसे है। आप अपना config एक helper में इम्पोर्ट करते हैं, और दो छोटे interactive कंपोनेंट उस helper को इस्तेमाल करते हैं। Bundler, यानी वह टूल जो आपके कोड को उन फ़ाइलों में पैक करता है जिन्हें ब्राउज़र डाउनलोड करता है, यह नहीं जान सकता कि उन्हें कौन सी keys चाहिए, इसलिए वह सब शिप कर देता है।

हमारे JavaScript में REA को ठीक यही मिला। हमारा पूरा साइट config एक फ़ाइल में पड़ा था, जिसमें हमारी मेलिंग लिस्ट की ID, हमारे build फ़ोल्डर, और उस बॉट की सीमाएँ थीं जो हमारे वीडियो के कमेंट्स का जवाब देता है। उसमें यह भी लिखा था कि वह बॉट रोज़ कितने जवाब भेजता है, सौ, और कितनी errors उसका सेफ़्टी स्विच ट्रिप करती हैं। जिन दो कंपोनेंट ने उसे खींचा था वे सिर्फ़ साइट का नाम और भाषाओं की सूची पढ़ते थे।

नियम: अपने शिप किए JavaScript में अपने ही config की keys खोजिए, और क्लाइंट कंपोनेंट्स को सिर्फ़ वही फ़ील्ड दीजिए जो वे पढ़ते हैं। हमारे सैंडबॉक्स में एजेंट ने config को एक छोटे ब्राउज़र वर्ज़न में बाँट दिया जिसमें सिर्फ़ वही फ़ील्ड हैं, और बाक़ी सर्वर पर रहा। उसने एक build स्टेप भी जोड़ा जो तब फेल हो जाता है जब कोई सर्वर key दोबारा किसी शिप की हुई फ़ाइल में दिखे, ताकि आप वापस न फिसल सकें।

इनमें से कुछ भी पासवर्ड नहीं था, लेकिन उस फ़ाइल में जो कुछ है वह सार्वजनिक है, इसलिए आपके secrets सिर्फ़ सर्वर variables में रहते हैं।

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

सिक्योरिटी की दुनिया की अपनी चेकलिस्ट साफ़ कहती है: आपका access control सिर्फ़ उस कोड में काम करता है जिसे हमलावर बदल नहीं सकता, यानी आपका सर्वर। इसलिए ऐसे हर endpoint पर ब्रेक लगाइए:

• Origin जाँच। Origin header वह मुहर है जो ब्राउज़र request पर लगाता है ताकि बताए कि किस साइट ने भेजी, इसलिए किसी दूसरी वेबसाइट का फ़ॉर्म ठुकरा दिया जाता है।
• Rate limit। एक विज़िटर थोड़ी देर की विंडो में कितनी requests भेज सकता है, इस पर सीमा।
• सर्वर पर जाँची गई सहमति। जो बॉक्स आप टिक करते हैं वह सच में request के साथ जाता है।

हमारे सैंडबॉक्स में एजेंट ने ये सब हमारे Worker में लिख दिए, यानी वह छोटा फ़ंक्शन जो आपके विज़िट करने पर पेजों के आगे चलता है। फिर उसने इन्हें एक नक़ली मेलिंग सर्विस के ख़िलाफ़ टेस्ट किया, असली के नहीं, और हर request ठीक उसी जगह ठुकराई गई जहाँ उसे ठुकराई जानी थी। ग़लत साइट से भेजें तो आप ठुकराए जाते हैं। एक मिनट में आपकी छठी request भी ठुकराई जाती है, और सहमति के बिना आप रिजेक्ट होते हैं।

सीमा यह है कि कोई स्क्रिप्ट Origin की मुहर नक़ली बना सकती है, और rate limit हर लोकेशन के हिसाब से गिनता है, इसलिए इसका असली इलाज ईमेल से दोहरी पुष्टि है।

छठा और आख़िरी नियम है फ़िक्स को साबित करना, क्योंकि हरे चेकमार्क की दीवार ठीक वही पल है जब आप देखना बंद कर देते हैं। एक डेवलपर ने, जिसने REA को एक डेस्कटॉप ऐप पर टेस्ट किया, HackerNoon पर लिखा कि यह उन entry points को चूक गया जो ऐप में सच में थे।

इसलिए वही REA स्टेप फ़िक्स किए build पर फिर से चलाइए, हर फ़िक्स टर्मिनल से हाथ से जाँचिए, और उसके बाद ही pull request खोलिए।

फ़िक्स किए build पर वह request जो हमारे signup फ़ॉर्म से निकल जाती थी, अब ठुकरा दी जाती है। हमारी सर्वर keys हर शिप की हुई फ़ाइल से ग़ायब थीं, सिक्योरिटी headers मौजूद थे, और Worker टेस्ट फेल से पास हो गए। हमारे फ़्री पैक का गेट अब भी खुला था, जो हमारा फ़ैसला है, और रिपोर्ट हर लाइन के बगल में यही कहती है।

फिर एजेंट ने pull request खोली। रिपोर्ट्स उसमें सिर्फ़ इसलिए हैं कि हमने प्रॉम्प्ट में उन्हें माँगा था। Kosuke जो टेस्टिंग चेकलिस्ट बनाता है वह सेशन के अंदर ही रही, pull request पर कुछ पोस्ट नहीं हुआ। अगर आपका रिव्यूअर सिर्फ़ GitHub पढ़ता है, तो पहले और बाद की रिपोर्ट्स ख़ुद pull request में डालिए।

फिर हम वही बदलाव अपने कोड में ले आए, और वह हमारी साइट के अगले deploy के साथ लाइव हो जाता है।

पूरा रन यह था: REA हमारी अपनी लाइव साइट पर, एक throwaway सैंडबॉक्स से, हर नतीजा छाँटा गया, असली लीक ठीक हुए, दोबारा ऑडिट हुआ, और pull request के रूप में शिप हुआ। जिस नतीजे ने सबको सही ठहराया वह पहला था: कोई भी वेबसाइट हमारे signup फ़ॉर्म को किसी के भी पते से भर सकती थी।

यह ऑडिट तब चलाइए जब आप कुछ भी लॉन्च करें जिसके पीछे सार्वजनिक फ़ॉर्म या पेड सर्विस हो, और फिर हर बार जब आप बदलते हैं कि क्या शिप होता है। इसे उस सॉफ़्टवेयर पर मत चलाइए जो आपका नहीं है, क्योंकि REA का अपना disclaimer इसे उस सॉफ़्टवेयर तक सीमित करता है जिसके आप मालिक हैं या जिसे जाँचने की आपको अनुमति है। और यह आपका सर्वर कोड पढ़ने की जगह कभी नहीं लेता, क्योंकि unknowns ठीक वहीं रहते हैं।

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

इस वीडियो की फ़्री किट में सटीक प्रॉम्प्ट, triage टेबल और हमारा शिप किया गया Worker फ़िक्स हैं।