सुरक्षा हेडर के बारे में फटाफट जानकारी

उन हेडर के बारे में ज़्यादा जानें जिनसे आपकी साइट सुरक्षित रहती है. साथ ही, सबसे ज़रूरी जानकारी को तुरंत ढूंढा जा सकता है.

Eiji Kitamura

Artur Janc

Maud Nalpas

इस लेख में, सबसे अहम सुरक्षा हेडर की सूची दी गई है. इनका इस्तेमाल करके, अपनी वेबसाइट को सुरक्षित रखा जा सकता है. इसका इस्तेमाल, वेब पर सुरक्षा से जुड़ी सुविधाओं के बारे में जानने के लिए करें. साथ ही, अपनी वेबसाइट पर उन्हें लागू करने का तरीका जानें. इसके अलावा, जब आपको किसी सुविधा के बारे में याद दिलाने की ज़रूरत हो, तब इसे रेफ़रंस के तौर पर इस्तेमाल करें.

उपयोगकर्ता का संवेदनशील डेटा मैनेज करने वाली वेबसाइटों के लिए, सुरक्षा हेडर का सुझाव दिया जाता है:: कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी); भरोसेमंद टाइप
सभी वेबसाइटों के लिए, सुरक्षा हेडर का सुझाव दिया जाता है:: X-Content-Type-Options; X-Frame-Options; Cross-Origin Resource Policy (CORP); Cross-Origin Opener Policy (COOP); HTTP Strict Transport Security (HSTS)
बेहतर सुविधाओं वाली वेबसाइटों के लिए सुरक्षा हेडर:: क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (CORS); क्रॉस-ऑरिजिन एम्बेडर नीति (COEP)

वेब पर मौजूद जाने-पहचाने खतरे

सुरक्षा हेडर के बारे में जानने से पहले, वेब पर मौजूद जाने-पहचाने खतरों के बारे में जानें. साथ ही, यह भी जानें कि आपको इन सुरक्षा हेडर का इस्तेमाल क्यों करना चाहिए.

अपनी साइट को इंजेक्शन की कमज़ोरियों से बचाना

इंजेक्शन से जुड़ी कमज़ोरियां तब पैदा होती हैं, जब आपके ऐप्लिकेशन से प्रोसेस किया गया गैर-भरोसेमंद डेटा, उसके व्यवहार पर असर डाल सकता है. आम तौर पर, इससे हमलावर के कंट्रोल वाली स्क्रिप्ट को एक्ज़ीक्यूट किया जा सकता है. इंजेक्शन बग की वजह से होने वाली सबसे आम समस्या, क्रॉस-साइट स्क्रिप्टिंग (XSS) है. यह कई तरह की होती है. जैसे, रिफ़्लेक्टेड XSS, स्टोर्ड XSS, डीओएम पर आधारित XSS, और अन्य वैरिएंट.

आम तौर पर, XSS की कमज़ोरी की वजह से हमलावर को ऐप्लिकेशन से प्रोसेस किए गए उपयोगकर्ता डेटा का पूरा ऐक्सेस मिल सकता है. साथ ही, उसे उसी वेब ऑरिजिन में होस्ट की गई कोई भी अन्य जानकारी मिल सकती है.

इंजेक्शन से बचाव के लिए, इन तरीकों का इस्तेमाल किया जाता है: एचटीएमएल टेंप्लेट सिस्टम में ऑटोएस्केपिंग का लगातार इस्तेमाल करना, खतरनाक JavaScript API का इस्तेमाल न करना, और उपयोगकर्ता के डेटा को सही तरीके से प्रोसेस करना. इसके लिए, फ़ाइल अपलोड को किसी दूसरे डोमेन में होस्ट करना और उपयोगकर्ता के कंट्रोल वाले एचटीएमएल को सैनिटाइज़ करना ज़रूरी है.

कॉन्टेंट की सुरक्षा के लिए नीति (सीएसपी) का इस्तेमाल करके, यह कंट्रोल करें कि आपके ऐप्लिकेशन में कौनसी स्क्रिप्ट इस्तेमाल की जा सकती हैं. इससे इंजेक्शन के जोखिम को कम किया जा सकता है.
खतरनाक JavaScript API में पास किए गए डेटा को सैनिटाइज़ करने के लिए, भरोसेमंद टाइप का इस्तेमाल करें.
ब्राउज़र को आपकी वेबसाइट के संसाधनों के MIME टाइप की गलत व्याख्या करने से रोकने के लिए, X-Content-Type-Options का इस्तेमाल करें. इससे स्क्रिप्ट को चलाने से रोका जा सकता है.

