หน้านี้ได้รับการแปลโดย Cloud Translation API

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

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

Eiji Kitamura

Artur Janc

Maud Nalpas

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

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

ใช้ X-Frame-Options เพื่อป้องกันไม่ให้เอกสารของคุณถูกฝังโดย เว็บไซต์ที่เป็นอันตราย
ใช้นโยบายทรัพยากรข้ามโดเมน (CORP) เพื่อป้องกันไม่ให้เว็บไซต์ของคุณ ทรัพยากรไม่รวมอยู่ในเว็บไซต์แบบข้ามต้นทาง
ใช้นโยบายเครื่องมือเปิดแบบข้ามต้นทาง (COOP) เพื่อปกป้องเว็บไซต์ของคุณ จากการโต้ตอบของเว็บไซต์ที่เป็นอันตราย
ใช้การแชร์ทรัพยากรข้ามโดเมน (CORS) เพื่อควบคุมการเข้าถึง ทรัพยากรของเว็บไซต์จากเอกสารข้ามต้นทาง

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

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

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

ใช้นโยบายเครื่องมือฝังข้ามต้นทาง (COEP) ควบคู่ไปกับ COOP เพื่อ เปิดใช้การแยกแบบข้ามต้นทาง

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

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

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

ใช้ความปลอดภัยที่เข้มงวดในการรับส่งข้อมูลแบบ HTTP (HSTS) เพื่อให้บริการ เนื้อหาผ่าน HTTPS

