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

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

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas
Maud Nalpas
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';

एचटीएमएल में, स्क्रिप्ट लोड करने के लिए, सभी के nonce एट्रिब्यूट को सेट करें <script> टैग को एक ही {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';

HTML में, हैश-आधारित टैग लागू करने के लिए, आपको अपनी स्क्रिप्ट को इनलाइन करना होगा नीति का पालन नहीं करता, क्योंकि ज़्यादातर ब्राउज़र बाहरी साइट के लिए हैशिंग स्क्रिप्ट.

index.html

<script>
...// your script1, inlined
</script>
<script>
...// your script2, inlined
</script>

एक्सटर्नल स्क्रिप्ट लोड करने के लिए, "सोर्स की गई स्क्रिप्ट को डाइनैमिक तौर पर लोड करें" लेख पढ़ें कम दूसरा विकल्प: हैश पर आधारित सीएसपी रिस्पॉन्स हेडर सेक्शन.

सीएसपी का आकलन करने वाला, इन कामों के लिए एक अच्छा टूल है अपने सीएसपी का आकलन करें. साथ ही, नॉन्स-आधारित सख्त सीएसपी उदाहरण का इस्तेमाल करें. DevTools का इस्तेमाल करके, इसके इस्तेमाल का तरीका देखें.

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

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

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

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

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

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

ये ऑब्जेक्ट बनाने के लिए, सुरक्षा नीतियां बनाई जा सकती हैं. इन नीतियों में, यह पक्का किया जा सकता है कि कि सुरक्षा के नियम (जैसे कि एस्केपिंग या सैनिटाइज़ेशन) हर बार लागू होते हैं DOM में लिखे जाने से पहले. तब ये नीतियां जो 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. खतरनाक DOM सिंक के लिए विश्वसनीय प्रकार लागू करें सीएसपी और भरोसेमंद टाइप का हेडर: 

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

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

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

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

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>credible-types</code> सेट करके, भरोसेमंद टाइप की नीति के तहत दिखने वाले नामों को सीमित कर सकते हैं डायरेक्टिव (उदाहरण के लिए, <code> Trusted-types myPolicy</code>). हालांकि, ऐसा करने की कोई शर्त नहीं होती.  &lt;/aside&gt;


    
  
  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 इसे ब्राउज़र को निर्देश देकर रोकता है कि MIME टाइप, जो दिए गए जवाब के लिए Content-Type हेडर सही है. यह हेडर आपके सभी संसाधनों के लिए सुझाया गया है.

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

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-Frame-Options का इस्तेमाल करने का तरीका

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

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

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

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

X-Frame-Options: 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 ड्रॉपडाउन मेन्यू और इफ़ेक्ट देखने के लिए 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

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

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

  • 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 का ड्रॉपडाउन मेन्यू बदलें पॉप-अप विंडो में, पॉप-अप खोलें बटन पर क्लिक करें. इसके बाद, भेजें postMessage देखें कि क्या मैसेज वाकई डिलीवर हुआ है या नहीं.

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

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

क्रॉस-ऑरिजिन-ओपनर-नीति: एक ही ऑरिजिन 
Cross-Origin-Opener-Policy: same-origin

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

same-origin-allow-popups को सेट करने पर, दस्तावेज़ में रेफ़रंस सेव रहता है इसकी पॉप-अप विंडो, जब तक कि वे COOP को 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 के साथ काम नहीं करते

जब COOP, क्रॉस-विंडो इंटरैक्शन को रोकता है, तब आपको रिपोर्ट मिल सकती हैं रिपोर्टिंग एपीआई.

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

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.

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

सामान्य अनुरोध

जब कोई अनुरोध सामान्य अनुरोध मानदंड से मेल खाता है, तो ब्राउज़र 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 HTTP हेडर को का पालन नहीं करता है.

रिस्पॉन्स हेडर का उदाहरण

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 और जब तक ये संसाधन साफ़ तौर पर CORS के ज़रिए लोड किए जाने के लिए ऑप्ट इन नहीं करते या CORP हेडर का इस्तेमाल करें. सीओईपी कोCross-Origin-Opener-Policy के साथ जोड़ा जा सकता है ताकि किसी दस्तावेज़ को क्रॉस-ऑरिजिन आइसोलेशन में शामिल किया जा सके.

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

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

Cross-Origin-Embedder-Policy: require-corp
COEP को इस्तेमाल करने का तरीका

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

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

सीओईपी के काम करने का तरीका

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

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

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

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

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

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

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

सोर्स

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

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

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

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

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

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

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

Strict-Transport-Security: max-age=31536000

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

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

  • 4
  • 12
  • 4
  • 7

सोर्स

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

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