ข้อมูลอ้างอิงด่วนของส่วนหัวการรักษาความปลอดภัย

ดูข้อมูลเพิ่มเติมเกี่ยวกับส่วนหัวที่จะช่วยรักษาความปลอดภัยของเว็บไซต์และค้นหารายละเอียดที่สำคัญที่สุดได้อย่างรวดเร็ว

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas

บทความนี้แสดงรายการส่วนหัวด้านความปลอดภัยที่สำคัญที่สุดที่คุณใช้เพื่อปกป้อง เว็บไซต์ได้ ใช้เพื่อทำความเข้าใจฟีเจอร์ความปลอดภัยบนเว็บ เรียนรู้วิธี ติดตั้งใช้งานในเว็บไซต์ และใช้เป็นข้อมูลอ้างอิงเมื่อคุณต้องการการแจ้งเตือน

ส่วนหัวด้านความปลอดภัยที่แนะนำสำหรับเว็บไซต์ที่จัดการข้อมูลผู้ใช้ที่ละเอียดอ่อนมีดังนี้
นโยบายรักษาความปลอดภัยเนื้อหา (CSP)
ประเภทที่เชื่อถือได้
ส่วนหัวด้านความปลอดภัยที่แนะนำสำหรับทุกเว็บไซต์
X-Content-Type-Options
X-Frame-Options
นโยบายทรัพยากรแบบข้ามต้นทาง (CORP)
นโยบายการเปิดแบบข้ามต้นทาง (COOP)
HTTP Strict Transport Security (HSTS)
ส่วนหัวด้านความปลอดภัยสำหรับเว็บไซต์ที่มีความสามารถขั้นสูงมีดังนี้
กลไกการแชร์ทรัพยากรข้ามโดเมน (CORS)
นโยบายเครื่องมือฝังแบบข้ามต้นทาง (COEP)
ภัยคุกคามที่ทราบบนเว็บ
ก่อนที่จะเจาะลึกเรื่องส่วนหัวด้านความปลอดภัย โปรดดูข้อมูลเกี่ยวกับภัยคุกคามที่ทราบบนเว็บ และเหตุผลที่คุณควรใช้ส่วนหัวด้านความปลอดภัยเหล่านี้

ก่อนที่จะเจาะลึกเรื่องส่วนหัวด้านความปลอดภัย โปรดดูข้อมูลเกี่ยวกับภัยคุกคามที่ทราบกันดีบนเว็บ และเหตุผลที่คุณควรใช้ส่วนหัวด้านความปลอดภัยเหล่านี้

ปกป้องเว็บไซต์จากช่องโหว่ด้านการแทรก

ช่องโหว่การแทรกเกิดขึ้นเมื่อข้อมูลที่ไม่น่าเชื่อถือซึ่งแอปพลิเคชันของคุณประมวลผลอาจส่งผลต่อลักษณะการทำงานของแอปพลิเคชัน และโดยทั่วไปแล้วจะนำไปสู่การดำเนินการสคริปต์ที่ผู้โจมตีควบคุม ช่องโหว่ที่พบบ่อยที่สุดซึ่งเกิดจากข้อบกพร่องในการแทรกคือ Cross-Site Scripting (XSS) ใน รูปแบบต่างๆ รวมถึง XSS ที่สะท้อน XSS ที่จัดเก็บ XSS ที่อิงตาม DOM และ รูปแบบอื่นๆ

โดยปกติแล้ว ช่องโหว่ XSS จะทำให้ผู้โจมตีมีสิทธิ์เข้าถึงข้อมูลผู้ใช้ทั้งหมด ที่แอปพลิเคชันประมวลผล รวมถึงข้อมูลอื่นๆ ที่โฮสต์ในเว็บ ต้นทางเดียวกัน

