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

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

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

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

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

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

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

ช่องโหว่ที่พบบ่อยซึ่งบ่อนทำลายการแยกเว็บ ได้แก่ Clickjacking, การปลอมแปลงคำขอแบบข้ามเว็บไซต์ (CSRF), การรวมสคริปต์ข้ามเว็บไซต์ (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>

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

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

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

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

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

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

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

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

Trusted Types มีเครื่องมือในการเขียน ตรวจสอบความปลอดภัย และดูแลรักษาแอปพลิเคชันโดยปราศจาก DOM XSS คุณเปิดใช้ผ่าน CSP และทำให้โค้ด JavaScript ปลอดภัยโดยค่าเริ่มต้นได้โดยจำกัดให้ Web 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. บังคับใช้ Trusted Types สําหรับที่เก็บ DOM ที่อันตราย ส่วนหัว CSP และ Trusted Types: 

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

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

    คุณรวม Trusted Types กับคำสั่ง CSP อื่นๆ ได้โดยทำดังนี้

การผสาน CSP ที่ใช้ Nonce จากด้านบนกับประเภทที่เชื่อถือได้ 

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




<aside class="note"><b>หมายเหตุ: </b> คุณสามารถจํากัดชื่อนโยบายประเภทที่เชื่อถือได้ที่ได้รับอนุญาตได้โดยการตั้งค่าคําแนะนํา <code>trusted-types</code> เพิ่มเติม (เช่น <code>trusted-types myPolicy</code>) แต่นี่ไม่ใช่ข้อกําหนด  </aside>


    
  
  1. 
    
    กําหนดนโยบาย
    
    
    นโยบาย:
    
    
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}
    
    
  
    2. 
  
  2. 
    
    ใช้นโยบาย
    
    
    ใช้นโยบายเมื่อเขียนข้อมูลไปยัง DOM
    
    
    // Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;
    
    
    require-trusted-types-for 'script' กำหนดให้ใช้ประเภทที่เชื่อถือได้ การใช้ DOM API ที่เป็นอันตรายกับสตริงจะทำให้เกิดข้อผิดพลาด
    
  
    3. 



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



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


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

X-Content-Type-Options

เมื่อมีการนําส่งเอกสาร 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: nosniff

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

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

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

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

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

แหล่งที่มา

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

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: DENY 
X-Frame-Options: DENY

ปกป้องเว็บไซต์ของคุณไม่ให้ถูกฝังโดยเว็บไซต์ข้ามแหล่งที่มา

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

X-Frame-Options: SAMEORIGIN

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

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

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

แหล่งที่มา

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

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

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

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

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

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

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

คุณสามารถลองดูว่าการกำหนดค่าต่อไปนี้ส่งผลต่อการโหลดทรัพยากรในสภาพแวดล้อม 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: same-origin 
Cross-Origin-Resource-Policy: same-origin

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

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

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

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

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

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

แหล่งที่มา

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

นโยบายเครื่องมือเปิดแบบข้ามต้นทาง (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: ป๊อปอัปเดิมต้นทาง-อนุญาต 
Cross-Origin-Opener-Policy: same-origin-allow-popups

อนุญาตให้หน้าต่างจากต้นทางอื่นอ้างอิงเอกสาร

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

Cross-Origin-Opener-Policy: ไม่ปลอดภัย 
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"

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

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

  • 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.
  • Edge: 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-Embedder-Policy: require-corp
วิธีใช้ COEP

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

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

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

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

เปิดใช้การแยกแบบข้ามต้นทาง

เปิดใช้การแยกแบบข้ามต้นทางโดยส่ง 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"

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

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

  • 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.

แหล่งที่มา

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

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