अपनी साइट को अन्य वेबसाइटों से अलग करना

वेब की ओपननेस की वजह से, वेबसाइटें एक-दूसरे के साथ इस तरह से इंटरैक्ट कर सकती हैं जिससे किसी ऐप्लिकेशन की सुरक्षा से जुड़ी उम्मीदों का उल्लंघन हो सकता है. इसमें अचानक से पुष्टि किए गए अनुरोध करना या हमलावर के दस्तावेज़ में किसी दूसरे ऐप्लिकेशन से डेटा एम्बेड करना शामिल है. इससे हमलावर को ऐप्लिकेशन के डेटा में बदलाव करने या उसे पढ़ने की अनुमति मिल जाती है.

वेब आइसोलेशन को कमज़ोर करने वाले सामान्य जोखिमों में ये शामिल हैं: क्लिकजैकिंग, किसी दूसरी साइट से किए जाने वाले संदिग्ध अनुरोध (सीएसआरएफ़), क्रॉस-साइट स्क्रिप्ट को शामिल करना (एक्सएसएसआई), और अलग-अलग तरह के क्रॉस-साइट लीक.

अपने दस्तावेज़ों को किसी नुकसान पहुंचाने वाली वेबसाइट से एम्बेड होने से रोकने के लिए, X-Frame-Options का इस्तेमाल करें.
क्रॉस-ऑरिजिन रिसॉर्स पॉलिसी (सीओआरपी) का इस्तेमाल करके, अपनी वेबसाइट के संसाधनों को किसी क्रॉस-ऑरिजिन वेबसाइट में शामिल होने से रोकें.
क्रॉस-ऑरिजिन ओपनर नीति (सीओओपी) का इस्तेमाल करके, अपनी वेबसाइट की विंडो को नुकसान पहुंचाने वाली वेबसाइटों के इंटरैक्शन से सुरक्षित रखें.
क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का इस्तेमाल करके, क्रॉस-ऑरिजिन दस्तावेज़ों से अपनी वेबसाइट के रिसॉर्स के ऐक्सेस को कंट्रोल करें.

अगर आपको इन हेडर के बारे में ज़्यादा जानना है, तो Post-Spectre Web Development लेख पढ़ें.

सुरक्षित तरीके से एक दमदार वेबसाइट बनाना

Spectre, लोड किए गए किसी भी डेटा को एक ही ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में डालता है. इससे एक ही ऑरिजिन की नीति का पालन न होने पर भी, डेटा को पढ़ा जा सकता है. ब्राउज़र, उन सुविधाओं पर पाबंदी लगाते हैं जो "क्रॉस-ऑरिजिन आइसोलेशन" नाम के खास एनवायरमेंट की कमज़ोरी का फ़ायदा उठा सकती हैं. क्रॉस-ऑरिजिन आइसोलेशन की मदद से, SharedArrayBuffer जैसी बेहतर सुविधाओं का इस्तेमाल किया जा सकता है.

क्रॉस-ऑरिजिन आइसोलेशन चालू करने के लिए, COOP के साथ क्रॉस-ऑरिजिन एम्बेडर नीति (सीओईपी) का इस्तेमाल करें.

अपनी साइट पर ट्रैफ़िक को एन्क्रिप्ट (सुरक्षित) करना

एन्क्रिप्शन से जुड़ी समस्याएं तब दिखती हैं, जब कोई ऐप्लिकेशन ट्रांज़िट में मौजूद डेटा को पूरी तरह से एन्क्रिप्ट (सुरक्षित) नहीं करता. इससे, हमलावरों को ऐप्लिकेशन के साथ उपयोगकर्ता के इंटरैक्शन के बारे में पता चल जाता है.

इन मामलों में, एन्क्रिप्शन की कमी हो सकती है: एचटीटीपीएस का इस्तेमाल न करना, मिला-जुला कॉन्टेंट, Secure एट्रिब्यूट (या __Secure प्रीफ़िक्स) के बिना कुकी सेट करना या CORS की पुष्टि करने का ढीला लॉजिक.

एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी (एचएसटीएस) का इस्तेमाल करके, अपने कॉन्टेंट को हमेशा एचटीटीपीएस के ज़रिए दिखाएं.

कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी)