การป้องกันการแทรกแบบดั้งเดิม ได้แก่ การใช้ระบบเทมเพลต HTML ที่มีการหลีกเลี่ยงอักขระโดยอัตโนมัติอย่างสม่ำเสมอ การหลีกเลี่ยงการใช้ JavaScript API ที่เป็นอันตราย และการประมวลผลข้อมูลผู้ใช้อย่างเหมาะสมโดยการโฮสต์ การอัปโหลดไฟล์ในโดเมนแยกต่างหากและการล้างข้อมูล HTML ที่ผู้ใช้ควบคุม

  • ใช้นโยบายรักษาความปลอดภัยเนื้อหา (CSP) เพื่อควบคุมสคริปต์ที่แอปพลิเคชันเรียกใช้ได้ เพื่อลดความเสี่ยงของการแทรก
  • ใช้ Trusted Types เพื่อบังคับใช้การล้างข้อมูลที่ส่งไปยัง JavaScript API ที่เป็นอันตราย
  • ใช้ X-Content-Type-Options เพื่อป้องกันไม่ให้เบราว์เซอร์ ตีความประเภท MIME ของทรัพยากรในเว็บไซต์ผิด ซึ่งอาจทำให้ มีการเรียกใช้สคริปต์

แยกเว็บไซต์ของคุณออกจากเว็บไซต์อื่นๆ

ความเปิดกว้างของเว็บทำให้เว็บไซต์โต้ตอบกันได้ในลักษณะที่ อาจละเมิดความคาดหวังด้านความปลอดภัยของแอปพลิเคชัน ซึ่งรวมถึงการส่งคำขอที่ผ่านการตรวจสอบสิทธิ์โดยไม่คาดคิด หรือการฝังข้อมูลจากแอปพลิเคชันอื่นในเอกสารของผู้โจมตี ซึ่งทำให้ผู้โจมตีแก้ไขหรืออ่านข้อมูลแอปพลิเคชันได้

ช่องโหว่ที่พบบ่อยซึ่งบ่อนทำลายการแยกเว็บ ได้แก่ Clickjacking, การปลอมแปลงคำขอแบบข้ามเว็บไซต์ (CSRF), การรวม Cross-site Scripting (XSSI) และการรั่วไหลแบบข้ามเว็บไซต์ต่างๆ

การพัฒนาเว็บหลัง Spectreเป็นบทความที่น่าอ่าน หากคุณสนใจส่วนหัวเหล่านี้

สร้างเว็บไซต์ที่ทรงพลังอย่างปลอดภัย

Spectre จะใส่ข้อมูลที่โหลด ลงในกลุ่มบริบทการท่องเว็บเดียวกัน ซึ่งอาจอ่านได้ แม้จะมีนโยบายต้นทางเดียวกันก็ตาม เบราว์เซอร์จะจำกัดฟีเจอร์ ที่อาจใช้ช่องโหว่ในสภาพแวดล้อมพิเศษที่เรียกว่า "การแยกแบบข้ามต้นทาง" การแยกต้นทางข้ามช่วยให้คุณ ใช้ฟีเจอร์ที่มีประสิทธิภาพ เช่น SharedArrayBuffer ได้

เข้ารหัสการเข้าชมเว็บไซต์

ปัญหาการเข้ารหัสจะเกิดขึ้นเมื่อแอปพลิเคชันไม่ได้เข้ารหัสข้อมูลอย่างเต็มรูปแบบใน การรับส่ง ทำให้ผู้โจมตีที่ดักฟังสามารถทราบข้อมูลเกี่ยวกับการโต้ตอบของผู้ใช้ กับแอปพลิเคชัน

การเข้ารหัสไม่เพียงพออาจเกิดขึ้นในกรณีต่อไปนี้ ไม่ได้ใช้ HTTPS เนื้อหาผสม การตั้งค่าคุกกี้โดยไม่มีแอตทริบิวต์ Secure (หรือคำนำหน้า __Secure) หรือตรรกะการตรวจสอบ CORS แบบหลวมๆ

