no-transform और HTTPS के साथ प्रॉक्सी सामग्री पुनर्लेखन सीमित करें
HTTP सामग्री नीति घोषित करने के लिए no-transform और मार्ग में पृष्ठ बदलाव से ब्राउज़र कनेक्शन की सुरक्षा के लिए HTTPS का उपयोग करें।
सामग्री रूपांतरित करने वाला प्रॉक्सी ब्राउज़र की ओर जाते मार्ग में प्रतिक्रिया बदल सकता है: किसी छवि को फिर से संपीड़ित करना, मार्कअप फिर से लिखना या सहायक JavaScript डालना। जो पृष्ठ एक नेटवर्क पर काम करता है और दूसरे पर अपरिचित मार्कअप पाता है, वह संभवतः उसी मध्यस्थ व्यवहार से सामना कर रहा है।
आपके द्वारा संचालित साइट के लिए HTTP एक स्पष्ट प्रतिक्रिया निर्देश देता है:
Cache-Control: no-transform
RFC 9111 अपेक्षा करता है कि यह प्रतिक्रिया निर्देश पाने वाला मध्यस्थ सामग्री को अपरिवर्तित छोड़े, चाहे वह मध्यस्थ कैश लागू करे या न करे। यह छवि पुनःसंपीड़न और मार्कअप इंजेक्शन से संबंधित है, केवल इससे नहीं कि कोई वस्तु संग्रहीत होती है या नहीं।
इसे मौजूदा कैश नीति के साथ रखें
यदि प्रतिक्रिया में पहले से कैश निर्देश हैं, तो नीति का बाकी हिस्सा त्यागने के बजाय आवश्यकता को जानबूझकर जोड़ें। उदाहरण के लिए, सार्वजनिक रूप से कैश-योग्य संपत्ति में यह हो सकता है:
Cache-Control: public, max-age=3600, no-transform
यह उदाहरण एक घंटे की ताज़गी नीति बनाए रखता है और साथ ही सामग्री रूपांतरण को रोकता है। no-transform का अर्थ no-store नहीं है और यह सामान्य स्थानांतरण प्रसंस्करण को बंद नहीं करता। इसे उन प्रतिक्रियाओं पर सेट करें जिनकी मूल सामग्री मायने रखती है, जहाँ उपयुक्त हो वहाँ अलग छवि प्रतिक्रियाओं सहित।
यह निर्देश मध्यस्थ के अनुपालन से काम करता है। यह किसी नेटवर्क उपकरण को निर्देश अनदेखा करने से क्रिप्टोग्राफ़िक रूप से नहीं रोकता।
परिवहन को भी सुरक्षित रखें
HTTPS ब्राउज़र को उसके TLS साथी के प्रति प्रमाणीकरण और अखंडता सुरक्षा वाला कनेक्शन देता है। एन्क्रिप्टेड ट्रैफ़िक पार करने वाला सामान्य वाहक प्रॉक्सी उस सुरक्षित कनेक्शन में चुपचाप स्क्रिप्ट नहीं डाल सकता। प्रमाणपत्र सत्यापन चालू रखें; TLS समाप्त करने वाला स्थानीय रूप से विश्वसनीय निरीक्षण प्रॉक्सी एक भिन्न व्यवस्था है।
पृष्ठ और उसके आश्रित संसाधन HTTPS पर परोसें। HTTP आगंतुकों को HTTPS पर पुनर्निर्देशित करें, और ऐसी तैनाती के लिए HSTS पर विचार करें जो इसे लगातार समर्थित रख सके। केवल पुनर्निर्देशन HTTP URL इस्तेमाल करने वाले आगंतुक के लिए असुरक्षित HTTP विनिमय से शुरू होता है; पहले सीखी गई या पहले से लोड की गई HSTS नीति उस प्रारंभिक चयन को बदल देती है।
इंजेक्ट की गई स्क्रिप्ट को अवरुद्ध करना उसके दृश्य प्रभावों को कम कर सकता है, पर प्रतिक्रिया में पहले से बदला हुआ HTML या पुनर्लिखित छवि URL हो सकते हैं। एक पुराने फ़ंक्शन नाम को बदलना, असामान्य टिप्पणी जोड़ना या ऐतिहासिक इंजेक्शन पते को मैप करना अगले मध्यस्थ के लिए सामग्री अखंडता स्थापित नहीं करता।
किसी रिपोर्ट की जाँच करते समय, प्राप्त प्रतिक्रिया की तुलना मूल के इच्छित सामग्री से करें और पहचानें कि TLS कहाँ समाप्त होता है। वह साक्ष्य हर अपरिचित स्क्रिप्ट को साइट के अपने एप्लिकेशन कोड में बग मानने से अधिक उपयोगी है।