क्रॉस-साइट स्क्रिप्टिंग (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> टैग के एट्रिब्यूट को एक ही {RANDOM1} स्ट्रिंग पर सेट करें.nonce

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 का इस्तेमाल करके देखें कि इसका इस्तेमाल कैसे किया जाता है.

इस्तेमाल किए जा सकने वाले ब्राउज़र

* https: Safari के लिए फ़ॉलबैक है और unsafe-inline ब्राउज़र के बहुत पुराने वर्शन के लिए फ़ॉलबैक है. https: और unsafe-inline से आपकी नीति कम सुरक्षित नहीं होती, क्योंकि strict-dynamic के साथ काम करने वाले ब्राउज़र इन्हें अनदेखा कर देंगे. Safari और पुराने ब्राउज़र के साथ काम करने के लिए फ़ॉलबैक जोड़ना लेख में इसके बारे में ज़्यादा पढ़ें. * Safari में, फ़िलहाल strict-dynamic का इस्तेमाल नहीं किया जा सकता. हालांकि, ऊपर दिए गए उदाहरणों में दिखाए गए सख्त सीएसपी, आपकी सभी उपयोगकर्ताओं के लिए, अनुमति वाली सूची वाले सीएसपी से ज़्यादा सुरक्षित होते हैं. साथ ही, ये सीएसपी, किसी भी सीएसपी के न होने से ज़्यादा सुरक्षित होते हैं. Safari में भी, सख्त CSP आपकी साइट को कुछ तरह के XSS हमलों से बचाता है. ऐसा इसलिए होता है, क्योंकि CSP की मौजूदगी की वजह से, असुरक्षित पैटर्न इस्तेमाल करने की अनुमति नहीं मिलती.

सीएसपी के बारे में ध्यान देने वाली अन्य बातें

frame-ancestors डायरेक्टिव, आपकी साइट को क्लिकजैकिंग से बचाता है. यह एक ऐसा जोखिम है जो तब पैदा होता है, जब आपने भरोसेमंद न होने वाली साइटों को अपनी साइट एम्बेड करने की अनुमति दी हो. अगर आपको आसान समाधान चाहिए, तो लोड होने से रोकने के लिए X-Frame-Options का इस्तेमाल किया जा सकता है. हालांकि, frame-ancestors की मदद से, आपको सिर्फ़ कुछ ऑरिजिन को एम्बेडर के तौर पर अनुमति देने के लिए, ऐडवांस कॉन्फ़िगरेशन मिलता है.
आपने सीएसपी का इस्तेमाल किया हो, ताकि आपकी साइट के सभी संसाधन एचटीटीपीएस पर लोड किए जा सकें. यह अब कम काम का है: आजकल, ज़्यादातर ब्राउज़र मिक्स-कॉन्टेंट को ब्लॉक कर देते हैं.
सीएसपी को सिर्फ़ रिपोर्ट करने वाले मोड में भी सेट किया जा सकता है.
अगर सर्वर-साइड पर हेडर के तौर पर सीएसएपी सेट नहीं किया जा सकता, तो इसे मेटा टैग के तौर पर भी सेट किया जा सकता है. ध्यान दें कि मेटा टैग के लिए, सिर्फ़ रिपोर्ट करें मोड का इस्तेमाल नहीं किया जा सकता. हालांकि, इसमें बदलाव हो सकता है.

ज़्यादा जानें

भरोसेमंद टाइप

डीओएम पर आधारित XSS एक ऐसा हमला है जिसमें नुकसान पहुंचाने वाले डेटा को ऐसे सिंक में पास किया जाता है जो डाइनैमिक कोड एक्ज़ीक्यूशन के साथ काम करता है. जैसे, eval() या .innerHTML.

Trusted Types, डीओएम XSS से सुरक्षित ऐप्लिकेशन लिखने, उनकी सुरक्षा की समीक्षा करने, और उन्हें बनाए रखने के लिए टूल उपलब्ध कराते हैं. इन्हें सीएसपी के ज़रिए चालू किया जा सकता है. साथ ही, ये JavaScript कोड को डिफ़ॉल्ट रूप से सुरक्षित बनाते हैं. इसके लिए, ये खतरनाक वेब एपीआई को सिर्फ़ एक खास ऑब्जेक्ट—ट्रस्टेड टाइप स्वीकार करने की अनुमति देते हैं.

इन ऑब्जेक्ट को बनाने के लिए, सुरक्षा नीतियां तय की जा सकती हैं. इन नीतियों में यह पक्का किया जा सकता है कि डेटा को डीओएम में लिखने से पहले, सुरक्षा के नियमों (जैसे कि एस्केपिंग या सैनिटाइज़ेशन) को लगातार लागू किया जाए. इसके बाद, कोड में सिर्फ़ इन जगहों पर डीओएम एक्सएसएस हो सकता है.

इस्तेमाल के उदाहरण

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, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;

भरोसेमंद टाइप इस्तेमाल करने का तरीका

इस्तेमाल के सुझाव

खतरनाक डीओएम सिंक के लिए, Trusted Types लागू करें सीएसपी और Trusted Types हेडर:
```
Content-Security-Policy: require-trusted-types-for 'script'
```
फ़िलहाल, require-trusted-types-for डायरेक्टिव के लिए, 'script' वैल्यू का ही इस्तेमाल किया जा सकता है.

ज़रूर, भरोसेमंद टाइप को अन्य सीएसएपी डायरेक्टिव के साथ जोड़ा जा सकता है:

ऊपर दिए गए, नॉनस पर आधारित CSP को Trusted Types के साथ मर्ज करना:

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;


<aside class="note"><b>ध्यान दें: </b>  <code>trusted-types</code> डायरेक्टिव सेट करके, भरोसेमंद टाइप की अनुमति वाली नीतियों के नाम सीमित किए जा सकते हैं. उदाहरण के लिए, <code>trusted-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, '>');
    }
  });
}
    ध्यान दें:  trusted-types डायरेक्टिव सेट करके, भरोसेमंद टाइप की नीतियों के नामों को सीमित किया जा सकता है. ऐसा न करने पर, अपनी पसंद के हिसाब से नीतियों के नाम तय किए जा सकते हैं. 
  
  
    नीति लागू करना
    डेटा को DOM में लिखते समय नीति का इस्तेमाल करना:
    
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;
    require-trusted-types-for 'script' के साथ, भरोसेमंद टाइप का इस्तेमाल करना ज़रूरी है. स्ट्रिंग के साथ किसी भी खतरनाक DOM API का इस्तेमाल करने पर गड़बड़ी होगी.
  

