थर्ड-पार्टी स्क्रिप्ट एक आपूर्ति-शृंखला जोखिम है
थर्ड-पार्टी स्क्रिप्ट वह कोड है जो आपने नहीं लिखा, जो एक ऐसी कंपनी देती है जिसे आप नियंत्रित नहीं करते, और जो आपके पेजों के भीतर आपके उपयोगकर्ताओं के सत्रों के साथ चलता है — आपूर्ति-शृंखला की भाषा में, यह एक ऐसी निर्भरता है जो बिना रिलीज़, बिना समीक्षा और बिना सूचना के किसी भी क्षण अपना कोड खुद बदल सकती है। अक्टूबर 2026 में वह अमूर्त जोखिम, जैसा कि बताया गया, ठोस नुकसान बन गया, जब एक बड़े ट्रेडिंग साइट द्वारा लोड की गई प्रदर्शन-निगरानी स्क्रिप्ट को उसके उपयोगकर्ताओं को निकालने के लिए बनी स्क्रिप्ट से बदल दिया गया। यह लेख बताई गई बातों से गुज़रता है, SRI वास्तव में क्या रोकता है, किसी संस्करण को पिन करना उसके हैश से पहले क्यों आता है, स्वयं-होस्टिंग कब बेहतर उत्तर है, और वह छोटी ऑडिट दिनचर्या जो सूची को ईमानदार रखती है।
Polymarket में क्या हुआ, जैसा कि बताया गया
जैसा कि बताया गया, 29 अक्टूबर 2026 को Polymarket की अंतरराष्ट्रीय साइट ने, उपयोगकर्ताओं द्वारा अपने खातों से धन निकलने की सूचना के बाद, ट्रेडिंग को केवल-रद्द मोड में डाल दिया, और लगभग एक घंटे बाद ट्रेडिंग फिर शुरू हुई। जैसा कि बताया गया, कंपनी के अपने बयानों ने घटना को एक समझौता किए गए थर्ड-पार्टी प्रदाता से जोड़ा, कहा कि मामला कानून प्रवर्तन को भेजा गया है, और प्रभावित उपयोगकर्ताओं को पूरी तरह भरपाई करने का वादा किया। कंपनी के 30 अक्टूबर के पोस्टमॉर्टम पर आधारित रिपोर्टों ने हमले में ली गई राशि लगभग 2.7 मिलियन डॉलर बताई, और ट्रेडिंग ठहराव से हुए नुकसानों के लिए सद्भावना भुगतानों को शामिल करने पर कुल रिफ़ंड 3.9 मिलियन डॉलर बताया; कवरेज में उद्धृत स्वतंत्र ऑन-चेन विश्लेषणों ने कई सौ वॉलेटों में फैली इसी तरह की राशि, लगभग 2.7 मिलियन डॉलर का पता लगाया। इनमें से कोई भी आँकड़ा यहाँ स्वतंत्र रूप से सत्यापित नहीं है — ये रिपोर्टिंग के आँकड़े हैं, और यह लेख उन्हें वैसे ही मानता है।
जैसा कि बताया गया, तंत्र वह हिस्सा है जो सामान्यीकृत होता है। कवरेज में उद्धृत शोधकर्ताओं ने दुर्भावनापूर्ण कोड को एक वेबसाइट-प्रदर्शन विक्रेता की वास्तविक-उपयोगकर्ता निगरानी (RUM) स्क्रिप्ट से जोड़ा — एक छोटी फ़ाइल जिसका पूरा काम आगंतुकों के ब्राउज़रों में पेज-लोड गति मापना है, जो विक्रेता के CDN से प्रति-ग्राहक एम्बेड की जाती है। जैसा कि बताया गया, वह फ़ाइल लक्ष्य साइट के लिए विशेष रूप से लिखे गए पेलोड से बदल दी गई: वह लॉग-इन सत्रों के भीतर काम करता था, पेज में पहले से मौजूद साइट की अपनी ट्रेडिंग मशीनरी का उपयोग करता था, और पोज़िशन व धन को हमलावर-नियंत्रित गंतव्य पर ले जाता था। जैसा कि बताया गया, कोई स्मार्ट-कॉन्ट्रैक्ट खामी और कोई चुराया गया पासवर्ड या निजी कुंजी शामिल नहीं थी — बदली गई स्क्रिप्ट, ब्राउज़र के हिसाब से, बस पेज ही थी। उस विवरण की हर बारीकी बाद की जाँच में टिकेगी या नहीं, सबक़ के लिए, मुख्य बात से परे है: हमले का आकार — एक विक्रेता फ़ाइल, एक बार बदली गई, हर आगंतुक द्वारा चलाई गई — इस वर्ग की घटनाओं का मानक आकार है।
थर्ड-पार्टी स्क्रिप्ट आपका कोड है, बस रिलीज़ प्रक्रिया किसी और की है
क्लासिक script टैग में कोई सैंडबॉक्स नहीं होता। विक्रेता के CDN से लोड किया गया कोड आपके ऑरिजिन में आपके अपने बंडल जैसी ही पहुँच के साथ चलता है: वह DOM पढ़ और बदल सकता है, टाइप होते समय फ़ॉर्म मान पढ़ सकता है, उपयोगकर्ता के सत्र से आपके API बुला सकता है, और जो मिले उसे कहीं भी भेज सकता है। थर्ड-पार्टी JavaScript पर OWASP मार्गदर्शन तीन जोखिमों को स्पष्ट नाम देता है — क्लाइंट एप्लिकेशन में बदलावों पर नियंत्रण की हानि, क्लाइंट सिस्टमों पर मनमाना कोड चलना, और थर्ड पार्टियों को संवेदनशील जानकारी का खुलासा — और तीनों उसी एक तथ्य से निकलते हैं। आपकी समीक्षा प्रक्रिया, आपका कोड फ़्रीज़ और आपकी परिवर्तन समिति आपके अपने बिल्ड पर खत्म होती है; विक्रेता की फ़ाइल को विक्रेता संपादित कर सकता है, विक्रेता से समझौता करने वाला हमलावर संपादित कर सकता है, या वह व्यक्ति संपादित कर सकता है जो विक्रेता के डोमेन के कभी समाप्त होने पर उसे फिर से पंजीकृत करे।
वही असममिति इसका कारण है कि "हम इस विक्रेता पर भरोसा करते हैं" कोई नियंत्रण नहीं है। भरोसा तय करता है कि आज आप किसकी स्क्रिप्ट स्वीकार करते हैं; वह इस बारे में कुछ नहीं कहता कि वह URL कल क्या देगा, और सामग्री बदलने पर वह आपको कोई संकेत नहीं देता। जो नियंत्रण काम करते हैं वे वे हैं जो या तो भरोसे को हटाते हैं (फ़ाइल खुद दें), उसे सीमित करते हैं (एक Content-Security-Policy जो सीमित करे कि कोई भी स्क्रिप्ट क्या कर सकती है और डेटा कहाँ भेज सकती है), या हर लोड पर उसे यांत्रिक रूप से सत्यापित करते हैं — SRI इसी के लिए है। सूची से शुरू करें: आप उन स्क्रिप्ट पर तीनों में से कोई भी लागू नहीं कर सकते जिनके होने का आपको पता ही नहीं, और अधिकांश साइटों के पास, मार्केटिंग टैग, समर्थन विजेट और निगरानी एम्बेड गिनने के बाद, उनके मालिकों की अपेक्षा से ज़्यादा स्क्रिप्ट होती हैं।
SRI क्या रोकता है — और क्या नहीं रोकता
Subresource Integrity एक ब्राउज़र तंत्र है, W3C द्वारा निर्दिष्ट और MDN द्वारा प्रलेखित: पेज टैग की integrity विशेषता में उस फ़ाइल का क्रिप्टोग्राफ़िक हैश घोषित करता है जिसकी वह अपेक्षा करता है, ब्राउज़र वास्तव में डाउनलोड की गई चीज़ का हैश बनाता है, और किसी भी बेमेल पर फ़ाइल चलाने से मना कर देता है। क्रॉस-ऑरिजिन फ़ाइल के लिए टैग को crossorigin="anonymous" भी चाहिए और सर्वर को CORS हेडर भेजने होंगे, ताकि ब्राउज़र को जाँच करने की अनुमति मिले। एक निश्चित लाइब्रेरी पर लागू होने पर, SRI एक चुपचाप अदला-बदली को ज़ोरदार विफलता में बदल देता है: आने वाली फ़ाइल या तो बाइट-दर-बाइट वही फ़ाइल है जिसकी आपने समीक्षा की थी, या वह बिल्कुल नहीं चलती। यदि बताई गई घटना की निगरानी स्क्रिप्ट उस तरह लोड की गई एक निश्चित फ़ाइल होती, तो बदला गया पेलोड उपयोगकर्ताओं के सत्रों में चलने के बजाय जाँच में विफल होता — वह सशर्त रूप दावे का ईमानदार रूप है, क्योंकि वह विशेष एम्बेड हैश-योग्य था या नहीं, यह एक गतिशील प्रति-ग्राहक फ़ाइल के बारे में प्रश्न है, जो ठीक नीचे वाला कठिन मामला है।
SRI क्या नहीं रोकता, वह भी उतना ही महत्वपूर्ण है। वह उन स्क्रिप्ट के लिए मदद नहीं करता जिनकी सामग्री बदलनी ही होती है — टैग-मैनेजर कंटेनर, वैयक्तिकरण और सहमति लोडर, प्रति-ग्राहक बनाई गई फ़ाइलें — क्योंकि पिन करने के लिए कोई स्थिर हैश नहीं होता। वह उस फ़ाइल का न्याय नहीं करता जिसका आपने हैश लिया: वफ़ादारी से दी गई स्क्रिप्ट भी डिज़ाइन से जिज्ञासु, लापरवाह या दुर्भावनापूर्ण हो सकती है, और SRI हमेशा खुशी से उसे सत्यापित करेगा। वह अन्य स्क्रिप्ट द्वारा रनटाइम पर डाली गई स्क्रिप्ट को कवर नहीं करता, आपके अपने बुनियादी ढाँचे से दी गई फ़र्स्ट-पार्टी फ़ाइलों की रक्षा नहीं करता, और एक वैध स्क्रिप्ट के चलने के बाद इकट्ठा किए गए डेटा के बारे में कुछ नहीं करता। SRI एक यांत्रिक गारंटी है — ठीक यही बाइट्स, या कुछ नहीं — और वह CSP, विक्रेता समीक्षा, और शुरू से ही कितनी थर्ड पार्टियों को सत्र-स्तरीय पहुँच मिलती है उसे न्यूनतम करने के साथ-साथ, उनके स्थान पर नहीं, अपना स्थान कमाता है। इस साइट की सुरक्षा हेडर जाँच उस जोड़ी के CSP पक्ष को ग्रेड देती है।
संस्करण पिन करें, वरना हैश टिक नहीं सकता
SRI की एक पूर्व-शर्त है जिस पर दुर्भावना से ज़्यादा ऑडिट विफल होते हैं: URL को हमेशा वही बाइट्स लौटाने होंगे। latest पते, तैरते मेजर संस्करण, या विक्रेता द्वारा फिर से बनाई जाने वाली प्रति-ग्राहक फ़ाइल पर पिन किया गया हैश वह हैश है जो विक्रेता के पहला अपडेट भेजते ही टूट जाता है — और जिन टीमों को स्वयं-लगाई SRI विफलता ने एक बार जगाया है, वे पते को ठीक करने के बजाय विशेषता को हटाने की ओर झुकती हैं, पेज को अमापे से भी बदतर छोड़कर। टिकाऊ क्रम उल्टा है: पहले URL को ठीक-ठीक संस्करण का नाम लेने वाला बनाएँ ([email protected], /v2.4.0/), उस संस्करण की एक बार समीक्षा करें, फिर ठीक उसी फ़ाइल का हैश लें। संस्करण बढ़ाना तब सोच-समझकर किए गए कार्यक्रम बन जाते हैं — नया URL, नया हैश, एक कमिट — बजाय परिवेशी बदलावों के जिन्हें आप अपने उपयोगकर्ताओं से खोजते हैं।
पिन करने की एक कीमत है, और ईमानदारी उसे नाम देना माँगती है: पिन की गई लाइब्रेरी को विक्रेता से चुपचाप सुरक्षा पैच नहीं मिलते, इसलिए पिन करना रिलीज़ों पर नज़र रखने और सोच-समझकर बढ़ाने का कर्तव्य बनाता है, वही कर्तव्य जो कोई भी वेंडर की गई निर्भरता वहन करती है। यह एक प्रबंधनीय कर्तव्य है — रिलीज़ नोट और कैलेंडर रिमाइंडर इसे कवर करते हैं — और यह उस विकल्प से कड़ाई से बेहतर है जिसे यह बदलता है, जिसमें अपडेट विक्रेता की गति से बिना समीक्षा आएँ और टूट-फूट आपकी गति से बिना घोषणा आए। इस जोड़ी को एक ही अभ्यास मानें: पिन करना सामग्री को संबोधित-योग्य बनाता है, हैश उसे सत्यापन-योग्य बनाता है, और ऑडिट सुनिश्चित करता है कि दोनों में से कोई चुपचाप सड़ा नहीं है — CMS माइग्रेशन द्वारा संपादित करके हटाई गई संस्करण स्ट्रिंग उतनी ही आम है जितना गायब हैश, और आँख से नोटिस करना बस थोड़ा कठिन है।
स्वयं-होस्टिंग, और ऑडिट दिनचर्या
जो स्क्रिप्ट सबसे ज़्यादा मायने रखती हैं, उनके लिए एक भोंडा विकल्प है: फ़ाइल खुद दें। स्वयं-होस्टिंग विक्रेता के सर्वर, खाते और डोमेन को आपके रनटाइम आपूर्ति-शृंखला से पूरी तरह हटा देता है, आपकी सामान्य परिनियोजन पाइपलाइन को फ़ाइल की समीक्षा और हैश करने देता है, और विक्रेता के CDN के न चलने पर भी चलता रहता है। समझौते असली हैं — आप विक्रेता के एज कैश और स्वचालित अपडेट छोड़ देते हैं, उसके सुरक्षा सुधार खुद भेजने का कर्तव्य लेते हैं, और कुछ विक्रेताओं के लाइसेंस या उनकी प्रति-ग्राहक बनाई फ़ाइलें बस इसकी अनुमति नहीं देतीं — इसलिए समझदारी भरा विभाजन गंभीरता के हिसाब से है: संवेदनशील पेजों पर छोटी, निश्चित लाइब्रेरियों को स्वयं-होस्ट करें; जो CDN पर रहे उसे पिन और हैश करें; गतिशील टैगों को, जिन्हें न पिन किया जा सकता है न होस्ट, शासन (प्रकाशन प्रतिबंध, बदलाव समीक्षा और CSP) से चलाएँ; और देखते ही हर उस स्क्रिप्ट को हटाएँ जिसका कोई औचित्य न दे सके। हटाई गई हर स्क्रिप्ट एक आपूर्ति-शृंखला है जो अब आपके पास नहीं है।
जो दिनचर्या इसे सच रखती है वह इतनी छोटी है कि वास्तव में चलाई जा सके। त्रैमासिक — और हर पुनःडिज़ाइन, CMS माइग्रेशन या नए विक्रेता के बाद — अपने मुख्य पेज टेम्पलेटों पर थर्ड-पार्टी स्क्रिप्ट और SRI ऑडिट चलाएँ: वह स्टैटिक HTML द्वारा संदर्भित हर स्क्रिप्ट की सूची बनाता है, कौन-सी थर्ड-पार्टी हैं, किनमें इंटीग्रिटी नहीं है, और कौन-सी पिन नहीं हैं, और जिन पहले गायब हैशों को वह ला सकता है उनके लिए चिपकाने-योग्य sha384 गिनता है। प्रभाव के क्रम में ठीक करें — सत्र, भुगतान और व्यक्तिगत-डेटा पेज पहले — फिर SSL ग्रेडर और हेडर जाँच से परिवहन और हेडर परतों की जाँच करें, और टैग मैनेजर में समाप्त करें, जहाँ रनटाइम पर डाली गई स्क्रिप्ट स्टैटिक ऑडिट नहीं देख सकती: उसकी प्रकाशक सूची और बदलाव इतिहास की उसी संदेह से समीक्षा करें जो आप किसी परिनियोजन लॉग को देते। हर तिमाही पंद्रह मिनट, एक ऐसी घटना-वर्ग के सामने जिसकी बताई गई कीमत, ऊपर के मामले में, लगभग एक घंटे में लाखों तक पहुँच गई।