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

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

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas
Maud Nalpas
X GitHub

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डीओएम पर आधारित एक्सएसएस एक ऐसा हमला है जिसमें नुकसान पहुंचाने वाले डेटा को ऐसे सिंक में भेजा जाता है जो 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;
भरोसेमंद टाइप इस्तेमाल करने का तरीका

  1. खतरनाक डीओएम सिंक के लिए, 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>


    
  
  1. 
    
    नीति परिभाषित करें
    
    
    नीति:
    
    
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}
    
    
  
    2. 
  
  2. 
    
    नीति लागू करना
    
    
    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 का इस्तेमाल करने से
      गड़बड़ी होगी.
    
  
    3. 



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



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


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

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

दस्तावेज़ के एचटीएमएल के साथ भेजे गए हेडर का उदाहरण

X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

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

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

  • Chrome: 64.
  • Edge: 12.
  • Firefox: 50.
  • सफ़ारी: 11.

सोर्स

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

X-Frame-Options

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

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

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

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

जिन दस्तावेज़ों को एम्बेड करने के लिए डिज़ाइन नहीं किया गया है उनके लिए X-Frame-Options हेडर का इस्तेमाल किया जाना चाहिए.

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

आपकी वेबसाइट को किसी दूसरी वेबसाइट से एम्बेड होने से बचाता है

किसी दूसरे दस्तावेज़ में एम्बेड होने से रोकना.

X-Frame-Options: DENY 
X-Frame-Options: DENY

आपकी वेबसाइट को किसी भी क्रॉस-ऑरिजिन वेबसाइट से एम्बेड होने से बचाता है

सिर्फ़ एक ही ऑरिजिन वाले दस्तावेज़ों को एम्बेड करने की अनुमति दें.

X-Frame-Options: SAMEORIGIN

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

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

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 4.

सोर्स

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

क्रॉस-ओरिजिन रिसॉर्स पॉलिसी (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 
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-Resource-Policy: same-site

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

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

  • Chrome: 73.
  • Edge: 79.
  • Firefox: 74.
  • Safari: 12.

सोर्स

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

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

किसी हमलावर की वेबसाइट वेब-आधारित क्रॉस-साइट लीक का फ़ायदा उठाकर उसके बारे में जानकारी पाने के लिए एक पॉप-अप विंडो में दूसरी साइट खोल सकती है. कुछ मामलों में, इससे 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 
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 
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"

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

Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

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

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

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 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 सेकंड के लिए कैश मेमोरी में सेव किया जा सकता है.

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

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

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 3.5.
  • Safari: 4.

सोर्स

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

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

स्पेक्टर पर आधारित हमलों की वजह से, क्रॉस-ऑरिजिन संसाधनों को हैक करने से रोकने के लिए, 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"

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

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

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

सोर्स

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

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

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

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

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

Strict-Transport-Security: max-age=31536000
एचएसटीएस का इस्तेमाल करने का तरीका

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

Strict-Transport-Security: max-age=31536000

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

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

  • Chrome: 4.
  • एज: 12.
  • Firefox: 4.
  • Safari: 7.

सोर्स

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

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