उन हेडर के बारे में ज़्यादा जानें जो आपकी साइट को सुरक्षित रख सकते हैं और सबसे अहम जानकारी को तुरंत खोज सकते हैं.
इस लेख में उन सबसे ज़रूरी सुरक्षा हेडर की सूची दी गई है, जिनका इस्तेमाल करके आप अपनी वेबसाइट को सुरक्षित रख सकते हैं. वेब पर आधारित सुरक्षा सुविधाओं को समझने, इन्हें अपनी वेबसाइट पर लागू करने का तरीका जानें, और ज़रूरत पड़ने पर इन्हें रेफ़रंस के तौर पर इस्तेमाल करें.
- जिन वेबसाइटों पर उपयोगकर्ता का संवेदनशील डेटा मैनेज होता है उनके लिए सुरक्षा हेडर का सुझाव दिया जाता है:
- कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी)
- भरोसेमंद टाइप
- सभी वेबसाइटों के लिए सुरक्षा हेडर का सुझाव दिया जाता है:
- X-Content-Type-Options
- X-फ़्रेम-विकल्प
- क्रॉस-ऑरिजिन रिसॉर्स पॉलिसी (सीओआरपी)
- क्रॉस-ऑरिजिन ओपनर पॉलिसी (सीओओपी)
- एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी (एचएसटीएस)
- बेहतर सुविधाओं वाली वेबसाइटों के लिए सिक्योरिटी हेडर:
- क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस)
- क्रॉस-ऑरिजिन एम्बेडर पॉलिसी (सीओईपी)
सुरक्षा हेडर के बारे में जानने से पहले, वेब पर आम तौर पर आने वाले खतरों के बारे में जानें और जानें कि आपको इन सुरक्षा हेडर का इस्तेमाल क्यों करना चाहिए.
अपनी साइट को इंजेक्शन से जुड़े जोखिमों से बचाना
इंजेक्शन के जोखिम की आशंका तब होती है, जब आपके ऐप्लिकेशन में प्रोसेस किए जाने वाले गैर-भरोसेमंद डेटा की वजह से, आम तौर पर ऐप्लिकेशन के काम करने के तरीके पर असर पड़ सकता है. इस वजह से, आम तौर पर हमलावरों की ओर से कंट्रोल की जाने वाली स्क्रिप्ट लागू होती हैं. इंजेक्शन से जुड़ी गड़बड़ियों की वजह से होने वाला सबसे सामान्य जोखिम, क्रॉस-साइट स्क्रिप्टिंग (XSS) के अलग-अलग रूपों में है. इनमें रिफ़्लेक्टेड XSS, स्टोर किया गया XSS, DOM पर आधारित XSS, और दूसरे वैरिएंट शामिल हैं.
XSS के जोखिम की आशंका से, किसी हमलावर को ऐप्लिकेशन के प्रोसेस किए गए उपयोगकर्ता के डेटा और उसी वेब ऑरिजिन पर होस्ट की गई अन्य जानकारी का पूरा ऐक्सेस मिल सकता है.
इंजेक्शन से बचने के पारंपरिक तरीकों में, ऑटो-स्कैपिंग एचटीएमएल टेंप्लेट सिस्टम का लगातार इस्तेमाल करना, खतरनाक JavaScript एपीआई का इस्तेमाल करने से बचना, और उपयोगकर्ता के डेटा को एक अलग डोमेन में फ़ाइल अपलोड को होस्ट करके, और उपयोगकर्ता के कंट्रोल किए जाने वाले एचटीएमएल को सैनिटाइज़ करके ठीक से प्रोसेस करना शामिल है.
- कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी) का इस्तेमाल करके, यह कंट्रोल करें कि इंजेक्शन के जोखिम को कम करने के लिए, आपका ऐप्लिकेशन कौनसी स्क्रिप्ट चला सकता है.
- खतरनाक JavaScript API में भेजे गए डेटा की सैनिटाइज़ेशन लागू करने के लिए भरोसेमंद प्रकार का इस्तेमाल करें.
- X-Content-Type-Options का इस्तेमाल करें, ताकि ब्राउज़र आपकी वेबसाइट के संसाधनों के MIME टाइप को गलत तरीके से समझ न पाए. इन संसाधनों की वजह से स्क्रिप्ट लागू की जा सकती है.
अपनी साइट को दूसरी वेबसाइटों से अलग करना
वेब के खुले होने की वजह से, वेबसाइटें एक-दूसरे से इस तरह इंटरैक्ट कर सकती हैं जिससे किसी ऐप्लिकेशन की सुरक्षा से जुड़ी उम्मीदों का उल्लंघन हो सकता है. इसमें हमलावर के दस्तावेज़ में, पुष्टि किए गए अनुरोध करना या किसी दूसरे ऐप्लिकेशन से डेटा एम्बेड करना शामिल है. इसकी मदद से, हमलावर, ऐप्लिकेशन के डेटा में बदलाव कर सकता है या उसे पढ़ सकता है.
वेब आइसोलेशन को कमज़ोर करने वाली आम जोखिमों की आशंकाओं में, क्लिकजैकिंग, क्रॉस-साइट अनुरोध जालसाज़ी (सीएसआरएफ़), क्रॉस-साइट स्क्रिप्ट शामिल करना (XSSI), और कई क्रॉस-साइट लीक शामिल हैं.
- अपने दस्तावेज़ों को नुकसान पहुंचाने वाली किसी वेबसाइट पर एम्बेड किए जाने से रोकने के लिए, X-Frame-Options का इस्तेमाल करें.
- अपनी वेबसाइट के संसाधनों को क्रॉस-ऑरिजिन वेबसाइट में शामिल किए जाने से रोकने के लिए, क्रॉस-ऑरिजिन रिसॉर्स नीति (सीओआरपी) का इस्तेमाल करें.
- अपनी वेबसाइट की विंडो को नुकसान पहुंचाने वाली वेबसाइटों से इंटरैक्शन से बचाने के लिए, क्रॉस-ऑरिजिन ओपनर नीति (सीओओपी) का इस्तेमाल करें.
- क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का इस्तेमाल करके, क्रॉस-ऑरिजिन दस्तावेज़ों से अपनी वेबसाइट के संसाधनों का ऐक्सेस कंट्रोल करें.
अगर आपकी दिलचस्पी इन हेडर में है, तो पोस्ट-स्पेक्टर वेब डेवलपमेंट के लिए एक बेहतरीन टूल है.
सुरक्षित तरीके से एक असरदार वेबसाइट बनाएं
एक ही ऑरिजिन से जुड़ी नीति के बावजूद, स्पेक्टर, लोड किए गए किसी भी डेटा
को ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में डाल देता है. इस ग्रुप को पढ़ा जा सकता है. ब्राउज़र ऐसी सुविधाओं पर पाबंदी लगाते हैं जो "क्रॉस-ऑरिजिन आइसोलेशन" नाम के एक खास एनवायरमेंट की जोखिम की आशंका का फ़ायदा उठा सकती हैं. क्रॉस-ऑरिजिन आइसोलेशन की मदद से, SharedArrayBuffer
जैसी बेहतरीन सुविधाओं का इस्तेमाल किया जा सकता है.
- क्रॉस-ऑरिजिन आइसोलेशन चालू करने के लिए, सीओओपी के साथ-साथ क्रॉस-ऑरिजिन एम्बेडर नीति (सीओईपी) का इस्तेमाल करें.
अपनी साइट का ट्रैफ़िक एन्क्रिप्ट (सुरक्षित) करें
एन्क्रिप्ट (सुरक्षित) करने से जुड़ी समस्याएं तब दिखती हैं, जब कोई ऐप्लिकेशन, ट्रांसफ़र के दौरान डेटा को पूरी तरह से एन्क्रिप्ट (सुरक्षित) नहीं करता है. इससे जासूसी करने वाले हमलावरों को, उपयोगकर्ता के ऐप्लिकेशन के साथ हुए इंटरैक्शन के बारे में जानकारी मिलती है.
एन्क्रिप्ट (सुरक्षित) करने के तरीके की अधूरी जानकारी इन मामलों में हो सकती है: एचटीटीपीएस का इस्तेमाल न करना,
मिले-जुले कॉन्टेंट का इस्तेमाल न करना, Secure
एट्रिब्यूट
या __Secure
प्रीफ़िक्स के बिना कुकी सेट करना,
या लैक्स सीओआरएस पुष्टि
लॉजिक.
- एचटीटीपीएस के ज़रिए अपने कॉन्टेंट को लगातार दिखाने के लिए, एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी (एचएसटीएस) का इस्तेमाल करें.
कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी)
क्रॉस-साइट स्क्रिप्टिंग (XSS) एक ऐसा हमला है जिसमें किसी वेबसाइट के जोखिम की वजह से नुकसान पहुंचाने वाली स्क्रिप्ट को इंजेक्ट किया जा सकता है और लागू किया जा सकता है.
Content-Security-Policy
, XSS हमलों को कम करने के लिए एक अतिरिक्त लेयर उपलब्ध कराता है, ताकि यह पाबंदी लगाई जा सके कि पेज से कौनसी स्क्रिप्ट चलाई जा सकती हैं.
हमारा सुझाव है कि आप इनमें से किसी एक तरीके का इस्तेमाल करके, सख्त सीएसपी चालू करें:
- अगर आप सर्वर पर अपने एचटीएमएल पेजों को रेंडर करते हैं, तो नॉन्स पर आधारित सख्त सीएसपी का इस्तेमाल करें.
- अगर आपको अपने एचटीएमएल को स्टैटिक या कैश मेमोरी में सेव करना है, तो हैश-आधारित सख्त सीएसपी का इस्तेमाल करें. उदाहरण के लिए, अगर यह एक पेज का ऐप्लिकेशन है.
इस्तेमाल का उदाहरण: नॉन्स-आधारित सीएसपी
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
सुझाए गए इस्तेमाल
1. नॉन्स-आधारित सख्त सीएसपी {: #nonce-based-csp} का इस्तेमाल करें
अगर आप सर्वर पर अपने एचटीएमएल पेजों को रेंडर करते हैं, तो नॉन्स पर आधारित सख्त सीएसपी का इस्तेमाल करें.
सर्वर साइड पर किए जाने वाले हर अनुरोध के लिए, एक नई स्क्रिप्ट नॉन्स वैल्यू जनरेट करें और यहां दिया गया हेडर सेट करें:
सर्वर कॉन्फ़िगरेशन फ़ाइल
Content-Security-Policy: script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none';
एचटीएमएल में, स्क्रिप्ट लोड करने के लिए सभी <script>
टैग के nonce
एट्रिब्यूट को एक ही {RANDOM1}
स्ट्रिंग पर सेट करें.
index.html
<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script> <script nonce="{RANDOM1}"> // Inline scripts can be used with the <code>nonce</code> attribute. </script>
Google Photos, नॉन्स पर आधारित एक अच्छे सीएसपी का अच्छा उदाहरण है. DevTools का इस्तेमाल करके देखें कि यह कैसे इस्तेमाल किया जाता है.
2. हैश-आधारित सख्त सीएसपी {: #hash-based-csp} का इस्तेमाल करें
अगर आपको अपने एचटीएमएल को स्टैटिक या कैश मेमोरी में सेव करना है, तो हैश पर आधारित एक सख्त सीएसपी का इस्तेमाल करें. उदाहरण के लिए, अगर एक पेज का ऐप्लिकेशन बनाया जा रहा है, तो ऐसा किया जा सकता है.
सर्वर कॉन्फ़िगरेशन फ़ाइल
Content-Security-Policy: script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none';
एचटीएमएल में, हैश-आधारित नीति लागू करने के लिए आपको अपनी स्क्रिप्ट को इनलाइन करना होगा, क्योंकि ज़्यादातर ब्राउज़र में बाहरी स्क्रिप्ट हैशिंग की सुविधा काम नहीं करती.
index.html
<script> ...// your script1, inlined </script> <script> ...// your script2, inlined </script>
बाहरी स्क्रिप्ट लोड करने के लिए, विकल्प B: हैश-आधारित सीएसपी रिस्पॉन्स हेडर सेक्शन में "सोर्स की गई स्क्रिप्ट को डाइनैमिक तौर पर लोड करें" पढ़ें.
सीएसपी का आकलन करने वाला अपने सीएसपी का आकलन करने के लिए एक अच्छा टूल है. हालांकि, नॉन्स पर आधारित सख्त सीएसपी का उदाहरण भी एक अच्छा टूल है. DevTools का इस्तेमाल करके देखें कि यह कैसे इस्तेमाल किया जाता है.
इस्तेमाल किए जा सकने वाले ब्राउज़र
सीएसपी के बारे में ध्यान रखने वाली अन्य बातें
frame-ancestors
डायरेक्टिव, आपकी साइट पर क्लिकजैकिंग से बचाता है. यह एक तरह का जोखिम तब होता है, जब गैर-भरोसेमंद साइटों को अपनी साइट एम्बेड करने की अनुमति दी जाती है. अगर आपको आसान तरीका चाहिए, तो लोड होने से रोकने के लिएX-Frame-Options
का इस्तेमाल करें. हालांकि,frame-ancestors
आपको बेहतर कॉन्फ़िगरेशन उपलब्ध कराता है, ताकि कुछ खास ऑरिजिन को ही एम्बेडर के तौर पर अनुमति दी जा सके.- शायद आपने यह पक्का करने के लिए एक सीएसपी का इस्तेमाल किया हो कि आपकी साइट के सभी रिसॉर्स, एचटीटीपीएस पर लोड हों. यह अब कम काम का है: आज के समय में, ज़्यादातर ब्राउज़र मिक्स्ड-कॉन्टेंट को ब्लॉक कर देते हैं.
- रिपोर्ट-ओनली मोड में भी सीएसपी सेट किया जा सकता है.
- अगर एक सीएसपी को हेडर सर्वर-साइड के तौर पर सेट नहीं किया जा सकता, तो उसे मेटा टैग के तौर पर भी सेट किया जा सकता है. ध्यान दें कि मेटा टैग के लिए, सिर्फ़ रिपोर्ट मोड का इस्तेमाल नहीं किया जा सकता. हालांकि, इसमें बदलाव हो सकता है.
ज़्यादा जानें
विश्वसनीय प्रकार
DOM पर आधारित XSS एक हमला है, जिसमें नुकसान पहुंचाने वाला डेटा ऐसे सिंक में भेजा जाता है जो eval()
या .innerHTML
जैसे डाइनैमिक कोड एक्ज़ीक्यूट पर काम करता है.
भरोसेमंद टाइप, DOM XSS के बिना ऐप्लिकेशन लिखने, सुरक्षा समीक्षा करने, और उनका रखरखाव करने के टूल मुहैया कराते हैं. इन्हें सीएसपी की मदद से चालू किया जा सकता है और JavaScript कोड को डिफ़ॉल्ट रूप से सुरक्षित बनाया जा सकता है. ऐसा करने के लिए, खतरनाक वेब एपीआई को सिर्फ़ एक खास ऑब्जेक्ट यानी 'भरोसेमंद टाइप' को स्वीकार करने के लिए सीमित किया जाता है.
ये ऑब्जेक्ट बनाने के लिए, सुरक्षा नीतियां तय की जा सकती हैं. इनकी मदद से, यह पक्का किया जा सकता है कि डेटा को डीओएम में लिखने से पहले, सुरक्षा से जुड़े नियम (जैसे कि एस्केपिंग या सैनिटाइज़ेशन) एक ही तरीके से लागू किए जाएं. इसके बाद, कोड में ये नीतियां सिर्फ़ ऐसी जगहें होती हैं जहां से DOM XSS मिल सकता है.
इस्तेमाल के उदाहरण
Content-Security-Policy: require-trusted-types-for 'script'
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\</g, '<').replace(/>/g, '>');
}
});
}
// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.
// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped; // '&lt;img src=x onerror=alert(1)&gt;'
सुझाए गए इस्तेमाल
-
खतरनाक डीओएम सिंक के लिए, भरोसेमंद टाइप लागू करें सीएसपी और भरोसेमंद टाइप हेडर
Content-Security-Policy: require-trusted-types-for 'script'
फ़िलहाल,
require-trusted-types-for
डायरेक्टिव के लिए सिर्फ़'script'
वैल्यू ही स्वीकार की जाती है.बेशक, आप भरोसेमंद टाइप को दूसरे सीएसपी निर्देशों के साथ जोड़ सकते हैं:
ऊपर दिए गए नॉन्स-आधारित सीएसपी को भरोसेमंद टाइप के साथ मर्ज करना:
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
<aside class="note"><b>ध्यान दें: </b> आप अतिरिक्त <code>भरोसेमंद प्रकार</code> डायरेक्टिव (उदाहरण के लिए, <code>untrusted-types myPolicy</code>) सेट करके, भरोसेमंद टाइप की नीतियों के लिए अनुमति वाले नामों को सीमित कर सकते हैं. हालांकि, ऐसा करने की कोई ज़रूरत नहीं है. </aside>
-
नीति तय करें
नीति:
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\/g, '>');
}
});
}
-
नीति लागू करें
डीओएम में डेटा लिखते समय, इस नीति का इस्तेमाल करें:
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.</p>
<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src="x" onerror="alert(1)">');
el.innerHTML = escaped; // '<img src=x onerror=alert(1)>'
require-trusted-types-for 'script'
के साथ, भरोसेमंद टाइप का इस्तेमाल
करना ज़रूरी है. स्ट्रिंग के साथ खतरनाक DOM API का इस्तेमाल करने से
गड़बड़ी हो सकती है.
इस्तेमाल किए जा सकने वाले ब्राउज़र
ज़्यादा जानें
- भरोसेमंद टाइप की मदद से, डीओएम आधारित क्रॉस-साइट स्क्रिप्टिंग के जोखिम से बचें
- सीएसपी: need-untrusted-types-for - एचटीटीपी |
एमडीएन
- सीएसपी: भरोसेमंद के टाइप - एचटीटीपी |
एमडीएन
- भरोसेमंद टाइप का डेमो— DevTools इंस्पेक्टर खोलें और देखें कि
क्या हो रहा है
X-Content-Type-Options
जब आपके डोमेन से कोई नुकसान पहुंचाने वाला एचटीएमएल दस्तावेज़ दिखाया जाता है (उदाहरण के लिए, अगर किसी फ़ोटो सेवा पर अपलोड की गई किसी इमेज में मान्य एचटीएमएल मार्कअप है), तो कुछ ब्राउज़र उसे ऐक्टिव दस्तावेज़ मानेंगे और ऐप्लिकेशन के संदर्भ में स्क्रिप्ट चलाने की अनुमति देंगे. इससे, क्रॉस-साइट स्क्रिप्टिंग से जुड़ी गड़बड़ी हो जाती है.
X-Content-Type-Options: nosniff
, ब्राउज़र को यह निर्देश देकर इस सुविधा को रोकता है कि
Content-Type
हेडर में सेट किया गया MIME टाइप सही है. इस हेडर को आपके सभी संसाधनों के लिए सुझाया गया है.
इस्तेमाल के उदाहरण
X-Content-Type-Options: nosniff
सुझाए गए इस्तेमाल
X-Content-Type-Options: nosniff
का सुझाव, सही Content-Type
हेडर के साथ
आपके सर्वर से दिखाए गए सभी संसाधनों के लिए दिया जाता है.
दस्तावेज़ के एचटीएमएल के साथ भेजे गए हेडर के उदाहरण
X-Content-Type-Options: nosniff Content-Type: text/html; charset=utf-8
इस्तेमाल किए जा सकने वाले ब्राउज़र
ज़्यादा जानें
X-फ़्रेम-विकल्प
अगर नुकसान पहुंचाने वाली कोई वेबसाइट आपकी साइट को iframe के रूप में एम्बेड कर सकती है, तो इससे हमलावर, क्लिकजैकिंग की मदद से उन कार्रवाइयों को शुरू कर सकते हैं जो अनजाने में की गई हैं. साथ ही, कुछ मामलों में स्पेक्टर टाइप के हमलों की वजह से, नुकसान पहुंचाने वाली वेबसाइटों को एम्बेड किए गए दस्तावेज़ के कॉन्टेंट के बारे में जानकारी मिल पाती है.
X-Frame-Options
से यह पता चलता है कि ब्राउज़र को <frame>
, <iframe>
, <embed>
या <object>
में से
किसी पेज को रेंडर करने की अनुमति दी जानी चाहिए या नहीं. सभी दस्तावेज़ों को इस हेडर को भेजने का सुझाव दिया जाता है, ताकि यह बताया जा सके कि उन्हें दूसरे दस्तावेज़ों में एम्बेड किया जा सकता है या नहीं.
इस्तेमाल के उदाहरण
X-Frame-Options: DENY
सुझाए गए इस्तेमाल
जो दस्तावेज़ एम्बेड करने के लिए डिज़ाइन नहीं किए गए हैं उनमें X-Frame-Options
हेडर का इस्तेमाल होना चाहिए.
इस डेमो में, यह देखा जा सकता है कि नीचे दिए गए कॉन्फ़िगरेशन, iframe को लोड करने पर कैसे असर डालते हैं. X-Frame-Options
ड्रॉपडाउन मेन्यू बदलें और iframe को फिर से लोड करें बटन पर क्लिक करें.
यह आपकी वेबसाइट को किसी दूसरी वेबसाइट पर एम्बेड किए जाने से बचाता है
किसी दूसरे दस्तावेज़ से एम्बेड किए जाने की अनुमति न दें.
X-Frame-Options: DENY
यह आपकी वेबसाइट को किसी भी क्रॉस-ऑरिजिन वेबसाइट पर एम्बेड होने से बचाता है
सिर्फ़ एक ही ऑरिजिन वाले दस्तावेज़ों में एम्बेड होने की अनुमति दें.
X-Frame-Options: SAMEORIGIN
इस्तेमाल किए जा सकने वाले ब्राउज़र
ज़्यादा जानें
क्रॉस-ऑरिजिन रिसॉर्स पॉलिसी (सीओआरपी)
कोई हमलावर वेब पर आधारित क्रॉस-साइट लीक का गलत इस्तेमाल करके, अपनी साइट के संसाधनों को किसी दूसरे ऑरिजिन से जोड़ सकता है, जैसे कि आपकी साइट से.
यह जोखिम को कम करने के लिए, Cross-Origin-Resource-Policy
यह जानकारी देता है कि यह किन वेबसाइटों पर लोड की जा सकती है. हेडर में, इन तीन वैल्यू में से कोई एक होती है: same-origin
, same-site
, और cross-origin
. सभी रिसॉर्स
को इस हेडर को भेजने का सुझाव दिया जाता है, ताकि यह बताया जा सके कि उन्हें दूसरी वेबसाइटों
को लोड करने की अनुमति है या नहीं.
इस्तेमाल के उदाहरण
Cross-Origin-Resource-Policy: same-origin
सुझाए गए इस्तेमाल
हमारा सुझाव है कि सभी संसाधनों को, इन तीन हेडर में से किसी एक के साथ दिखाया जाए.
इस डेमो में, Cross-Origin-Embedder-Policy: require-corp
एनवायरमेंट में जाकर देखें कि यहां दिए गए कॉन्फ़िगरेशन, लोड होने वाले रिसॉर्स पर कैसे असर डालते हैं. असर देखने के लिए,
Cross-Origin-Resource-Policy ड्रॉपडाउन मेन्यू को बदलें और Cross-Origin-Resource-Policy या Cross-Origin-Resource-Policy बटन पर क्लिक करें.
संसाधनों को लोड होने की अनुमति दें cross-origin
हमारा सुझाव है कि सीडीएन जैसी सेवाएं, संसाधनों पर cross-origin
को लागू करें, क्योंकि ये आम तौर पर क्रॉस-ऑरिजिन पेज से लोड होती हैं. हालांकि, अगर ये सेवाएं सीओआरएस की मदद से उपलब्ध कराई जा रही हैं, तो इनका यही असर नहीं होगा.
Cross-Origin-Resource-Policy: cross-origin
same-origin
से लोड होने वाले संसाधनों को सीमित करें
same-origin
को उन संसाधनों पर लागू किया जाना चाहिए जिन्हें सिर्फ़ एक जैसे ऑरिजिन वाले पेजों से लोड
किया जाना चाहिए. आपको इसे ऐसे संसाधनों पर लागू करना चाहिए जिनमें उपयोगकर्ता के बारे में संवेदनशील
जानकारी शामिल हो या किसी ऐसे एपीआई के रिस्पॉन्स शामिल हों जिन्हें सिर्फ़ उसी ऑरिजिन से कॉल किया जाना हो.
ध्यान रखें कि इस हेडर वाले संसाधन अब भी सीधे लोड किए जा सकते हैं. उदाहरण के लिए, नई ब्राउज़र विंडो में यूआरएल पर जाकर. क्रॉस-ऑरिजिन रिसॉर्स नीति सिर्फ़ संसाधन को दूसरी वेबसाइटों पर एम्बेड किए जाने से रोकती है.
Cross-Origin-Resource-Policy: same-origin
same-site
से लोड होने वाले संसाधनों को सीमित करें
हमारा सुझाव है कि आप same-site
को उन रिसॉर्स पर लागू करें जो ऊपर दिए गए रिसॉर्स से मिलते-जुलते हैं, लेकिन उन्हें आपकी साइट के अन्य सबडोमेन से लोड करने के लिए बनाया गया है.
Cross-Origin-Resource-Policy: same-site
इस्तेमाल किए जा सकने वाले ब्राउज़र
ज़्यादा जानें
क्रॉस-ऑरिजिन ओपनर पॉलिसी (सीओओपी)
किसी हमलावर की वेबसाइट किसी दूसरी साइट को पॉप-अप विंडो में खोल सकती है, ताकि वह वेब आधारित क्रॉस-साइट लीक का गलत इस्तेमाल करके, उसके बारे में जानकारी हासिल कर सके. कुछ मामलों में, इसकी मदद से स्पेक्टर के आधार पर साइड-चैनल हमलों का फ़ायदा भी लिया जा सकता है.
Cross-Origin-Opener-Policy
हेडर की मदद से दस्तावेज़, window.open()
के ज़रिए खोली गई क्रॉस-ऑरिजिन विंडो या rel="noopener"
के बिना target="_blank"
वाले लिंक से खुद को अलग कर सकता है. इस वजह से, दस्तावेज़ के किसी भी क्रॉस-ऑरिजिन ओपनर
का इसका कोई रेफ़रंस नहीं होगा और वह उससे इंटरैक्ट नहीं कर पाएगा.
इस्तेमाल के उदाहरण
Cross-Origin-Opener-Policy: same-origin-allow-popups
सुझाए गए इस्तेमाल
इस डेमो में देखा जा सकता है कि नीचे दिए गए कॉन्फ़िगरेशन, क्रॉस-ऑरिजिन पॉप-अप विंडो से कम्यूनिकेशन पर कैसे असर डालते हैं. दस्तावेज़ और पॉप-अप विंडो, दोनों के लिए Cross-Origin-Opener-Policy ड्रॉपडाउन मेन्यू बदलें और Cross-Origin-Opener-Policy बटन पर क्लिक करें. इसके बाद, Cross-Origin-Opener-Policy पर क्लिक करें और देखें कि वाकई में मैसेज डिलीवर हुआ या नहीं.
किसी दस्तावेज़ को क्रॉस-ऑरिजिन विंडो से अलग करना
same-origin
को सेट करने पर, दस्तावेज़ को क्रॉस-ऑरिजिन दस्तावेज़ विंडो से अलग कर दिया जाता है.
Cross-Origin-Opener-Policy: same-origin
क्रॉस-ऑरिजिन विंडो से दस्तावेज़ को अलग करना, लेकिन पॉप-अप की अनुमति देना
same-origin-allow-popups
को सेट करने पर, दस्तावेज़ अपने पॉप-अप विंडो का रेफ़रंस तब तक सेव रख सकता है, जब तक सीओओपी को same-origin
या
same-origin-allow-popups
के साथ सेट नहीं किया जाता. इसका मतलब है कि same-origin-allow-popups
अब भी पॉप-अप विंडो के तौर पर खोले जाने पर, दस्तावेज़ को रेफ़र किए जाने से सुरक्षित रख सकता है. हालांकि, यह अपने पॉप-अप के साथ बातचीत करने की अनुमति दे सकता है.
Cross-Origin-Opener-Policy: same-origin-allow-popups
क्रॉस-ऑरिजिन विंडो से, दस्तावेज़ का रेफ़रंस देने की अनुमति दें
unsafe-none
डिफ़ॉल्ट वैल्यू है, लेकिन आपके पास साफ़ तौर पर यह जानकारी देने का विकल्प होता है कि इस दस्तावेज़ को क्रॉस-ऑरिजिन विंडो से खोला जा सकता है और म्युचुअल ऐक्सेस को बनाए रखा जा सकता है.
Cross-Origin-Opener-Policy: unsafe-none
COOP के साथ काम न करने वाले रिपोर्ट पैटर्न
जब सीओओपी, Reporting API की मदद से क्रॉस-विंडो इंटरैक्शन को रोकता है, तब आपको रिपोर्ट मिल सकती हैं.
Cross-Origin-Opener-Policy: same-origin; report-to="coop"
COOP सिर्फ़ रिपोर्ट वाला मोड भी काम करता है. इससे क्रॉस-ऑरिजिन दस्तावेज़ों के बीच होने वाले कम्यूनिकेशन को ब्लॉक किए बिना भी रिपोर्ट पाई जा सकती हैं.
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
इस्तेमाल किए जा सकने वाले ब्राउज़र
ज़्यादा जानें
क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस)
इस लेख में दिए गए अन्य आइटम से अलग, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) एक हेडर नहीं है, बल्कि एक ऐसा ब्राउज़र तरीका है जो क्रॉस-ऑरिजिन रिसॉर्स के ऐक्सेस का अनुरोध करता है और उसे ऐक्सेस करने की अनुमति देता है.
डिफ़ॉल्ट रूप से, ब्राउज़र सेम-ऑरिजिन की नीति को लागू करते हैं, ताकि किसी वेब पेज को क्रॉस-ऑरिजिन रिसॉर्स को ऐक्सेस करने से रोका जा सके. उदाहरण के लिए, जब कोई क्रॉस-ऑरिजिन इमेज लोड होती है, भले ही वह वेब पेज पर विज़ुअल के रूप में दिखाई गई हो, तो पेज पर मौजूद JavaScript को इमेज के डेटा का ऐक्सेस नहीं मिलता. संसाधन देने वाली कंपनी, पाबंदियों में छूट दे सकती है. साथ ही, दूसरी वेबसाइटों को सीओआरएस से ऑप्ट-इन करके, रिसॉर्स को पढ़ने की अनुमति दे सकती है.
इस्तेमाल के उदाहरण
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
सीओआरएस को कॉन्फ़िगर करने का तरीका जानने से पहले, अनुरोध के टाइप के बीच अंतर को समझना ज़रूरी है. अनुरोध की जानकारी के आधार पर, किसी अनुरोध को सामान्य अनुरोध या प्रीफ़्लाइट किए गए अनुरोध की कैटगरी में रखा जाएगा.
सामान्य अनुरोध के लिए शर्तें:
- यह तरीका
GET
,HEAD
याPOST
है. - कस्टम हेडर में सिर्फ़
Accept
,Accept-Language
,Content-Language
, औरContent-Type
शामिल होते हैं. Content-Type
,application/x-www-form-urlencoded
,multipart/form-data
याtext/plain
है.
बाकी सब कुछ प्रीफ़्लाइट किए गए अनुरोध की कैटगरी में रखा जाता है. ज़्यादा जानकारी के लिए, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) - एचटीटीपी | एमडीएन देखें.
सुझाए गए इस्तेमाल
आसान अनुरोध
जब कोई अनुरोध, आसान अनुरोध की शर्तों को पूरा करता है, तो ब्राउज़र Origin
हेडर के साथ क्रॉस-ऑरिजिन अनुरोध भेजता है. यह अनुरोध करने वाले
ऑरिजिन के बारे में बताता है.
अनुरोध के हेडर का उदाहरण
Get / HTTP/1.1 Origin: https://example.com
जवाब हेडर का उदाहरण
Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://example.com
से पता चलता है किhttps://example.com
, जवाब के कॉन्टेंट को ऐक्सेस कर सकता है. ऐसे संसाधन जिन्हें कोई भी साइट पढ़ सके, वे इस हेडर को*
पर सेट कर सकते हैं. इस स्थिति में, ब्राउज़र को सिर्फ़ क्रेडेंशियल के बिना अनुरोध करने की ज़रूरत होगी.Access-Control-Allow-Credentials: true
से पता चलता है कि ऐसे अनुरोध जिनके पास क्रेडेंशियल (कुकी) हैं, उन्हें संसाधन लोड करने की अनुमति दी गई है. ऐसा नहीं होने पर, पुष्टि किए गए अनुरोधों को अस्वीकार कर दिया जाएगा, भले ही अनुरोध करने वाला ऑरिजिनAccess-Control-Allow-Origin
हेडर में मौजूद हो.
इस डेमो में, Cross-Origin-Embedder-Policy: require-corp
एनवायरमेंट में जाकर देखें कि आसान अनुरोध से, रिसॉर्स के लोड होने पर क्या असर पड़ता है. असर देखने के लिए,
क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग वाले चेकबॉक्स पर क्लिक करें और इमेज को फिर से लोड करें
बटन पर क्लिक करें.
पहले से भेजे गए अनुरोध
प्रीफ़्लाइट किए गए अनुरोध से पहले OPTIONS
अनुरोध होता है. इससे यह पता चलता है कि
बाद वाला अनुरोध भेजा जा सकता है या नहीं.
अनुरोध के हेडर का उदाहरण
OPTIONS / HTTP/1.1 Origin: https://example.com Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-Type
Access-Control-Request-Method: POST
,POST
तरीके का इस्तेमाल करके, ये अनुरोध करने की अनुमति देता है.Access-Control-Request-Headers: X-PINGOTHER, Content-Type
, अनुरोध करने वाले को बाद के अनुरोध में,X-PINGOTHER
औरContent-Type
एचटीटीपी हेडर सेट करने की अनुमति देता है.
जवाब हेडर का उदाहरण
Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-PINGOTHER, Content-Type Access-Control-Max-Age: 86400
Access-Control-Allow-Methods: POST, GET, OPTIONS
बताता है कि बाद के अनुरोधPOST
,GET
, औरOPTIONS
तरीकों का इस्तेमाल करके किए जा सकते हैं.Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
से पता चलता है कि बाद के अनुरोधों मेंX-PINGOTHER
औरContent-Type
हेडर शामिल हो सकते हैं.Access-Control-Max-Age: 86400
से पता चलता है कि प्रीफ़्लाइट किए गए अनुरोध के नतीजे को 86,400 सेकंड के लिए कैश मेमोरी में सेव किया जा सकता है.
इस्तेमाल किए जा सकने वाले ब्राउज़र
ज़्यादा जानें
क्रॉस-ऑरिजिन एम्बेडर नीति (सीओईपी)
स्पेक्टर पर आधारित हमलों से क्रॉस-ऑरिजिन संसाधनों को चोरी होने से रोकने के लिए, SharedArrayBuffer
या performance.measureUserAgentSpecificMemory()
जैसी सुविधाएं डिफ़ॉल्ट रूप से बंद रहती हैं.
Cross-Origin-Embedder-Policy: require-corp
दस्तावेज़ों और वर्कर को क्रॉस-ऑरिजिन रिसॉर्स, जैसे कि इमेज, स्क्रिप्ट, स्टाइलशीट, iframe, और अन्य को लोड करने से रोकता है. ऐसा तब तक होता है, जब तक कि इन रिसॉर्स को सीओआरएस या सीओआरपी हेडर की मदद से लोड होने के लिए ऑप्ट इन न किया जाए. किसी दस्तावेज़ को क्रॉस-ऑरिजिन आइसोलेशन में शामिल करने के लिए, सीओईपी कोCross-Origin-Opener-Policy
के साथ जोड़ा जा सकता है.
अपने दस्तावेज़ के लिए, क्रॉस-ऑरिजिन आइसोलेशन चालू करने के लिए, Cross-Origin-Embedder-Policy: require-corp
का इस्तेमाल करें.
इस्तेमाल के उदाहरण
Cross-Origin-Embedder-Policy: require-corp
इस्तेमाल के उदाहरण
COEP में require-corp
की एक वैल्यू होती है. इस हेडर को भेजकर, ब्राउज़र को उन रिसॉर्स को लोड होने से रोकने का निर्देश दिया जा सकता है जो सीओआरएस या सीओआरपी से ऑप्ट-इन नहीं किए गए हैं.
इस डेमो में देखा जा सकता है कि नीचे दिए गए कॉन्फ़िगरेशन, लोड होने वाले संसाधनों पर कैसे असर डालते हैं. यह देखने के लिए कि Cross-Origin-Embedder-Policy ड्रॉपडाउन मेन्यू, Cross-Origin-Embedder-Policy ड्रॉपडाउन मेन्यू, Cross-Origin-Embedder-Policy चेकबॉक्स वगैरह किस तरह लोड होने वाले संसाधनों पर असर डालते हैं. साथ ही, यह देखने के लिए रिपोर्टिंग एंडपॉइंट का डेमो खोलें कि ब्लॉक किए गए रिसॉर्स की शिकायत की गई है या नहीं.
क्रॉस-ऑरिजिन आइसोलेशन चालू करें
Cross-Origin-Opener-Policy: same-origin
के साथ Cross-Origin-Embedder-Policy: require-corp
भेजकर, क्रॉस-ऑरिजिन आइसोलेशन चालू करें.
Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin
COEP के साथ काम न करने वाले संसाधनों की शिकायत करें
Reporting API की मदद से, सीओईपी की वजह से ब्लॉक किए गए रिसॉर्स की रिपोर्ट पाई जा सकती है.
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"
COEP यानी सीओईपी भी रिपोर्ट-ओनली मोड में काम करता है, ताकि आप लोड होने वाले रिसॉर्स को ब्लॉक किए बिना रिपोर्ट पा सकें.
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"
इस्तेमाल किए जा सकने वाले ब्राउज़र
ज़्यादा जानें
एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी (एचएसटीएस)
सामान्य एचटीटीपी कनेक्शन पर होने वाली कम्यूनिकेशन को एन्क्रिप्ट (सुरक्षित) नहीं किया जाता. इस वजह से, ट्रांसफ़र किए गए डेटा को नेटवर्क-लेवल पर चोरी करने वाले लोग ऐक्सेस कर सकते हैं.
Strict-Transport-Security
हेडर, ब्राउज़र को बताता है कि उसे साइट को कभी भी एचटीटीपी का इस्तेमाल करके लोड नहीं करना चाहिए और एचटीटीपीएस का इस्तेमाल करना चाहिए. इसे सेट करने के बाद ब्राउज़र, एचटीटीपी के बजाय एचटीटीपीएस का इस्तेमाल करेगा. इससे हेडर में तय की गई अवधि के लिए, रीडायरेक्ट के बिना डोमेन को ऐक्सेस किया जा सकेगा.
इस्तेमाल के उदाहरण
Strict-Transport-Security: max-age=31536000
सुझाए गए इस्तेमाल
एचटीटीपी से एचटीटीपीएस पर ट्रांज़िशन करने वाली सभी वेबसाइटों को एचटीटीपी के साथ अनुरोध मिलने पर, Strict-Transport-Security
हेडर के साथ जवाब देना चाहिए.
Strict-Transport-Security: max-age=31536000
इस्तेमाल किए जा सकने वाले ब्राउज़र