थर्ड-पार्टी स्क्रिप्ट और SRI ऑडिट
आपके पेज द्वारा लोड की जाने वाली हर थर्ड-पार्टी स्क्रिप्ट आपके पेज के पूरे विशेषाधिकारों के साथ चलती है — वह DOM पढ़ सकती है, फ़ॉर्म इनपुट देख सकती है और आपके आगंतुकों के सत्रों के भीतर काम कर सकती है। यह ऑडिट किसी पेज का स्टैटिक HTML लाता है, उसके द्वारा संदर्भित हर बाहरी स्क्रिप्ट की सूची बनाता है, चिह्नित करता है कि कौन-सी थर्ड-पार्टी हैं, किनमें Subresource Integrity (SRI) हैश है, और कौन-सी किसी ठीक-ठीक संस्करण पर पिन की गई हैं — और इंटीग्रिटी से वंचित थर्ड-पार्टी स्क्रिप्ट के लिए sha384 हैश गिनता है ताकि आप उसे सीधे टैग में चिपका सकें।
अंतिम अपडेट:
चिंता है कि आपकी साइट पर कोई विक्रेता स्क्रिप्ट बदल जाए या बंद हो जाए? myeventwatch से मुफ़्त निगरानी करें — समाप्ति और डाउनटाइम अलर्ट, कार्ड की ज़रूरत नहीं।
यह ऑडिट क्या जाँचता है — और क्या नहीं देख सकता
चेकर पेज को एक बार लाता है और उसे दिए गए HTML को पार्स करता है — केवल स्टैटिक HTML। उस मार्कअप का हर <script src> अपने होस्ट के साथ सूचीबद्ध होता है, जब होस्ट आपके पेज के रजिस्टर-योग्य डोमेन से मेल खाए तो फ़र्स्ट-पार्टी और न खाए तो थर्ड-पार्टी वर्गीकृत होता है, और उन दो विशेषताओं पर जाँचा जाता है जो तय करती हैं कि ब्राउज़र आपकी रक्षा कर सकता है या नहीं: integrity, वह SRI हैश जिसे ब्राउज़र फ़ाइल चलाने से पहले सत्यापित करता है, और crossorigin, जिसकी ज़रूरत क्रॉस-ऑरिजिन SRI जाँच को काम करने के लिए होती है। URL में संस्करण का भी मूल्यांकन होता है: [email protected] या /v2.4/ के रूप में संबोधित स्क्रिप्ट पिन की गई है, जबकि latest या बिना-संस्करण वाला पता एक चलता निशाना है जिसकी सामग्री किसी भी क्षण बदल सकती है, बिना कोई आपकी साइट को छुए।
सीमा को स्पष्ट समझें, क्योंकि यह मायने रखती है: v1 केवल पेज के स्टैटिक HTML को पार्स करता है — JavaScript द्वारा रनटाइम पर डाली गई स्क्रिप्ट इसके दायरे में नहीं हैं। टैग मैनेजर, सहमति उपकरण और चैट विजेट अक्सर पेज लोड होने के बाद कोड से script एलिमेंट बनाते हैं, और स्टैटिक पार्स उन्हें कभी नहीं देखता। इस ऑडिट को अपने टेम्पलेट और CMS द्वारा सीधे संदर्भित चीज़ों की सूची मानें — आम तौर पर समस्या का सबसे बड़ा और सबसे ठीक करने योग्य हिस्सा — और टैग-मैनेजर कंटेनरों का ऑडिट अलग से, मैनेजर के अपने पूर्वावलोकन और परिवर्तन इतिहास में करें। इनलाइन स्क्रिप्ट (जिन ब्लॉकों में src नहीं है) परिणाम में एक तथ्य के रूप में गिनी जाती हैं, क्योंकि वे SRI रख ही नहीं सकतीं; साथी मार्गदर्शिका बताती है कि उनके बारे में क्या करें।
हैश कॉलम: गिना गया, कभी अंदाज़ा नहीं
integrity विशेषता से वंचित थर्ड-पार्टी स्क्रिप्ट के लिए, चेकर स्क्रिप्ट को खुद लाता है — इस साइट के हर दूसरे चेकर की ही तरह SSRF-सुरक्षित लाने के रास्ते से, ऐसी पहली 15 स्क्रिप्ट तक सीमित और हर एक 512 KB तक — और उसका SHA-384 हैश गिनता है। जब लाना सफल होता है, SRI सेल पूरा स्निपेट दिखाता है, integrity="sha384-…", जो crossorigin="anonymous" के साथ आपके टैग में चिपकाने के लिए तैयार है। हैश तभी दिखाया जाता है जब स्क्रिप्ट वास्तव में लाई गई हो। यदि लाना विफल हुआ, फ़ाइल बहुत बड़ी थी, या स्क्रिप्ट 15 की सीमा से आगे थी, तो सेल इसके बजाय वह टिप्पणी दिखाता है — कभी कोई प्लेसहोल्डर या अंदाज़ा मूल्य नहीं — और उपाय यह है कि हैश अपने खुद के बिल्ड पाइपलाइन में बनाएँ, जहाँ ठीक-ठीक फ़ाइल हाथ में है।
संबंधित जाँचें: सुरक्षा हेडर जाँच प्रतिक्रिया हेडरों को ग्रेड देती है — SRI की स्वाभाविक साथी Content-Security-Policy समेत —, SSL ग्रेडर उस परिवहन को कवर करता है जिससे ये स्क्रिप्ट आती हैं, और साथी लेख थर्ड-पार्टी स्क्रिप्ट एक आपूर्ति-शृंखला जोखिम है एक असली घटना, SRI क्या रोकता है और क्या नहीं, और दोहराई जा सकने वाली ऑडिट दिनचर्या से गुज़रता है।
निष्कर्षों को कैसे पढ़ा जाए: इंटीग्रिटी वाली और पिन किए गए संस्करण वाली थर्ड-पार्टी स्क्रिप्ट स्वस्थ स्थिति है — ब्राउज़र बदली गई या संपादित फ़ाइल को मना कर देगा। इंटीग्रिटी रहित थर्ड-पार्टी स्क्रिप्ट अपने-आप दुर्भावनापूर्ण नहीं है; वह असुरक्षित है, जिसका अर्थ है कि उसकी सामग्री वही है जो उसका होस्ट आज दे रहा है, और किसी बदलाव की आपकी एकमात्र चेतावनी नुकसान खुद होगा। बिना पिन किए पते उसी संदेह के हक़दार हैं जो गायब हैश के हैं, क्योंकि latest URL पर SRI हैश विक्रेता के पहले अपडेट भेजते ही टूट जाता है — इसीलिए दोनों निष्कर्ष साथ-साथ रिपोर्ट किए जाते हैं, और इसीलिए टिकाऊ उपाय हमेशा जोड़ी है: पहले ठीक-ठीक संस्करण पिन करें, फिर ठीक उसी फ़ाइल का हैश लें।
इस पेज द्वारा दिखाए जाने वाले तथ्य
| थर्ड-पार्टी | ऐसी स्क्रिप्ट जिसका होस्ट का रजिस्टर-योग्य डोमेन पेज के डोमेन से अलग है — किसी और द्वारा दी गई कोड, जो आपके पेज के विशेषाधिकारों से चलती है। |
| इंटीग्रिटी (SRI) | टैग में integrity विशेषता है या नहीं: एक क्रिप्टोग्राफ़िक हैश जिसे ब्राउज़र फ़ाइल चलाने से पहले जाँचता है, किसी भी बेमेल पर उसे मना कर देता है। |
| Crossorigin | टैग में वह crossorigin विशेषता है या नहीं जिसकी ज़रूरत क्रॉस-ऑरिजिन SRI जाँच को होती है; इसके बिना ब्राउज़र लोड पर SRI लागू नहीं कर सकते। |
| पिन किया गया | URL किसी ठीक-ठीक संस्करण ([email protected], /v2.4/) का नाम लेता है या नहीं, बजाय तैरते latest या बिना-संस्करण पते के जिसकी सामग्री चुपचाप बदल सकती है। |
| गिना गया SRI | इंटीग्रिटी से वंचित थर्ड-पार्टी स्क्रिप्ट के लिए, फ़ाइल को वास्तव में लाकर चेकर द्वारा गिना गया sha384 हैश — केवल सफल लाने पर, ऐसी पहली 15 स्क्रिप्ट के लिए दिखाया जाता है। |
अक्सर पूछे जाने वाले प्रश्न
क्या यह ऑडिट मेरे पेज द्वारा चलाई जाने वाली हर स्क्रिप्ट को देखता है?
नहीं — और पेज यह स्पष्ट कहता है: v1 केवल पेज के स्टैटिक HTML को पार्स करता है, इसलिए JavaScript द्वारा रनटाइम पर डाली गई स्क्रिप्ट इसके दायरे में नहीं हैं। टैग मैनेजर, A/B परीक्षण उपकरण, सहमति बैनर और चैट विजेट आम तौर पर लोड के बाद स्क्रिप्ट डालते हैं; उनका ऑडिट टैग मैनेजर में या ब्राउज़र के नेटवर्क पैनल से करें। यह ऑडिट पूरी तरह कवर करता है आपके दिए गए HTML द्वारा सीधे संदर्भित हर स्क्रिप्ट को, जो वही जगह है जहाँ लाइब्रेरी, CDN विजेट और निगरानी एम्बेड रहते हैं।
SRI कॉलम का हैश कहाँ से आता है?
चेकर स्क्रिप्ट फ़ाइल को खुद लाता है और उसका SHA-384 हैश गिनता है, integrity विशेषता से वंचित थर्ड-पार्टी स्क्रिप्ट के लिए — पहली 15, हर एक 512 KB तक। हैश तभी दिखाया जाता है जब स्क्रिप्ट वास्तव में लाई गई हो: यदि लाना विफल हुआ, फ़ाइल बहुत बड़ी थी, या सीमा तक पहुँच गए, तो सेल हैश के बजाय वह टिप्पणी दिखाता है। स्निपेट को crossorigin="anonymous" के साथ अपने script टैग में चिपकाएँ और हर संस्करण बदलाव के बाद ऑडिट फिर चलाएँ — नया संस्करण मतलब नया हैश।
मेरी टैग मैनेजर स्क्रिप्ट का कोई निश्चित हैश नहीं हो सकता। तब क्या?
सही — टैग-मैनेजर कंटेनर बदलने के लिए ही बना है, इसलिए SRI उसे पिन नहीं कर सकता, और यही बात हर उस स्क्रिप्ट पर लागू होती है जिसका पूरा उद्देश्य बदलती कोड लोड करना है। उनके लिए नियंत्रण दूसरे हैं: कंटेनर में कौन प्रकाशित कर सकता है इसे सीमित करें, उसके परिवर्तन इतिहास की कोड बदलावों की तरह समीक्षा करें, उसे केवल उन्हीं पेजों पर लोड करें जिन्हें उसकी ज़रूरत है, और Content-Security-Policy का उपयोग करके सीमित करें कि डाली गई स्क्रिप्ट क्या कर सकती हैं और डेटा कहाँ भेज सकती हैं। SRI निश्चित लाइब्रेरियों की रक्षा करता है; शासन गतिशील वालों की।
क्या integrity विशेषता का न होना आपात स्थिति है?
यह एक स्थायी जोखिम-खुलापन है, कोई घटना नहीं। स्क्रिप्ट लगभग निश्चित रूप से वही फ़ाइल है जो विक्रेता आज देना चाहता है; समस्या यह है कि कल कोई दूसरी फ़ाइल — विक्रेता के समझौते, अपहृत खाते या समाप्त डोमेन के बाद — आने पर कुछ भी उसे न रोकेगा, न चिह्नित करेगा। ठीक करने का क्रम: पहले लॉगिन, भुगतान या व्यक्तिगत डेटा वाले पेजों की स्क्रिप्ट, फिर हर दूसरी जगह पिन और हैश की गई लाइब्रेरी, फिर लंबी पूंछ। संस्करण पिन हो जाने के बाद हर उपाय टैग में एक-पंक्ति का बदलाव है।
पिन कॉलम किसी स्क्रिप्ट को "latest" या "बिना-संस्करण" क्यों कहता है?
पिन निष्कर्ष URL की एक अनुमान-आधारित पढ़त है: @1.2.3 या /v2.4/ जैसा संस्करण-जैसा खंड पिन किया गया गिना जाता है, स्पष्ट latest खंड तैरता गिना जाता है, और कहीं भी संस्करण न रखने वाला URL बिना-संस्करण गिना जाता है। इसे अनुमान-आधारित इसलिए कहा गया है क्योंकि केवल विक्रेता अपनी रिलीज़ योजना जानता है — लेकिन सुरक्षा का मुद्दा इस लेबल पर निर्भर नहीं है: यदि उस URL पर बाइट्स बिना URL बदले बदल सकते हैं, तो SRI हैश जीवित नहीं रह सकता, इसलिए पहले पिन करें, फिर हैश लें।