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

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

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

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

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

ปกป้องเว็บไซต์ของคุณจากช่องโหว่ในการแทรก

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

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

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

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

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

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

ช่องโหว่ที่พบบ่อยที่บ่อนทำลายการแยกเว็บมีดังนี้ การหลอกให้คลิก, ข้ามเว็บไซต์ คำขอปลอม (CSRF), ข้ามเว็บไซต์ การรวมสคริปต์ (XSSI) และองค์ประกอบที่หลากหลาย การรั่วไหลของข้อมูลข้ามเว็บไซต์

เว็บ Post-Spectre การพัฒนา หากคุณสนใจส่วนหัวเหล่านี้

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

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

เข้ารหัสการเข้าชมไปยังเว็บไซต์ของคุณ

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

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

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

การเขียนสคริปต์ข้ามเว็บไซต์ (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';

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

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>

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

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

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

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

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

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

ประเภทที่เชื่อถือได้

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

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

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

    ใช้นโยบายเมื่อเขียนข้อมูลไปยัง 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 ที่เป็นอันตรายกับสตริงจะส่งผลให้เกิด

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

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

X-Content-Type-Options

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

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: ไม่ทราบ

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

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

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

การรองรับเบราว์เซอร์

  • Chrome: 64
  • ขอบ: 12.
  • Firefox: 50
  • Safari: 11.

แหล่งที่มา

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

X-Frame-Options

หากเว็บไซต์ที่เป็นอันตรายสามารถฝังเว็บไซต์ของคุณเป็น iframe ได้ ผู้โจมตีที่จะเรียกใช้การดำเนินการที่ไม่คาดคิดจากผู้ใช้ การหลอกให้คลิก และในบางกรณี กรณี Spectre-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: DENY
X-Frame-Options: DENY

ป้องกันไม่ให้มีการฝังเว็บไซต์โดยเว็บไซต์แบบข้ามต้นทาง

อนุญาตให้ฝังโดยเอกสารที่มีต้นทางเดียวกันเท่านั้น

X-Frame-Options: SAMEORIGIN

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

การรองรับเบราว์เซอร์

  • Chrome: 4.
  • ขอบ: 12.
  • Firefox: 4.
  • Safari: 4.

แหล่งที่มา

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

นโยบายทรัพยากรข้ามโดเมน (CORP)

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

Cross-Origin-Resource-Policy ช่วยลดความเสี่ยงนี้โดยการระบุชุดของ ที่โหลดปลายทางได้ ส่วนหัวจะใช้ค่าใดค่าหนึ่งจาก 3 ค่าดังนี้ 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

เราขอแนะนำให้บริการแบบ 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: ต้นทางเดียวกัน
Cross-Origin-Resource-Policy: same-origin

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

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

Cross-Origin-Resource-Policy: เว็บไซต์เดียวกัน วันที่
Cross-Origin-Resource-Policy: same-site

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

การรองรับเบราว์เซอร์

  • Chrome: 73
  • ขอบ: 79
  • Firefox: 74
  • Safari: 12.

แหล่งที่มา

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

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

เว็บไซต์ของผู้โจมตีอาจเปิดเว็บไซต์อื่นๆ ในหน้าต่างป๊อปอัปเพื่อดูข้อมูล เกี่ยวกับเรื่องนี้โดยใช้ประโยชน์จากเว็บแบบข้ามเว็บไซต์ การรั่วไหลของข้อมูล ในบางกรณี วิธีนี้อาจทำให้ การแสวงหาประโยชน์จากการโจมตี Side-channels 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: ต้นทางเดียวกัน
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: ป๊อปอัปเดิมต้นทาง-อนุญาต
Cross-Origin-Opener-Policy: same-origin-allow-popups

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

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

Cross-Origin-Opener-Policy: ไม่ปลอดภัย วันที่
Cross-Origin-Opener-Policy: unsafe-none

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

คุณสามารถรับรายงานเมื่อ COOP ป้องกันการโต้ตอบข้ามกรอบเวลากับ API การรายงาน

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

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

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

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

การรองรับเบราว์เซอร์

  • Chrome: 83.
  • ขอบ: 83
  • Firefox: 79
  • Safari: 15.2

แหล่งที่มา

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

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

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

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

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

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

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

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

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

คำขอที่ได้รับการตรวจสอบล่วงหน้า

คำขอที่ตรวจสอบล่วงหน้าจะมีคำขอ 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 วินาที

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

การรองรับเบราว์เซอร์

  • Chrome: 4.
  • ขอบ: 12.
  • Firefox: 3.5.
  • Safari: 4.

แหล่งที่มา

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

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

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

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

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

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

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

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

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

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

คุณสามารถลองใช้การกำหนดค่าต่อไปนี้ส่งผลต่อการโหลดทรัพยากรใน การสาธิต เปลี่ยน 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

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

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

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

นอกจากนี้ COEP ยังรองรับโหมดรายงานเท่านั้น คุณจึงจะได้รับรายงาน บล็อกทรัพยากรการโหลด

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

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

การรองรับเบราว์เซอร์

  • Chrome: 83.
  • ขอบ: 83
  • Firefox: 79
  • Safari: 15.2

แหล่งที่มา

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

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

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

การรองรับเบราว์เซอร์

  • Chrome: 4.
  • ขอบ: 12.
  • Firefox: 4.
  • Safari: 7.

แหล่งที่มา

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

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