मिक्स्ड कंटेंट तब बनता है जब सुरक्षित तरीके से लोड हुआ पेज असुरक्षित कनेक्शन से मांगे गए संसाधन इस्तेमाल करता है। Screpy का मिक्स्ड कंटेंट चेकर एक सार्वजनिक HTTPS पेज के स्रोत HTML में HTTP संसाधन संदर्भ ढूंढता है और उनकी श्रेणी, पता, पहली स्रोत पंक्ति व दोहराव की संख्या दिखाता है। इन जानकारियों से बदलाव वाली सामग्री या टेमप्लेट ढूंढकर सुरक्षित विकल्प तैयार कर सकते हैं।
रिपोर्ट पेज नहीं चलाती और सूचीबद्ध संसाधन नहीं मंगाती। यह जांचने योग्य स्रोत संदर्भ पहचानती है, यह रिकॉर्ड नहीं करती कि किसी विज़िटर के ब्राउज़र ने वास्तव में क्या लोड किया, HTTPS में बदला या ब्लॉक किया। सफल जांच पूरी वेबसाइट की सुरक्षा का प्रमाणपत्र भी नहीं है।
संदर्भ रखने वाले HTTPS पेज की जांच करें
जिस पेज को देखना है उसका पूरा सार्वजनिक पता दें। किसी लेख के लिए होमपेज या संदिग्ध चित्र के बजाय लेख का अपना URL भेजें, जैसे उदाहरण का https://example.com/guides/setup/। टूल दिए गए एक पेज की जांच करता है; डोमेन के सभी पेज नहीं खोजता।
इनपुट के लिए HTTPS ज़रूरी है। जांच के बाद अंतिम URL पढ़ें, क्योंकि रीडायरेक्ट जांचे जा रहे पेज को बदल सकते हैं। HTTPS पता अंत में HTTP पर पहुंचे तो HTTPS मिक्स्ड कंटेंट विश्लेषण लागू नहीं होता। यह समस्यामुक्त नतीजा नहीं है। अनपेक्षित गंतव्य समझने के लिए Redirect Checker इस्तेमाल करें।
पेज को पढ़ने योग्य सार्वजनिक HTML देना चाहिए। लॉगिन स्क्रीन के संदर्भ उसके पीछे के निजी पेज से अलग हो सकते हैं। अनुपलब्ध रिस्पॉन्स, असमर्थित दस्तावेज़ या विफल अनुरोध का मतलब मांगी गई जांच अधूरी है; इससे असुरक्षित संदर्भ न होने का प्रमाण नहीं मिलता।
ब्लॉक होने योग्य संसाधन, अपग्रेड विकल्प और फ़ॉर्म लक्ष्य समझें
टेबल सीमित करने के लिए श्रेणी फ़िल्टर इस्तेमाल करें, फिर हर पते के पास का एलिमेंट और एट्रिब्यूट देखें। श्रेणियां बताती हैं कि चेकर समर्थित HTTP संदर्भों को कैसे समूहित करता है; ये ब्राउज़र में देखे गए परिणाम नहीं हैं।
| श्रेणी | इस रिपोर्ट के उदाहरण | क्या जांचें |
|---|---|---|
| ब्लॉक होने योग्य, लाल | स्क्रिप्ट, स्टाइलशीट, फ़्रेम और रिस्पॉन्सिव चित्रों के srcset विकल्प |
स्रोत ढूंढें और उपयुक्त HTTPS विकल्प की पुष्टि करें। |
| अपग्रेड संभव, पीला | समर्थित चित्र, ऑडियो और वीडियो स्रोत संदर्भ | देखें कि इच्छित संसाधन HTTPS पर सचमुच काम करता है; अपने आप अपग्रेड होना उपलब्धता का प्रमाण नहीं है। |
| असुरक्षित फ़ॉर्म लक्ष्य, नारंगी | फ़ॉर्म का action या बटन/input का formaction |
फ़ॉर्म बदलने से पहले इच्छित सुरक्षित सबमिशन पते की पुष्टि करें। |
चेकर ऑब्जेक्ट, इमेज इनपुट, वीडियो पोस्टर और कुछ link संबंधों के समर्थित संसाधन संदर्भ भी देखता है। जिन चित्र या मीडिया URL का होस्ट IP पता है, उन्हें अपग्रेड विकल्प के बजाय ब्लॉक होने योग्य श्रेणी में रखा जाता है।
मिक्स्ड कंटेंट के वर्तमान निर्देश अपग्रेड होने योग्य और ब्लॉक होने योग्य अनुरोध अलग बताते हैं। वास्तविक व्यवहार ब्राउज़र के नियमों और सुरक्षा नीतियों पर भी निर्भर है। स्रोत का यह वर्गीकरण हर अपवाद नहीं जांचता, जिसमें संभावित रूप से विश्वसनीय स्थानीय पते भी हैं। हर लाल पंक्ति को इस बात का प्रमाण न मानें कि किसी खास ब्राउज़र ने अनुरोध ब्लॉक किया।
फ़ॉर्म लक्ष्य अलग समीक्षा श्रेणी हैं। मिक्स्ड कंटेंट विनिर्देश का फ़ॉर्म सबमिशन भाग ब्राउज़र चेतावनियों को सामान्य संसाधन जांच से अलग बताता है। Screpy इन फ़ॉर्म को भेजता नहीं और यह तय नहीं करता कि वे क्या जानकारी जुटाते हैं। बिना जांचे पते पर संवेदनशील टेस्ट डेटा भेजे बिना असली फ़ॉर्म का उद्देश्य देखें।
समूहित नतीजों से स्रोत तक पहुंचें
टेबल एक जैसे एलिमेंट, एट्रिब्यूट, वर्गीकरण और रिज़ॉल्व किए URL वाले दोहराव जोड़ती है। वही पता किसी दूसरे एलिमेंट या एट्रिब्यूट में अलग पंक्ति बना सकता है। दिखाई गई पंक्ति प्राप्त HTML में समूह का पहला उदाहरण है, ज़रूरी नहीं कि वह आपके टेमप्लेट एडिटर की पंक्ति हो।
इस काल्पनिक हिस्से में चार HTTP संदर्भ हैं:
<script src="http://static.example.com/site.js"></script>
<img src="http://static.example.com/logo.png" alt="Example homepage">
<img src="http://static.example.com/logo.png" alt="Example homepage">
<form action="http://example.com/contact/" method="post"></form>
| समूह | बार दिखाई देना | वर्गीकरण |
|---|---|---|
/site.js पर खत्म होने वाला script[src] |
1 | ब्लॉक होने योग्य |
/logo.png पर खत्म होने वाला img[src] |
2 | अपग्रेड संभव |
/contact/ पर खत्म होने वाला form[action] |
1 | असुरक्षित फ़ॉर्म लक्ष्य |
सारांश में एक ब्लॉक होने योग्य संदर्भ, दो अपग्रेड विकल्प और एक फ़ॉर्म संदर्भ गिना जाता है: तीन पंक्तियों में चार बार मौजूद होना। इसका मतलब चार अलग फ़ाइलें या चार पुष्ट नेटवर्क अनुरोध नहीं है। उदाहरण रिपोर्ट के समूह समझाता है, यह लाइव स्कैन या पूरा काम करने वाला संपर्क फ़ॉर्म नहीं है।
ज़िम्मेदार सामग्री या साझा कंपोनेंट में दोहराए गए संदर्भ का हर उदाहरण ढूंढें। केवल पहली दिखाई पंक्ति ठीक करने से दूसरा उदाहरण बिना बदले रह सकता है। कौन सा CMS फ़ील्ड, थीम सेटिंग या टेमप्लेट इसे बनाता है, यह तय करने से पहले उस पंक्ति के आसपास का वास्तविक स्रोत पढ़ें।
रिलेटिव पाथ बदलने से पहले बेस URL देखें
दिखाया गया संसाधन URL दस्तावेज़ के प्रभावी बेस के अनुसार रिज़ॉल्व होता है। अपना बेस न होने पर रिलेटिव पाथ अंतिम पेज URL इस्तेमाल करते हैं। HTTP वाला <base href> इसके विपरीत रिलेटिव संदर्भ को HTTP बना सकता है, भले पेज HTTPS से प्राप्त हुआ हो।
काल्पनिक https://example.com/guides/setup/ पेज के लिए यह हिस्सा देखें:
<head><base href="http://static.example.com/assets/"></head>
<body><img src="logo.png" alt="Example homepage"></body>
चित्र HTTPS पेज के फ़ोल्डर में किसी फ़ाइल के बजाय http://static.example.com/assets/logo.png बनता है। //static.example.com/assets/logo.png जैसा प्रोटोकॉल-रिलेटिव संदर्भ भी बेस की स्कीम इस्तेमाल करता है। इसलिए सिर्फ http: हटाने से सुरक्षित गंतव्य तय नहीं हो जाता।
HTML base का संदर्भ बताता है कि पहला लागू बेस रिलेटिव URL कैसे नियंत्रित करता है। बेस और फ़ाइल की इच्छित जगह साथ जांचें। इसे बदलने से दूसरे संसाधन, नेविगेशन और फ़ॉर्म लक्ष्य प्रभावित हो सकते हैं; असर देखे बिना जानबूझकर रखा बेस न हटाएं। स्पष्ट और काम करने वाला HTTPS संसाधन पता इच्छित बदलाव समझना आसान कर सकता है।
असुरक्षित संदर्भ को काम करने वाले HTTPS पते से बदलें
जहां संदर्भ बनता है वहीं से शुरू करें। पुराना चित्र URL लेख के फ़ील्ड, लोगो की सेटिंग या साझा टेमप्लेट में हो सकता है; एम्बेडेड स्क्रिप्ट किसी इंटीग्रेशन के दिए कोड से आ सकती है। अगले प्रकाशन में दोबारा लिखे जाने वाले तैयार HTML के बजाय उस स्रोत को सुधारें। पूरी वेबसाइट में असंबंधित http:// टेक्स्ट को अंधाधुंध बदलने से बचें।
प्रस्तावित HTTPS गंतव्य इस्तेमाल करने से पहले जांचें। उसे अनपेक्षित रीडायरेक्ट, पहुंच की स्क्रीन या अलग सामग्री के बजाय इच्छित चित्र, स्क्रिप्ट या दूसरा संसाधन देना चाहिए। इस चेकर ने वह अनुरोध नहीं किया है। अगर होस्ट वही फ़ाइल सुरक्षित रूप से नहीं देता, तो http://static.example.com/site.js को HTTPS में बदलना विफल हो सकता है।
किसी बाहरी निर्भरता का उपयुक्त सुरक्षित संस्करण नहीं है तो समर्थित विकल्प मांगें या तय करें कि सुविधा हटानी या बदलनी चाहिए। केवल नतीजा हटाने के लिए चुपचाप असंबंधित फ़ाइल न लगाएं। फ़ॉर्म में केवल पते की वर्तनी नहीं, प्राप्त करने वाला एंडपॉइंट और अपेक्षित व्यवहार जांचें।
upgrade-insecure-requests वाली Content Security Policy स्रोत में HTTP संदर्भ रखते हुए ब्राउज़र के अनुरोध बदल सकती है। डायरेक्टिव के दस्तावेज़ के अनुसार अनुपलब्ध HTTPS संसाधन HTTP पर लौटे बिना विफल हो सकता है। यह हर अपग्रेड किए संसाधन के काम करने का प्रमाण नहीं है। घोषित रिस्पॉन्स हेडर अलग देखने के लिए HTTP Headers Checker इस्तेमाल करें; मौजूदा नीति बिना समझे न बदलें और समस्या छिपाने के लिए ब्राउज़र सुरक्षा बंद न करें।
प्रकाशित स्रोत और ब्राउज़र अनुरोध दोनों सत्यापित करें
बदलाव से पहले मूल रिपोर्ट और इच्छित विकल्प साथ रखें। JSON डाउनलोड में रखे गए नतीजे और समूह रहते हैं; श्रेणी चुनने से टेबल बदलती है, पूरा रिपोर्ट डाउनलोड नहीं। इस टूल में CSV निर्यात या अपने आप सुधारने की सुविधा नहीं है।
- सही की गई सामग्री, सेटिंग या टेमप्लेट प्रकाशित करें और अपडेटेड रिस्पॉन्स उपलब्ध होने पर उसी HTTPS पेज को फिर जांचें।
- संबंधित URL, एलिमेंट, एट्रिब्यूट और दोहराव की संख्या की तुलना करें। कम कुल संख्या दूसरा बचा हुआ संदर्भ छिपा सकती है; सिर्फ सारांश नहीं, पंक्तियां देखें।
- पेज ब्राउज़र में खोलकर डेवलपर कंसोल की चेतावनियां और नेटवर्क अनुरोध देखें। संबंधित चित्र, मीडिया या सुविधा आज़माएं; स्रोत रिपोर्ट ये इंटरैक्शन नहीं चलाती।
- वही बदला टेमप्लेट इस्तेमाल करने वाले दूसरे पेज भी जांचें। होमपेज ठीक होने से हर उत्पाद या लेख ठीक होना साबित नहीं होता।
Chrome के सुरक्षा पैनल की गाइड बताती है कि असुरक्षित origin से संबंधित नेटवर्क अनुरोध तक कैसे जाएं। ब्राउज़र के अवलोकन उन स्क्रिप्ट या स्टाइल के बनाए अनुरोध दिखा सकते हैं जिन्हें यह केवल स्रोत देखने वाला टूल नहीं जांचता। मूल कोड में HTTP होने पर भी अपग्रेड या ब्लॉक हुआ अनुरोध दिख सकता है।
इन अवलोकनों को अलग रखें: सही किया स्रोत संदर्भ और सफल ब्राउज़र अनुरोध अलग सवालों के जवाब हैं। कोई भी अकेले साबित नहीं करता कि सारी सामग्री, हर ब्राउज़र या पूरी वेबसाइट सुरक्षित है।
नतीजे न मिलना और आंशिक कवरेज समझें
चेकर अधिकतम 2 MiB HTML स्वीकार करता है और 200 समूहित पंक्तियों में अधिकतम 1,000 HTTP संदर्भ रखता है। अगर परिणाम की सीमा आगे का साक्ष्य रखने से रोके तो कवरेज आंशिक होता है और संदर्भों की पूरी संख्या अज्ञात रहती है। सारांश तब पूरा दस्तावेज़ नहीं, रखा गया हिस्सा बताता है। स्रोत प्राप्त न हो या HTML सीमा से बड़ा हो तो मांगी गई जांच इसके बजाय अनुपलब्ध रहती है।
नतीजे न मिलने का मतलब जांचे गए स्रोत दायरे में समर्थित HTTP संदर्भ नहीं मिले। यह JavaScript से बने अनुरोध, CSS url() मान, बाहरी स्टाइलशीट की सामग्री, भीतर के फ़्रेम दस्तावेज़ या सभी संभावित एट्रिब्यूट शामिल नहीं करता। संसाधन रीडायरेक्ट भी नहीं देखता: मूल HTTPS एट्रिब्यूट पढ़ने से यह तय नहीं होता कि फ़ाइल बाद में HTTP पर जाती है या नहीं।
सामान्य नेविगेशन एंकर बाहर हैं, जिसमें HTTP पेज का साधारण लिंक भी है। डाउनलोड व्यवहार और गंतव्य की सुरक्षा अलग समीक्षा मांगते हैं; टेबल में न होना उनकी मंज़ूरी नहीं है। एम्बेडेड संसाधनों के बजाय पेज के बाहर जाने वाले लिंक का सवाल हो तो Internal Link Analyzer इस्तेमाल करें।
आंशिक रिपोर्ट के लिए JSON डाउनलोड में दायरा सुरक्षित रखें और बचे हुए स्रोत संदर्भ अलग जांचें। दिखाई गई पंक्तियां हटाने से छूटे हुए संदर्भों का ठीक होना साबित नहीं होता। बदलाव के बाद दोबारा चलाएं और पुरानी रिपोर्ट रखें, ताकि पुष्ट सुधार और कभी न जांचे साक्ष्य में फर्क रहे।