इस्तेमाल किए जा सकने वाले ब्राउज़र

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  
ज़्यादा जानें

  Trusted Types की मदद से, डीओएम पर आधारित क्रॉस-साइट स्क्रिप्टिंग की कमियों को रोकना
  सीएसपी: require-trusted-types-for - HTTP |
      एमडीएन
  सीएसपी: trusted-types - एचटीटीपी |
      एमडीएन
  भरोसेमंद टाइप का डेमो—DevTools Inspector खोलें और देखें कि क्या हो रहा है



X-Content-Type-Options

जब आपके डोमेन से कोई नुकसान पहुंचाने वाला एचटीएमएल दस्तावेज़ दिखाया जाता है, तो कुछ ब्राउज़र इसे चालू दस्तावेज़ के तौर पर देखते हैं. उदाहरण के लिए, अगर फ़ोटो सेवा पर अपलोड की गई किसी इमेज में मान्य एचटीएमएल मार्कअप शामिल है, तो कुछ ब्राउज़र इसे चालू दस्तावेज़ के तौर पर देखेंगे. साथ ही, वे इसे ऐप्लिकेशन के कॉन्टेक्स्ट में स्क्रिप्ट चलाने की अनुमति देंगे. इससे क्रॉस-साइट स्क्रिप्टिंग बग हो सकता है.

X-Content-Type-Options: nosniff इसे रोकता है. इसके लिए, वह ब्राउज़र को यह निर्देश देता है कि किसी जवाब के लिए Content-Type हेडर में सेट किया गया MIME टाइप सही है. इस हेडर का इस्तेमाल करने का सुझाव आपके सभी संसाधनों के लिए दिया जाता है.

इस्तेमाल का उदाहरण
X-Content-Type-Options: nosniff


  
    
    X-Content-Type-Options का इस्तेमाल कैसे करें


    
      इस्तेमाल के सुझाव
X-Content-Type-Options: nosniff को आपके सर्वर से दिखाए जाने वाले सभी संसाधनों के लिए इस्तेमाल करने का सुझाव दिया जाता है. साथ ही, सही Content-Type हेडर का इस्तेमाल करने का भी सुझाव दिया जाता है.

दस्तावेज़ के एचटीएमएल के साथ भेजे गए हेडर का उदाहरण
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
इस्तेमाल किए जा सकने वाले ब्राउज़र

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        64
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        50
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        11
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
ज़्यादा जानें

  X-Content-Type-Options - HTTP MDN

    
  


X-Frame-Options

अगर कोई नुकसान पहुंचाने वाली वेबसाइट आपकी साइट को iframe के तौर पर एम्बेड कर सकती है, तो इससे हमलावरों को क्लिकजैकिंग की मदद से, उपयोगकर्ता की अनचाही कार्रवाइयां शुरू करने की अनुमति मिल सकती है. साथ ही, कुछ मामलों में स्पेक्ट्र टाइप के हमलों की वजह से, नुकसान पहुंचाने वाली वेबसाइटों को एम्बेड किए गए दस्तावेज़ के कॉन्टेंट के बारे में पता चल जाता है.

