इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

Eiji Kitamura

Artur Janc

Maud Nalpas

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

उपयोगकर्ता के संवेदनशील डेटा को मैनेज करने वाली वेबसाइटों के लिए सुझाए गए सुरक्षा हेडर:: कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी); भरोसेमंद टाइप
सभी वेबसाइटों के लिए सुझाए गए सुरक्षा हेडर:: X-Content-Type-Options; X-Frame-Options; क्रॉस-ऑरिजिन रिसॉर्स पॉलिसी (सीओआरपी); क्रॉस-ऑरिजिन ओपनर पॉलिसी (सीओओपी); एचटीटीपी स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी (एचएसटीएस)
बेहतर सुविधाओं वाली वेबसाइटों के लिए सुरक्षा हेडर:: क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (CORS); क्रॉस-ऑरिजिन एम्बेडर नीति (COEP)

वेब पर मौजूद खतरे

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

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

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

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

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

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

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

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

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

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

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

अगर आपको इन हेडर के बारे में जानना है, तो पोस्ट-स्पेक्टर वेब डेवलपमेंट एक अच्छा विकल्प है.

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

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

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

अपनी साइट पर आने वाले ट्रैफ़िक को एन्क्रिप्ट करना

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

एन्क्रिप्शन (सुरक्षित) करने की प्रक्रिया पूरी न होने की समस्या इन मामलों में आ सकती है: एचटीटीपीएस का इस्तेमाल न करना, मिश्रित कॉन्टेंट, 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 का इस्तेमाल करके देखें कि इसका इस्तेमाल कैसे किया जाता है.

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

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

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

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

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

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

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

भरोसेमंद टाइप की मदद से, ऐप्लिकेशन में DOM XSS के बिना ऐप्लिकेशन लिखने, सुरक्षा की समीक्षा करने, और उनका रखरखाव करने के लिए टूल मिलते हैं. इन्हें CSP की मदद से चालू किया जा सकता है. साथ ही, 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 के अन्य डायरेक्टिव के साथ जोड़ा जा सकता है:

ऊपर दिए गए, नॉन्स-आधारित सीएसपी को भरोसेमंद टाइप के साथ मर्ज करना:

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 का इस्तेमाल करने से
      गड़बड़ी होगी.
  

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

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

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



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
इस्तेमाल किए जा सकने वाले ब्राउज़र

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        ब्राउज़र सहायता
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        64
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        50
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        11
      
    
  
  
  
        
        
        सोर्स
        
      
    
    
    
  
ज़्यादा जानें

  X-कॉन्टेंट-टाइप-विकल्प - एचटीटीपी एमडीएन

    
  


X-Frame-Options

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

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

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

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


  
    
    X-Frame-Options का इस्तेमाल करने का तरीका


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

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        ब्राउज़र के इस्तेमाल से जुड़ी सहायता
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        सोर्स
        
      
    
    
    
  
ज़्यादा जानें

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

    
  


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

हमलावर, वेब पर आधारित क्रॉस-साइट लीक का गलत इस्तेमाल करके, अन्य ऑरिजिन से रिसॉर्स को एम्बेड कर सकता है, जैसे कि आपकी साइट से.

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 ड्रॉपडाउन मेन्यू में बदलाव करें. इसके बाद, इसका असर देखने के लिए, iframe को फिर से लोड करें या इमेज को फिर से लोड करें बटन पर क्लिक करें.

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        ब्राउज़र के इस्तेमाल से जुड़ी सहायता
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        73
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        74
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
        
        
        सोर्स
        
      
    
    
    
  
ज़्यादा जानें

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

    
  


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

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

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

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


  
    
    सीओओपी का इस्तेमाल करने का तरीका


    
      इस्तेमाल के सुझाव
इस डेमो पर, नीचे दिए गए कॉन्फ़िगरेशन से क्रॉस-ऑरिजिन पॉप-अप विंडो के साथ कम्यूनिकेशन पर पड़ने वाले असर को आज़माया जा सकता है.
  दस्तावेज़ और पॉप-अप विंडो, दोनों के लिए 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 के साथ काम नहीं करते
जब सीओओपी, Reporting API के साथ क्रॉस-विंडो इंटरैक्शन को रोकता है, तो आपको रिपोर्ट मिल सकती हैं.
Cross-Origin-Opener-Policy: same-origin; report-to="coop"
सीओओपी में सिर्फ़ रिपोर्ट मोड भी काम करता है. इससे आपको क्रॉस-ऑरिजिन दस्तावेज़ों के बीच कम्यूनिकेशन को ब्लॉक किए बिना, रिपोर्ट मिल सकती हैं.
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
इस्तेमाल किए जा सकने वाले ब्राउज़र

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        ब्राउज़र के इस्तेमाल से जुड़ी सहायता
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        सोर्स
        
      
    
    
    
  
ज़्यादा जानें

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

    
  


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

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

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

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

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        ब्राउज़र के इस्तेमाल से जुड़ी सहायता
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        3.5
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        सोर्स
        
      
    
    
    
  
ज़्यादा जानें

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

    
  


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

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

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

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

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


  
    
    COEP को इस्तेमाल करने का तरीका


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


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

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        ब्राउज़र के इस्तेमाल से जुड़ी सहायता
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        सोर्स
        
      
    
    
    
  
ज़्यादा जानें

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

    
  


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

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

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

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


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


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

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        ब्राउज़र के इस्तेमाल से जुड़ी सहायता
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        7
      
    
  
  
  
        
        
        सोर्स
        
      
    
    
    
  
ज़्यादा जानें

  सख्त-परिवहन-सुरक्षा -
      एचटीटीपी

    
  


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


Specter के बाद का वेब डेवलपमेंट