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

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

एजी कितामुरा
आर्टर जैंक
आर्टर जैन
X GitHub
मॉड नाल्पस
मॉड नाल्पस
X GitHub

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

विश्वसनीय प्रकार

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

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

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

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

Content-Security-Policy: require-trusted-types-for 'script'

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\</g, '&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. खतरनाक डीओएम सिंक के लिए, भरोसेमंद टाइप लागू करें सीएसपी और भरोसेमंद टाइप हेडर 

    Content-Security-Policy: require-trusted-types-for 'script'

    फ़िलहाल, require-trusted-types-for डायरेक्टिव के लिए सिर्फ़ 'script' वैल्यू ही स्वीकार की जाती है.

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

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

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>भरोसेमंद प्रकार</code> डायरेक्टिव (उदाहरण के लिए, <code>untrusted-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. 
    
    नीति लागू करें
    
    
    डीओएम में डेटा लिखते समय, इस नीति का इस्तेमाल करें:
    
   
    // 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-कॉन्टेंट टाइप-विकल्पों को इस्तेमाल करने का तरीका

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

X-कॉन्टेंट टाइप-विकल्प: कोई जवाब न दें

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

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

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

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

  • 64
  • 12
  • 50
  • 11

सोर्स

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

X-फ़्रेम-विकल्प

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

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

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

X-Frame-Options: DENY
X-फ़्रेम-विकल्पों को इस्तेमाल करने का तरीका

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

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

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

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

X-फ़्रेम-विकल्प: DENY 
X-Frame-Options: DENY

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

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

X-Frame-Options: SAMEORIGIN

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

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

  • 4
  • 12
  • 4
  • 4

सोर्स

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

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

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

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

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

Cross-Origin-Resource-Policy: same-origin
सीओआरपी का इस्तेमाल कैसे करें

हमारा सुझाव है कि सभी संसाधनों को, इन तीन हेडर में से किसी एक के साथ दिखाया जाए.

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

संसाधनों को लोड होने की अनुमति दें cross-origin

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

क्रॉस-ऑरिजिन-संसाधन-नीति: क्रॉस-ऑरिजिन 
Cross-Origin-Resource-Policy: cross-origin

same-origin से लोड होने वाले संसाधनों को सीमित करें

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

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

क्रॉस-ऑरिजिन-संसाधन-नीति: समान-ऑरिजिन 
Cross-Origin-Resource-Policy: same-origin

same-site से लोड होने वाले संसाधनों को सीमित करें

हमारा सुझाव है कि आप same-site को उन रिसॉर्स पर लागू करें जो ऊपर दिए गए रिसॉर्स से मिलते-जुलते हैं, लेकिन उन्हें आपकी साइट के अन्य सबडोमेन से लोड करने के लिए बनाया गया है.

क्रॉस-ऑरिजिन-संसाधन-नीति: समान-साइट 
Cross-Origin-Resource-Policy: same-site

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

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

  • 73
  • 79
  • 74
  • 12

सोर्स

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

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

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

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

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

Cross-Origin-Opener-Policy: same-origin-allow-popups
COOP इस्तेमाल करने का तरीका

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

किसी दस्तावेज़ को क्रॉस-ऑरिजिन विंडो से अलग करना

same-origin को सेट करने पर, दस्तावेज़ को क्रॉस-ऑरिजिन दस्तावेज़ विंडो से अलग कर दिया जाता है.

क्रॉस-ऑरिजिन-ओपनर-पॉलिसी: समान-ऑरिजिन 
Cross-Origin-Opener-Policy: same-origin

क्रॉस-ऑरिजिन विंडो से दस्तावेज़ को अलग करना, लेकिन पॉप-अप की अनुमति देना

same-origin-allow-popups को सेट करने पर, दस्तावेज़ अपने पॉप-अप विंडो का रेफ़रंस तब तक सेव रख सकता है, जब तक सीओओपी को same-origin या same-origin-allow-popups के साथ सेट नहीं किया जाता. इसका मतलब है कि same-origin-allow-popups अब भी पॉप-अप विंडो के तौर पर खोले जाने पर, दस्तावेज़ को रेफ़र किए जाने से सुरक्षित रख सकता है. हालांकि, यह अपने पॉप-अप के साथ बातचीत करने की अनुमति दे सकता है.

क्रॉस-ऑरिजिन-ओपनर-पॉलिसी: एक ही मूल की अनुमति वाले पॉप-अप 
Cross-Origin-Opener-Policy: same-origin-allow-popups

क्रॉस-ऑरिजिन विंडो से, दस्तावेज़ का रेफ़रंस देने की अनुमति दें

unsafe-none डिफ़ॉल्ट वैल्यू है, लेकिन आपके पास साफ़ तौर पर यह जानकारी देने का विकल्प होता है कि इस दस्तावेज़ को क्रॉस-ऑरिजिन विंडो से खोला जा सकता है और म्युचुअल ऐक्सेस को बनाए रखा जा सकता है.

क्रॉस-ऑरिजिन-ओपनर-नीति: असुरक्षित कोई नहीं 
Cross-Origin-Opener-Policy: unsafe-none

COOP के साथ काम न करने वाले रिपोर्ट पैटर्न

जब सीओओपी, Reporting API की मदद से क्रॉस-विंडो इंटरैक्शन को रोकता है, तब आपको रिपोर्ट मिल सकती हैं.

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

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

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

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

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

  • 83
  • 83
  • 79
  • 78 जीबी में से

सोर्स

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

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

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

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

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

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

  • 4
  • 12
  • 3.5
  • 4

सोर्स

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

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

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

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

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

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

Cross-Origin-Embedder-Policy: require-corp
COEP का इस्तेमाल कैसे करें

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

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

सीओईपी कैसे काम करता है

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

क्रॉस-ऑरिजिन आइसोलेशन चालू करें

Cross-Origin-Opener-Policy: same-origin के साथ Cross-Origin-Embedder-Policy: require-corp भेजकर, क्रॉस-ऑरिजिन आइसोलेशन चालू करें. 

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

COEP के साथ काम न करने वाले संसाधनों की शिकायत करें

Reporting API की मदद से, सीओईपी की वजह से ब्लॉक किए गए रिसॉर्स की रिपोर्ट पाई जा सकती है.

Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

COEP यानी सीओईपी भी रिपोर्ट-ओनली मोड में काम करता है, ताकि आप लोड होने वाले रिसॉर्स को ब्लॉक किए बिना रिपोर्ट पा सकें.

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

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

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

  • 83
  • 83
  • 79
  • 78 जीबी में से

सोर्स

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

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

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

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

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

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

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

Strict-Transport-Security: max-age=31536000

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

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

  • 4
  • 12
  • 4
  • 7

सोर्स

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

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