X-Frame-Options से पता चलता है कि ब्राउज़र को किसी पेज को <frame>, <iframe>, <embed> या <object> में रेंडर करने की अनुमति दी जानी चाहिए या नहीं. हमारा सुझाव है कि सभी दस्तावेज़ों में यह हेडर शामिल किया जाए. इससे यह पता चलता है कि उन्हें अन्य दस्तावेज़ों में एम्बेड करने की अनुमति है या नहीं.

ध्यान दें:   अगर आपको ज़्यादा कंट्रोल चाहिए, जैसे कि सिर्फ़ किसी खास ऑरिजिन को दस्तावेज़ एम्बेड करने की अनुमति देनी है, तो सीएसपी frame-ancestors डायरेक्टिव का इस्तेमाल करें.  

इस्तेमाल का उदाहरण
X-Frame-Options: DENY


  
    
    X-Frame-Options का इस्तेमाल कैसे करें


    
      इस्तेमाल के सुझाव
जिन दस्तावेज़ों को एम्बेड करने के लिए नहीं बनाया गया है उनमें X-Frame-Options हेडर का इस्तेमाल किया जाना चाहिए.
इस डेमो पर जाकर, यह देखा जा सकता है कि iframe को लोड करने पर, इन कॉन्फ़िगरेशन का क्या असर पड़ता है. X-Frame-Options
  ड्रॉपडाउन मेन्यू को बदलें और आईफ़्रेम को फिर से लोड करें बटन पर क्लिक करें.
यह कुकी, आपकी वेबसाइट को किसी दूसरी वेबसाइट पर एम्बेड किए जाने से बचाती है
किसी अन्य दस्तावेज़ में एम्बेड किए जाने की अनुमति न दें.

X-Frame-Options: DENY
यह कुकी, आपकी वेबसाइट को किसी भी क्रॉस-ऑरिजिन वेबसाइट से एम्बेड किए जाने से बचाती है
सिर्फ़ एक जैसे ऑरिजिन वाले दस्तावेज़ों से एम्बेड करने की अनुमति दें.
X-Frame-Options: SAMEORIGIN
 डिफ़ॉल्ट रूप से दस्तावेज़ों को एम्बेड करने की अनुमति देने का मतलब है कि वेब डेवलपर को एम्बेड करने की सुविधा बंद करने के लिए, साफ़ तौर पर DENY या SAMEORIGIN भेजना होगा. इससे वे साइड-चैनल हमलों से खुद को बचा पाएंगे. Chrome की टीम, डिफ़ॉल्ट रूप से दस्तावेज़ों को एम्बेड करने की सुविधा को ब्लॉक करने पर विचार कर रही है. इससे वेबसाइटें सुरक्षित रहेंगी, भले ही वे हेडर को साफ़ तौर पर सेट न करें. इस नए सिस्टम में, दस्तावेज़ों को एम्बेड करने के लिए, साफ़ तौर पर ऑप्ट-इन करना होगा. 
इस्तेमाल किए जा सकने वाले ब्राउज़र

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
ज़्यादा जानें

  X-Frame-Options - एचटीटीपी

    
  


क्रॉस-ऑरिजिन रिसॉर्स पॉलिसी (सीओआरपी)

हमलावर, किसी दूसरे ऑरिजिन से संसाधन एम्बेड कर सकता है. उदाहरण के लिए, आपकी साइट से. ऐसा करके, वह वेब पर आधारित क्रॉस-साइट लीक का फ़ायदा उठाकर, उन संसाधनों के बारे में जानकारी हासिल कर सकता है.

Cross-Origin-Resource-Policy इस जोखिम को कम करता है. इसके लिए, यह उन वेबसाइटों के बारे में बताता है जिन पर इसे लोड किया जा सकता है. हेडर के लिए, इनमें से कोई एक वैल्यू इस्तेमाल की जा सकती है:
same-origin, same-site, और cross-origin. सभी संसाधनों को यह हेडर भेजने का सुझाव दिया जाता है. इससे यह पता चलता है कि वे अन्य वेबसाइटों से लोड होने की अनुमति देते हैं या नहीं.

इस्तेमाल का उदाहरण
Cross-Origin-Resource-Policy: same-origin


  
    
    CORP का इस्तेमाल कैसे करें


    
      इस्तेमाल के सुझाव