นโยบายรักษาความปลอดภัยเนื้อหา (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 ใช้เครื่องมือสำหรับนักพัฒนาเว็บเพื่อดูลักษณะการใช้งาน

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

* https: เป็นเวอร์ชันสำรองสำหรับ Safari และ unsafe-inline เป็นเบราว์เซอร์สำรองสำหรับเบราว์เซอร์เวอร์ชันเก่า https: และ unsafe-inline ไม่ทำให้นโยบายของคุณปลอดภัยน้อยลงเนื่องจากเบราว์เซอร์ที่รองรับ strict-dynamic จะไม่สนใจนโยบายดังกล่าว โปรดอ่านเพิ่มเติมในเพิ่มโฆษณาสำรองเพื่อรองรับ Safari และเบราว์เซอร์รุ่นเก่า * Safari ยังไม่รองรับ strict-dynamic แต่ CSP ที่เข้มงวดเหมือนในตัวอย่างด้านบนปลอดภัยกว่า CSP ที่อนุญาต (และปลอดภัยกว่าการไม่ CSP เลย) สำหรับผู้ใช้ทุกคน แม้แต่ใน Safari CSP ที่เข้มงวดก็ปกป้องเว็บไซต์ของคุณจากการโจมตี XSS บางประเภท เนื่องจากการมี CSP ดังกล่าวไม่อนุญาตรูปแบบที่ไม่ปลอดภัยบางอย่าง

สิ่งอื่นๆ ที่ควรทราบเกี่ยวกับ 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;

วิธีใช้ประเภทที่เชื่อถือ

การใช้งานที่แนะนำ

บังคับใช้ประเภทที่เชื่อถือสำหรับซิงก์ 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;


  
    กำหนดนโยบาย
    นโยบาย:
   // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}

    หมายเหตุ:  คุณสามารถกำหนดนโยบายโดยใช้ชื่อที่กำหนดเองได้ เว้นแต่คุณจะจำกัดชื่อของนโยบายประเภทที่เชื่อถือได้ที่อนุญาตโดยการตั้งค่าคำสั่ง trusted-types 
  
  
    ใช้นโยบาย
    ใช้นโยบายเมื่อเขียนข้อมูลไปยัง 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 ที่เป็นอันตรายกับสตริงจะส่งผลให้เกิด
      
  

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

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

  ป้องกันช่องโหว่ในการเขียนสคริปต์ข้ามเว็บไซต์ตาม DOM ด้วย Trusted
      ประเภท
  CSP: required-trusted-types-for - HTTP |
      MDN
  CSP: ประเภทที่เชื่อถือ - HTTP |
      MDN
  การสาธิตประเภทที่เชื่อถือได้ - เปิดตัวตรวจสอบเครื่องมือสำหรับนักพัฒนาเว็บและดู
    สิ่งที่เกิดขึ้น



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 ที่ถูกต้อง

ตัวอย่างส่วนหัวที่ส่งพร้อม HTML ของเอกสาร
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        การรองรับเบราว์เซอร์
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  64
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  50
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  11
  
  
        
        
        แหล่งที่มา
        
      
    
    
    
  
ดูข้อมูลเพิ่มเติม

  ตัวเลือก X-Content-Type-Options - HTTP MDN

    
  


ตัวเลือก X-Frame

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

X-Frame-Options ระบุว่าควรอนุญาตให้เบราว์เซอร์แสดงผลหรือไม่
หน้าเว็บใน <frame>, <iframe>, <embed> หรือ <object> เอกสารทั้งหมด
ขอแนะนำให้ส่งส่วนหัวนี้เพื่อระบุว่า
ที่ฝังโดยเอกสารอื่น

หมายเหตุ:  หากต้องการการควบคุมที่ละเอียดยิ่งขึ้น เช่น อนุญาตเฉพาะต้นทางที่เจาะจงให้ฝังเอกสารได้ ให้ใช้คำสั่ง CSP frame-ancestors  

ตัวอย่างการใช้งาน
X-Frame-Options: DENY


  
    
    วิธีใช้ X-Frame-Options


    
      การใช้งานที่แนะนำ
เอกสารทั้งหมดที่ไม่ได้ออกแบบมาให้ฝังควรใช้ส่วนหัว X-Frame-Options
คุณสามารถลองใช้การกำหนดค่าต่อไปนี้ส่งผลต่อการโหลด iframe ใน
    การสาธิต เปลี่ยน X-Frame-Options
  เมนูแบบเลื่อนลง แล้วคลิกปุ่มโหลด iframe ซ้ำ
ป้องกันไม่ให้มีการฝังเว็บไซต์ของคุณโดยเว็บไซต์อื่นๆ
ปฏิเสธการฝังโดยเอกสารอื่น

X-Frame-Options: DENY

ป้องกันไม่ให้มีการฝังเว็บไซต์โดยเว็บไซต์แบบข้ามต้นทาง
อนุญาตให้ฝังโดยเอกสารที่มีต้นทางเดียวกันเท่านั้น
X-Frame-Options: SAMEORIGIN

 เอกสารที่ฝังได้โดยค่าเริ่มต้นหมายความว่านักพัฒนาเว็บจะต้องส่ง DENY หรือ SAMEORIGIN อย่างชัดแจ้งเพื่อหยุดการฝังตัวและปกป้องตนเองจากการโจมตีแบบ Side-channel ทีม Chrome กำลังพิจารณาที่จะเปลี่ยนการบล็อกการฝังเอกสารโดยค่าเริ่มต้นเพื่อให้เว็บไซต์มีความปลอดภัย แม้ว่าจะไม่ได้กำหนดส่วนหัวไว้อย่างชัดเจนก็ตาม ในโลกยุคใหม่นั้น เอกสารจะต้องเลือกใช้การฝังอย่างชัดเจน 
เบราว์เซอร์ที่รองรับ

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        การรองรับเบราว์เซอร์
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
        
        
        แหล่งที่มา
        
      
    
    
    
  
ดูข้อมูลเพิ่มเติม

  ตัวเลือก X-Frame - HTTP

    
  


นโยบายทรัพยากรข้ามโดเมน (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

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

Cross-Origin-Resource-Policy: same-origin

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

วันที่Cross-Origin-Resource-Policy: same-site

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        การรองรับเบราว์เซอร์
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  73
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  74
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
        
        
        แหล่งที่มา
        
      
    
    
    
  
ดูข้อมูลเพิ่มเติม

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

    
  


นโยบายเครื่องมือเปิดแบบข้ามต้นทาง (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: 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 คือค่าเริ่มต้น แต่คุณระบุอย่างชัดแจ้งได้ว่า
  สามารถเปิดเอกสารโดยหน้าต่างข้ามต้นทางและยังคงมีสิทธิ์เข้าถึงร่วมกัน

 unsafe-none คือค่าเริ่มต้นหมายความว่านักพัฒนาเว็บต้องส่ง same-origin หรือ same-origin-allow-popups อย่างชัดแจ้งเพื่อปกป้องเว็บไซต์จากการโจมตีแบบ Side-channel 
วันที่Cross-Origin-Opener-Policy: unsafe-none

หมายเหตุ:  ฟีเจอร์ต่างๆ เช่น SharedArrayBuffer หรือ performance.measureUserAgentSpecificMemory() จะปิดใช้อยู่โดยค่าเริ่มต้น บางเบราว์เซอร์อนุญาตให้คุณใช้ในเบราว์เซอร์ "ข้ามต้นทาง" บริบท ซึ่งกำหนดให้คุณต้องตั้งค่าส่วนหัว COOP และ COEP หากต้องการดูข้อมูลเพิ่มเติม โปรดอ่านการทำเว็บไซต์ให้เป็นแบบ "ข้ามต้นทาง" การใช้ COOP และ COEP 
รูปแบบรายงานเข้ากันไม่ได้กับ COOP
คุณสามารถรับรายงานเมื่อ COOP ป้องกันการโต้ตอบข้ามกรอบเวลากับ
  API การรายงาน
Cross-Origin-Opener-Policy: same-origin; report-to="coop"

COOP ยังสนับสนุนโหมดรายงานเท่านั้นเพื่อให้คุณสามารถรับรายงาน
  บล็อกการสื่อสารระหว่างเอกสารข้ามต้นทางได้
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        การรองรับเบราว์เซอร์
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  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 วินาที

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        การรองรับเบราว์เซอร์
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  3.5
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
        
        
        แหล่งที่มา
        
      
    
    
    
  
ดูข้อมูลเพิ่มเติม

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

    
  


นโยบายเครื่องมือฝังแบบข้ามต้นทาง (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


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

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        การรองรับเบราว์เซอร์
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  15.2
  
  
        
        
        แหล่งที่มา
        
      
    
    
    
  
ดูข้อมูลเพิ่มเติม

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

    
  


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

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        การรองรับเบราว์เซอร์
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  7
  
  
        
        
        แหล่งที่มา
        
      
    
    
    
  
ดูข้อมูลเพิ่มเติม

  การรักษาความปลอดภัย-การขนส่งแบบเข้มงวด -
      HTTP

    
  


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


การพัฒนาเว็บหลังสเปคเตอร์