นโยบายรักษาความปลอดภัยเนื้อหา (CSP)

Cross-site Scripting (XSS) คือการโจมตี ที่ช่องโหว่ในเว็บไซต์อนุญาตให้แทรกและ เรียกใช้สคริปต์ที่เป็นอันตราย

Content-Security-Policy ช่วยเพิ่มการป้องกันเพื่อลดการโจมตี XSS โดย จำกัดสคริปต์ที่หน้าเว็บสามารถเรียกใช้ได้

เราขอแนะนำให้เปิดใช้ CSP ที่เข้มงวดโดยใช้วิธีใดวิธีหนึ่งต่อไปนี้

  • หากแสดงหน้า HTML ในเซิร์ฟเวอร์ ให้ใช้ CSP แบบเข้มงวดที่อิงตาม Nonce
  • หากต้องแสดงหรือแคช HTML แบบคงที่ เช่น หากเป็นแอปพลิเคชันหน้าเว็บเดียว ให้ใช้ CSP แบบเข้มงวดที่อิงตามแฮช

ตัวอย่างการใช้งาน: CSP ที่อิงตาม Nonce

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
วิธีใช้ CSP

1. ใช้ CSP ที่เข้มงวดตาม Nonce {: #nonce-based-csp}

หากแสดงหน้า HTML ในเซิร์ฟเวอร์ ให้ใช้ CSP แบบเข้มงวดที่อิงตาม Nonce

สร้างค่า Nonce ของสคริปต์ใหม่สำหรับทุกคำขอในฝั่งเซิร์ฟเวอร์และตั้งค่าส่วนหัวต่อไปนี้

ไฟล์การกำหนดค่าเซิร์ฟเวอร์

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

ใน HTML หากต้องการโหลดสคริปต์ ให้ตั้งค่าแอตทริบิวต์ 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 เป็นตัวอย่าง CSP แบบเข้มงวดที่อิงตาม Nonce ที่ดี ใช้เครื่องมือสำหรับนักพัฒนาเว็บเพื่อดูวิธีใช้งาน

2. ใช้ CSP ที่เข้มงวดตามแฮช {: #hash-based-csp}

หากต้องแสดงผลหรือแคช HTML แบบคงที่ เช่น หากคุณกำลังสร้างแอปพลิเคชันหน้าเว็บเดียว ให้ใช้ 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>

หากต้องการโหลดสคริปต์ภายนอก โปรดอ่าน "โหลดสคริปต์ที่มาจากแหล่งที่มาแบบไดนามิก" ในส่วนตัวเลือกที่ 2: ส่วนหัวการตอบกลับ CSP ที่อิงตามแฮช

เครื่องมือประเมิน CSP เป็นเครื่องมือที่ดีในการประเมิน CSP ของคุณ และในขณะเดียวกันก็เป็นตัวอย่าง CSP แบบเข้มงวดที่อิงตาม Nonce ที่ดีด้วย ใช้เครื่องมือสำหรับนักพัฒนาเว็บเพื่อดูวิธีใช้งาน

เบราว์เซอร์ที่รองรับ

สิ่งอื่นๆ ที่ควรทราบเกี่ยวกับ CSP

  • frame-ancestors ช่วยปกป้องเว็บไซต์ของคุณจากการคลิกแจ็กกิ้ง ซึ่งเป็นความเสี่ยงที่เกิดขึ้นหากคุณอนุญาตให้ เว็บไซต์ที่ไม่น่าเชื่อถือฝังเว็บไซต์ของคุณ หากต้องการโซลูชันที่ง่ายกว่า คุณสามารถใช้ X-Frame-Options เพื่อบล็อกไม่ให้โหลดได้ แต่ frame-ancestors จะให้ การกำหนดค่าขั้นสูงแก่คุณเพื่ออนุญาตเฉพาะต้นทางที่เฉพาะเจาะจงเป็นผู้ฝังเท่านั้น
  • คุณอาจใช้ CSP เพื่อให้มั่นใจว่าทรัพยากรทั้งหมดของเว็บไซต์จะ โหลดผ่าน HTTPS ซึ่งปัจจุบัน ไม่ค่อยเกี่ยวข้องแล้ว เนื่องจากปัจจุบันเบราว์เซอร์ส่วนใหญ่บล็อก เนื้อหาแบบผสม
  • คุณยังตั้งค่า CSP ในโหมดรายงานเท่านั้นได้ด้วย
  • หากตั้งค่า CSP เป็นส่วนหัวฝั่งเซิร์ฟเวอร์ไม่ได้ คุณก็ตั้งค่าเป็นเมตาแท็กได้เช่นกัน โปรดทราบว่าคุณไม่สามารถใช้โหมดรายงานเท่านั้นสำหรับแท็กเมตา (แม้ว่าอาจมีการเปลี่ยนแปลง)

ดูข้อมูลเพิ่มเติม

Trusted Types

XSS ที่อิงตาม DOM คือการโจมตีที่ส่งข้อมูลที่เป็นอันตรายไปยัง Sink ที่รองรับการเรียกใช้โค้ดแบบไดนามิก เช่น eval() หรือ .innerHTML

Trusted Types มีเครื่องมือสำหรับเขียน ตรวจสอบความปลอดภัย และดูแลรักษา แอปพลิเคชันที่ไม่มี DOM XSS คุณเปิดใช้ได้ผ่าน CSP และทำให้โค้ด JavaScript ปลอดภัยโดยค่าเริ่มต้นด้วยการจำกัด Web API ที่เป็นอันตรายให้ยอมรับเฉพาะออบเจ็กต์พิเศษ ซึ่งก็คือ Trusted Type

หากต้องการสร้างออบเจ็กต์เหล่านี้ คุณสามารถกำหนดนโยบายความปลอดภัยเพื่อให้มั่นใจได้ว่า จะมีการใช้กฎความปลอดภัย (เช่น การหลีกเลี่ยงหรือการล้างข้อมูล) อย่างสม่ำเสมอ ก่อนที่จะเขียนข้อมูลลงใน 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;
วิธีใช้ Trusted Types

  1. บังคับใช้ Trusted Types สำหรับ DOM Sink ที่เป็นอันตราย ส่วนหัว CSP และ Trusted Types: 

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

    ปัจจุบัน 'script' เป็นค่าเดียวที่ยอมรับได้สำหรับ คำสั่ง require-trusted-types-for

    แน่นอนว่าคุณสามารถรวม Trusted Types กับคำสั่ง CSP อื่นๆ ได้

การผสาน CSP ที่อิงตาม Nonce จากด้านบนกับ Trusted Types 

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




<aside class="note"><b>หมายเหตุ: </b> คุณอาจจำกัดชื่อนโยบาย Trusted Types ที่อนุญาตได้โดยการตั้งค่าคำสั่ง <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

เมื่อมีการแสดงเอกสาร HTML ที่เป็นอันตรายจากโดเมนของคุณ (เช่น หากรูปภาพที่อัปโหลดไปยังบริการรูปภาพมีมาร์กอัป HTML ที่ถูกต้อง) เบราว์เซอร์บางตัวจะถือว่าเป็นเอกสารที่ใช้งานอยู่และอนุญาตให้เรียกใช้สคริปต์ในบริบทของแอปพลิเคชัน ซึ่งจะทำให้เกิดCross-site Scripting bug

X-Content-Type-Options: nosniff ป้องกันโดยการสั่งให้เบราว์เซอร์ทราบว่าประเภท MIME ที่ตั้งค่าไว้ในส่วนหัว Content-Type สำหรับการตอบกลับที่ระบุนั้นถูกต้อง เราขอแนะนำให้ใช้ส่วนหัวนี้กับทรัพยากรทั้งหมด

ตัวอย่างการใช้งาน

X-Content-Type-Options: nosniff
วิธีใช้ X-Content-Type-Options

X-Content-Type-Options: nosniff ขอแนะนำสำหรับทรัพยากรทั้งหมดที่แสดงจากเซิร์ฟเวอร์ของคุณพร้อมกับส่วนหัว Content-Type ที่ถูกต้อง

X-Content-Type-Options: nosniff

ตัวอย่างส่วนหัวที่ส่งพร้อมกับ HTML ของเอกสาร

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

เบราว์เซอร์ที่รองรับ

Browser Support

  • Chrome: 64.
  • Edge: 12.
  • Firefox: 50.
  • Safari: 11.

Source

ดูข้อมูลเพิ่มเติม

X-Frame-Options

หากเว็บไซต์ที่เป็นอันตรายฝังเว็บไซต์ของคุณเป็น iframe ได้ ก็อาจทําให้ผู้โจมตีเรียกใช้การกระทําที่ผู้ใช้ไม่ได้ตั้งใจด้วยการคลิกแจ็คกิ้ง นอกจากนี้ ในบางกรณีการโจมตีประเภท Spectre ยังเปิดโอกาสให้เว็บไซต์ที่เป็นอันตรายได้เรียนรู้เกี่ยวกับเนื้อหาของเอกสารที่ฝังไว้ด้วย

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

เบราว์เซอร์ที่รองรับ

Browser Support

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

Source

ดูข้อมูลเพิ่มเติม

นโยบายทรัพยากรแบบข้ามต้นทาง (CORP)

ผู้โจมตีสามารถฝังทรัพยากรจากต้นทางอื่น เช่น จากเว็บไซต์ของคุณ เพื่อดูข้อมูลเกี่ยวกับทรัพยากรเหล่านั้นโดยการใช้ประโยชน์จากการรั่วไหลข้ามเว็บไซต์บนเว็บ

Cross-Origin-Resource-Policy ช่วยลดความเสี่ยงนี้ด้วยการระบุชุด เว็บไซต์ที่โหลดได้ ส่วนหัวมีค่าได้ 3 ค่า ได้แก่ same-origin, same-site และ cross-origin เราขอแนะนำให้แหล่งข้อมูลทั้งหมดส่งส่วนหัวนี้เพื่อระบุว่าอนุญาตให้เว็บไซต์อื่นๆ โหลดหรือไม่

ตัวอย่างการใช้งาน

Cross-Origin-Resource-Policy: same-origin
วิธีใช้ CORP

เราขอแนะนำให้แสดงทรัพยากรทั้งหมดด้วยส่วนหัว 3 รายการต่อไปนี้

คุณลองดูว่าการกำหนดค่าต่อไปนี้ส่งผลต่อการโหลดทรัพยากรในสภาพแวดล้อม Cross-Origin-Embedder-Policy: require-corp อย่างไรได้ในเดโมนี้ เปลี่ยนเมนูแบบเลื่อนลงของนโยบายการแชร์ทรัพยากรข้ามโดเมน แล้วคลิกปุ่มโหลด iframe ซ้ำหรือโหลดรูปภาพซ้ำเพื่อดูผลลัพธ์

อนุญาตให้โหลดทรัพยากร cross-origin

เราขอแนะนำให้บริการที่คล้าย CDN ใช้ cross-origin กับทรัพยากร (เนื่องจากโดยปกติแล้วหน้าเว็บแบบข้ามต้นทางจะโหลดทรัพยากรเหล่านี้) เว้นแต่จะแสดงผ่าน CORS อยู่แล้วซึ่งมีผลคล้ายกัน

Cross-Origin-Resource-Policy: cross-origin 
Cross-Origin-Resource-Policy: cross-origin

จำกัดทรัพยากรที่จะโหลดจาก same-origin

same-origin ควรใช้กับทรัพยากรที่ตั้งใจให้โหลดเฉพาะในหน้าเว็บที่มีต้นทางเดียวกันเท่านั้น คุณควรใช้การตั้งค่านี้กับทรัพยากรที่มีข้อมูลที่ละเอียดอ่อนเกี่ยวกับผู้ใช้ หรือการตอบกลับของ API ที่ตั้งใจจะเรียกจากแหล่งกําเนิดเดียวกันเท่านั้น

โปรดทราบว่ายังคงโหลดทรัพยากรที่มีส่วนหัวนี้ได้โดยตรง เช่น โดยการไปยัง URL ในหน้าต่างเบราว์เซอร์ใหม่ นโยบายการแชร์ทรัพยากรข้ามโดเมน จะปกป้องทรัพยากรจากการฝังโดยเว็บไซต์อื่นๆ เท่านั้น

Cross-Origin-Resource-Policy: same-origin 
Cross-Origin-Resource-Policy: same-origin

จำกัดทรัพยากรที่จะโหลดจาก same-site

same-site ขอแนะนำให้ใช้กับทรัพยากรที่คล้ายกับด้านบน แต่มีไว้เพื่อให้โดเมนย่อยอื่นๆ ของเว็บไซต์โหลด

Cross-Origin-Resource-Policy: same-site 
Cross-Origin-Resource-Policy: same-site

เบราว์เซอร์ที่รองรับ

Browser Support

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

Source

ดูข้อมูลเพิ่มเติม

นโยบายเครื่องมือเปิดแบบข้ามต้นทาง (COOP)

เว็บไซต์ของผู้โจมตีสามารถเปิดเว็บไซต์อื่นในหน้าต่างป๊อปอัปเพื่อดูข้อมูลเกี่ยวกับเว็บไซต์นั้นได้โดยการใช้ประโยชน์จากการรั่วไหลข้ามเว็บไซต์บนเว็บ ในบางกรณี การดำเนินการนี้อาจอนุญาตให้ ใช้ประโยชน์จากการโจมตีแบบช่องทางด้านข้างโดยอิงตาม Spectre ด้วย

ส่วนหัว Cross-Origin-Opener-Policy ช่วยให้เอกสารแยกตัวเองออกจากหน้าต่างข้ามต้นทางที่เปิดผ่าน window.open() หรือลิงก์ที่มี target="_blank" โดยไม่มี rel="noopener" ด้วยเหตุนี้ ตัวเปิดข้ามต้นทางของเอกสารจึงไม่มีการอ้างอิงถึงเอกสารดังกล่าวและจะโต้ตอบกับเอกสารไม่ได้

ตัวอย่างการใช้งาน

Cross-Origin-Opener-Policy: same-origin-allow-popups
วิธีใช้ COOP

คุณลองดูว่าการกำหนดค่าต่อไปนี้ส่งผลต่อการสื่อสารกับหน้าต่างป๊อปอัปข้ามต้นทางอย่างไรได้ในการสาธิตนี้ เปลี่ยนเมนูแบบเลื่อนลง Cross-Origin-Opener-Policy สำหรับทั้งเอกสาร และหน้าต่างป๊อปอัป คลิกปุ่มเปิดป๊อปอัป แล้วคลิกส่ง postMessage เพื่อดูว่าข้อความส่งถึงจริงหรือไม่

แยกเอกสารออกจากหน้าต่างแบบข้ามต้นทาง

การตั้งค่า same-origin จะทำให้เอกสารแยกออกจากหน้าต่างเอกสารแบบข้ามต้นทาง

Cross-Origin-Opener-Policy: same-origin 
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 
Cross-Origin-Opener-Policy: same-origin-allow-popups

อนุญาตให้หน้าต่างแบบข้ามต้นทางอ้างอิงเอกสาร

unsafe-none เป็นค่าเริ่มต้น แต่คุณระบุอย่างชัดเจนได้ว่าหน้าต่างแบบข้ามต้นทางสามารถเปิดเอกสารนี้และยังคงสิทธิ์เข้าถึงร่วมกันได้

Cross-Origin-Opener-Policy: unsafe-none 
Cross-Origin-Opener-Policy: unsafe-none

รูปแบบรายงานที่ใช้ร่วมกับ COOP ไม่ได้

คุณจะได้รับรายงานเมื่อ COOP ป้องกันการโต้ตอบข้ามหน้าต่างด้วย Reporting API 

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

นอกจากนี้ COOP ยังรองรับโหมดรายงานเท่านั้นเพื่อให้คุณรับรายงานได้โดยไม่ต้อง บล็อกการสื่อสารระหว่างเอกสารแบบข้ามต้นทางจริงๆ

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

เบราว์เซอร์ที่รองรับ

Browser Support

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

Source

ดูข้อมูลเพิ่มเติม

กลไกการแชร์ทรัพยากรข้ามโดเมน (CORS)

กลไกการแชร์ทรัพยากรข้ามโดเมน (CORS) ไม่ใช่ส่วนหัว แต่เป็นกลไกของเบราว์เซอร์ที่ขอและอนุญาตให้เข้าถึงทรัพยากรข้ามโดเมน ซึ่งแตกต่างจากรายการอื่นๆ ในบทความนี้

โดยค่าเริ่มต้น เบราว์เซอร์จะบังคับใช้นโยบายต้นทางเดียวกันเพื่อ ป้องกันไม่ให้หน้าเว็บเข้าถึงทรัพยากรแบบข้ามต้นทาง เช่น เมื่อโหลดรูปภาพจากต่างโดเมน แม้ว่าจะแสดงในหน้าเว็บแบบภาพ แต่ JavaScript ในหน้าเว็บจะไม่มีสิทธิ์เข้าถึงข้อมูลของรูปภาพ ผู้ให้บริการทรัพยากรสามารถผ่อนปรนข้อจำกัดและอนุญาตให้เว็บไซต์อื่นๆ อ่านทรัพยากรได้โดยเลือกใช้ CORS

ตัวอย่างการใช้งาน

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
วิธีใช้ CORS

ก่อนที่จะดูวิธีกำหนดค่า CORS คุณควรทำความเข้าใจความแตกต่างระหว่างประเภทคำขอก่อน คำขอจะได้รับการจัดประเภทเป็นคำขออย่างง่ายหรือคำขอ Preflight ทั้งนี้ขึ้นอยู่กับรายละเอียดคำขอ

เกณฑ์สำหรับคำขออย่างง่าย

  • วิธีการคือ GET, HEAD หรือ POST
  • ส่วนหัวที่กำหนดเองจะมีเพียง Accept, Accept-Language, Content-Language และ Content-Type
  • Content-Type คือ application/x-www-form-urlencoded multipart/form-data หรือ text/plain

ส่วนคำขออื่นๆ ทั้งหมดจะได้รับการจัดประเภทเป็นคำขอก่อนส่ง ดูรายละเอียดเพิ่มเติมได้ที่กลไกการแชร์ทรัพยากรข้ามโดเมน (CORS) - HTTP | 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 อย่างไรในการสาธิต นี้ คลิกช่องทําเครื่องหมายกลไกการแชร์ทรัพยากรข้ามโดเมน แล้วคลิกปุ่มโหลดรูปภาพอีกครั้ง เพื่อดูเอฟเฟกต์

คำขอ Preflight

คำขอก่อนส่งจะนำหน้าด้วยคำขอ 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 ช่วยให้ผู้ขอตั้งค่าส่วนหัว HTTP 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 แสดงว่าผลลัพธ์ของคำขอที่ส่งก่อน สามารถแคชได้เป็นเวลา 86400 วินาที

เบราว์เซอร์ที่รองรับ

Browser Support

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

Source

ดูข้อมูลเพิ่มเติม

นโยบายเครื่องมือฝังแบบข้ามต้นทาง (COEP)

ระบบจะปิดใช้ฟีเจอร์ต่างๆ เช่น SharedArrayBuffer หรือ performance.measureUserAgentSpecificMemory() โดยค่าเริ่มต้นเพื่อลดความสามารถของการโจมตีที่อิงตาม Spectre ในการ ขโมยทรัพยากรข้ามต้นทาง

Cross-Origin-Embedder-Policy: require-corp ป้องกันไม่ให้เอกสารและ Worker โหลด ทรัพยากรแบบข้ามต้นทาง เช่น รูปภาพ สคริปต์ สไตล์ชีต iframe และ อื่นๆ เว้นแต่ทรัพยากรเหล่านี้จะเลือกให้โหลดผ่านส่วนหัว CORS หรือ CORP อย่างชัดเจน COEP สามารถใช้ร่วมกับCross-Origin-Opener-Policy เพื่อเลือกใช้การแยกแบบข้ามต้นทางในเอกสาร

ใช้ Cross-Origin-Embedder-Policy: require-corp เมื่อต้องการเปิดใช้การแยกแบบข้ามต้นทางสำหรับเอกสาร

ตัวอย่างการใช้งาน

Cross-Origin-Embedder-Policy: require-corp
วิธีใช้ COEP

ตัวอย่างการใช้งาน

COEP ใช้ค่าเดียวของ require-corp การส่งส่วนหัวนี้ช่วยให้คุณ สั่งให้เบราว์เซอร์บล็อกการโหลดทรัพยากรที่ไม่ได้เลือกใช้ผ่าน CORS หรือ CORP

วิธีการทำงานของ COEP

คุณลองดูว่าการกำหนดค่าต่อไปนี้ส่งผลต่อการโหลดทรัพยากรในการ สาธิตนี้อย่างไรได้ เปลี่ยนเมนูแบบเลื่อนลงของ Cross-Origin-Embedder-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

รายงานทรัพยากรที่ใช้ร่วมกับ COEP ไม่ได้

คุณรับรายงานทรัพยากรที่ถูกบล็อกซึ่งเกิดจาก COEP ได้ด้วย Reporting API

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

นอกจากนี้ COEP ยังรองรับโหมดรายงานเท่านั้นเพื่อให้คุณรับรายงานได้โดยไม่ต้องบล็อกการโหลดทรัพยากรจริงๆ 

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

เบราว์เซอร์ที่รองรับ

Browser Support

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

Source

ดูข้อมูลเพิ่มเติม

HTTP Strict Transport Security (HSTS)

การสื่อสารผ่านการเชื่อมต่อ HTTP แบบธรรมดาจะไม่ได้รับการเข้ารหัส ทำให้ผู้ลักลอบขโมยข้อมูลในระดับเครือข่ายเข้าถึงข้อมูลที่โอนได้

ส่วนหัว Strict-Transport-Security จะแจ้งให้เบราว์เซอร์ทราบว่าไม่ควรโหลดเว็บไซต์โดยใช้ HTTP และควรใช้ HTTPS แทน เมื่อตั้งค่าแล้ว เบราว์เซอร์จะใช้ HTTPS แทน HTTP เพื่อเข้าถึงโดเมนโดยไม่มีการเปลี่ยนเส้นทางตามระยะเวลาที่กำหนดไว้ในส่วนหัว

ตัวอย่างการใช้งาน

Strict-Transport-Security: max-age=31536000
วิธีใช้ HSTS

เว็บไซต์ทั้งหมดที่เปลี่ยนจาก HTTP เป็น HTTPS ควรตอบกลับด้วยส่วนหัว Strict-Transport-Security เมื่อได้รับคำขอที่ใช้ HTTP 

Strict-Transport-Security: max-age=31536000

เบราว์เซอร์ที่รองรับ

Browser Support

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

Source

ดูข้อมูลเพิ่มเติม

อ่านเพิ่มเติม