हमारा सुझाव है कि सभी संसाधनों को यहां दिए गए तीन हेडर में से किसी एक के साथ दिखाया जाए.
इस डेमो पर जाकर, यह देखा जा सकता है कि Cross-Origin-Embedder-Policy: require-corp एनवायरमेंट में, संसाधनों को लोड करने पर इन कॉन्फ़िगरेशन का क्या असर पड़ता है. Cross-Origin-Resource-Policy ड्रॉपडाउन मेन्यू में बदलाव करें. इसके बाद, आईफ़्रेम फिर से लोड करें या इमेज फिर से लोड करें बटन पर क्लिक करके देखें कि बदलाव लागू हुआ है या नहीं.

cross-origin को रिसॉर्स लोड करने की अनुमति दें
हमारा सुझाव है कि सीडीएन जैसी सेवाएं, संसाधनों पर cross-origin लागू करें. ऐसा इसलिए, क्योंकि आम तौर पर इन्हें क्रॉस-ऑरिजिन पेजों से लोड किया जाता है. हालांकि, अगर उन्हें CORS का भी ऐसा ही असर होता है.

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
ध्यान दें:  एक ही ऑरिजिन और एक ही साइट के बीच के अंतर के बारे में ज़्यादा जानने के लिए, "एक ही साइट" और "एक ही ऑरिजिन" को समझना लेख पढ़ें. 
इस्तेमाल किए जा सकने वाले ब्राउज़र

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        73
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        74
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
ज़्यादा जानें

  क्रॉस-ऑरिजिन रिसॉर्स पॉलिसी को डिप्लॉय करें
  COOP और COEP का इस्तेमाल करके, अपनी वेबसाइट को "क्रॉस-ऑरिजिन आइसोलेटेड" बनाना
  बेहतर परफ़ॉर्मेंस वाली सुविधाओं के लिए, "क्रॉस-ऑरिजिन आइसोलेटेड" की ज़रूरत क्यों होती है

    
  


क्रॉस-ऑरिजिन ओपनर नीति (सीओओपी)

हमलावर की वेबसाइट, पॉप-अप विंडो में कोई दूसरी साइट खोल सकती है. ऐसा करके, वह वेब पर आधारित क्रॉस-साइट लीक का फ़ायदा उठाकर, उस साइट के बारे में जानकारी इकट्ठा कर सकती है. कुछ मामलों में, इससे Spectre पर आधारित साइड-चैनल हमलों का फ़ायदा उठाया जा सकता है.

Cross-Origin-Opener-Policy हेडर की मदद से, कोई दस्तावेज़ खुद को window.open() या target="_blank" वाले लिंक के ज़रिए खोले गए क्रॉस-ऑरिजिन विंडो से अलग कर सकता है. इसके लिए, rel="noopener" की ज़रूरत नहीं होती. इस वजह से, दस्तावेज़ के किसी भी क्रॉस-ऑरिजिन ओपनर के पास इसका कोई रेफ़रंस नहीं होगा. साथ ही, वह इससे इंटरैक्ट नहीं कर पाएगा.

इस्तेमाल का उदाहरण
Cross-Origin-Opener-Policy: same-origin-allow-popups


  
    
    COOP का इस्तेमाल कैसे करें


    
      इस्तेमाल के सुझाव
इस डेमो पर जाकर, यह देखा जा सकता है कि यहां दिए गए कॉन्फ़िगरेशन, क्रॉस-ऑरिजिन पॉप-अप विंडो के साथ कम्यूनिकेशन पर किस तरह असर डालते हैं.
  दस्तावेज़ और पॉपअप विंडो, दोनों के लिए Cross-Origin-Opener-Policy ड्रॉपडाउन मेन्यू में बदलाव करें. इसके बाद, पॉपअप खोलें बटन पर क्लिक करें. इसके बाद, postMessage भेजें पर क्लिक करके देखें कि मैसेज डिलीवर हुआ है या नहीं.
किसी दस्तावेज़ को क्रॉस-ओरिजिन विंडो से अलग करना
same-origin को सेट करने पर, दस्तावेज़ को क्रॉस-ऑरिजिन दस्तावेज़ विंडो से अलग कर दिया जाता है.

Cross-Origin-Opener-Policy: same-origin
किसी दस्तावेज़ को क्रॉस-ऑरिजिन विंडो से अलग करें, लेकिन पॉप-अप की अनुमति दें
same-origin-allow-popups को सेट करने पर, किसी दस्तावेज़ को अपनी पॉप-अप विंडो का रेफ़रंस बनाए रखने की अनुमति मिलती है. ऐसा तब तक होता है, जब तक वे same-origin या same-origin-allow-popups के साथ COOP सेट नहीं करते. इसका मतलब है कि same-origin-allow-popups, दस्तावेज़ को पॉप-अप विंडो के तौर पर खोले जाने पर, उसे रेफ़रंस के तौर पर इस्तेमाल होने से अब भी बचा सकता है. हालांकि, वह दस्तावेज़ को अपने पॉप-अप के साथ कम्यूनिकेट करने की अनुमति दे सकता है.


Cross-Origin-Opener-Policy: same-origin-allow-popups
किसी दस्तावेज़ को क्रॉस-ऑरिजिन विंडो से रेफ़रंस करने की अनुमति दें
unsafe-none डिफ़ॉल्ट वैल्यू है. हालांकि, यह साफ़ तौर पर बताया जा सकता है कि इस दस्तावेज़ को क्रॉस-ऑरिजिन विंडो से खोला जा सकता है और दोनों के पास एक-दूसरे को ऐक्सेस करने की अनुमति बनी रहेगी.

 unsafe-none को डिफ़ॉल्ट के तौर पर सेट करने का मतलब है कि वेब डेवलपर को साइड-चैनल के हमलों से अपनी वेबसाइट को सुरक्षित रखने के लिए, same-origin या same-origin-allow-popups को साफ़ तौर पर भेजना होगा. 
Cross-Origin-Opener-Policy: unsafe-none
ध्यान दें:  SharedArrayBuffer या performance.measureUserAgentSpecificMemory() जैसी सुविधाएँ डिफ़ॉल्ट रूप से बंद होती हैं. कुछ ब्राउज़र में, इनका इस्तेमाल "क्रॉस-ऑरिजिन आइसोलेटेड" कॉन्टेक्स्ट में किया जा सकता है. इसके लिए, आपको COOP और COEP हेडर सेट करने होंगे. ज़्यादा जानने के लिए, COOP और COEP का इस्तेमाल करके अपनी वेबसाइट को "क्रॉस-ऑरिजिन आइसोलेटेड" बनाना लेख पढ़ें. 
COOP के साथ काम न करने वाले रिपोर्ट पैटर्न
जब COOP, Reporting API के साथ क्रॉस-विंडो इंटरैक्शन को रोकता है, तब आपको रिपोर्ट मिल सकती हैं.
Cross-Origin-Opener-Policy: same-origin; report-to="coop"
COOP में सिर्फ़ रिपोर्ट करने का मोड भी होता है. इससे आपको रिपोर्ट मिल सकती हैं. साथ ही, अलग-अलग ऑरिजिन के दस्तावेज़ों के बीच कम्यूनिकेशन को ब्लॉक नहीं किया जाता.
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
इस्तेमाल किए जा सकने वाले ब्राउज़र

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
ज़्यादा जानें

  बेहतर परफ़ॉर्मेंस वाली सुविधाओं के लिए, "क्रॉस-ऑरिजिन आइसोलेटेड" की ज़रूरत क्यों होती है

    
  


क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस)

इस लेख में दिए गए अन्य आइटम के उलट, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) कोई हेडर नहीं है. यह ब्राउज़र का एक ऐसा तरीका है जो क्रॉस-ऑरिजिन रिसॉर्स को ऐक्सेस करने का अनुरोध करता है और अनुमति देता है.

डिफ़ॉल्ट रूप से, ब्राउज़र एक ऑरिजिन से दूसरे ऑरिजिन के बीच नेटवर्क मैसेज भेजने से जुड़ी नीति लागू करते हैं. इससे किसी वेब पेज को क्रॉस-ऑरिजिन संसाधनों को ऐक्सेस करने से रोका जा सकता है. उदाहरण के लिए, जब किसी दूसरे ऑरिजिन की इमेज लोड की जाती है, तब वह वेब पेज पर दिखती है. हालांकि, पेज पर मौजूद 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 सेकंड के लिए कैश मेमोरी में सेव किया जा सकता है.

इस्तेमाल किए जा सकने वाले ब्राउज़र

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        3.5
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
ज़्यादा जानें

  क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस)
  क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (CORS) - एचटीटीपी |
      एमडीएन

    
  


क्रॉस-ऑरिजिन एम्बेडर नीति (सीओईपी)

Spectre-based
attacks को क्रॉस-ऑरिजिन रिसॉर्स चुराने से रोकने के लिए, SharedArrayBuffer या performance.measureUserAgentSpecificMemory() जैसी सुविधाएं डिफ़ॉल्ट रूप से बंद होती हैं.

Cross-Origin-Embedder-Policy: require-corp, दस्तावेज़ों और वर्कर को क्रॉस-ऑरिजिन रिसॉर्स लोड करने से रोकता है. जैसे, इमेज, स्क्रिप्ट, स्टाइलशीट, iframe वगैरह. हालांकि, अगर इन रिसॉर्स को CORS या CORP हेडर के ज़रिए लोड करने का विकल्प चुना जाता है, तो इन्हें लोड किया जा सकता है. COEP को Cross-Origin-Opener-Policy के साथ मिलाकर, किसी दस्तावेज़ को क्रॉस-ऑरिजिन आइसोलेशन में शामिल किया जा सकता है.

अपने दस्तावेज़ के लिए क्रॉस-ऑरिजिन आइसोलेशन चालू करने के लिए, Cross-Origin-Embedder-Policy: require-corp का इस्तेमाल करें.

इस्तेमाल का उदाहरण
Cross-Origin-Embedder-Policy: require-corp


  
    
    COEP का इस्तेमाल कैसे करें


    
      इस्तेमाल के उदाहरण
COEP के लिए, require-corp की सिर्फ़ एक वैल्यू इस्तेमाल की जा सकती है. इस हेडर को भेजकर, ब्राउज़र को यह निर्देश दिया जा सकता है कि वह उन संसाधनों को लोड करने से रोके जिन्होंने CORS या सीओआरपी के ज़रिए ऑप्ट-इन नहीं किया है.


इस डेमो पर जाकर, यह देखा जा सकता है कि नीचे दिए गए कॉन्फ़िगरेशन से, संसाधनों को लोड करने पर क्या असर पड़ता है. Cross-Origin-Embedder-Policy ड्रॉपडाउन मेन्यू, Cross-Origin-Resource-Policy ड्रॉपडाउन मेन्यू, Report Only चेकबॉक्स वगैरह में बदलाव करके देखें कि इससे रिसॉर्स लोड करने पर क्या असर पड़ता है. यह देखने के लिए कि ब्लॉक किए गए संसाधनों की रिपोर्ट की गई है या नहीं, रिपोर्टिंग एंडपॉइंट का डेमो खोलें.

क्रॉस-ऑरिजिन आइसोलेशन की सुविधा चालू करना
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 की मदद से, COEP की वजह से ब्लॉक किए गए संसाधनों की रिपोर्ट पाई जा सकती हैं.
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"
COEP, report-only मोड के साथ भी काम करता है. इससे आपको रिपोर्ट मिल सकती हैं. हालांकि, इससे रिसॉर्स लोड होने में कोई रुकावट नहीं आती.
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"
इस्तेमाल किए जा सकने वाले ब्राउज़र

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
ज़्यादा जानें

  COOP और COEP का इस्तेमाल करके, अपनी वेबसाइट को "क्रॉस-ऑरिजिन आइसोलेटेड" बनाना
  बेहतर परफ़ॉर्मेंस वाली सुविधाओं के लिए, "क्रॉस-ऑरिजिन आइसोलेटेड" की ज़रूरत क्यों होती है
  क्रॉस-ऑरिजिन आइसोलेशन चालू करने के लिए गाइड

    
  


एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी (एचएसटीएस)

सामान्य एचटीटीपी कनेक्शन पर होने वाले कम्यूनिकेशन को एन्क्रिप्ट (सुरक्षित) नहीं किया जाता. इसलिए, ट्रांसफ़र किए गए डेटा को नेटवर्क-लेवल पर सुनने वाले लोग ऐक्सेस कर सकते हैं.

Strict-Transport-Security हेडर, ब्राउज़र को यह सूचना देता है कि उसे कभी भी एचटीटीपी का इस्तेमाल करके साइट को लोड नहीं करना चाहिए. इसके बजाय, उसे एचटीटीपीएस का इस्तेमाल करना चाहिए. इस नीति को सेट करने के बाद, ब्राउज़र हेडर में तय की गई अवधि के लिए, डोमेन को ऐक्सेस करने के लिए एचटीटीपी के बजाय एचटीटीपीएस का इस्तेमाल करेगा. इसके लिए, उसे रीडायरेक्ट करने की ज़रूरत नहीं होगी.

इस्तेमाल का उदाहरण
Strict-Transport-Security: max-age=31536000


  
    
    एचएसटीएस का इस्तेमाल कैसे करें


    
      इस्तेमाल के सुझाव
एचटीटीपी से एचटीटीपीएस पर स्विच करने वाली सभी वेबसाइटों को, एचटीटीपी का इस्तेमाल करके किए गए अनुरोध के जवाब में Strict-Transport-Security हेडर भेजना चाहिए.

Strict-Transport-Security: max-age=31536000
इस्तेमाल किए जा सकने वाले ब्राउज़र

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        7
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
ज़्यादा जानें

  Strict-Transport-Security -
      HTTP

    
  


इस बारे में और पढ़ें


Post-Spectre Web Development