ดูข้อมูลเพิ่มเติมเกี่ยวกับส่วนหัวที่ช่วยให้เว็บไซต์ปลอดภัยและค้นหารายละเอียดที่สำคัญที่สุดได้อย่างรวดเร็ว
บทความนี้แสดงส่วนหัวความปลอดภัยที่สำคัญที่สุดที่คุณสามารถใช้เพื่อป้องกัน เว็บไซต์ของคุณ ใช้เพื่อทำความเข้าใจฟีเจอร์ความปลอดภัยบนเว็บ ดูวิธีการ นำไปใช้บนเว็บไซต์ และใช้เป็นข้อมูลอ้างอิงเมื่อคุณต้องการการช่วยเตือน
- ส่วนหัวความปลอดภัยที่แนะนำสำหรับเว็บไซต์ที่จัดการข้อมูลที่ละเอียดอ่อนของผู้ใช้
- นโยบายรักษาความปลอดภัยเนื้อหา (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) และองค์ประกอบที่หลากหลาย การรั่วไหลของข้อมูลข้ามเว็บไซต์
- ใช้ 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';
การใช้งานที่แนะนำ
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, '<').replace(/>/g, '>');
}
});
}
// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.
// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped; // '&lt;img src=x onerror=alert(1)&gt;'
การใช้งานที่แนะนำ
-
บังคับใช้ประเภทที่เชื่อถือสำหรับซิงก์ 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 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
<aside class="note"><b>หมายเหตุ:</b> คุณอาจจำกัดชื่อนโยบายประเภทที่เชื่อถือที่อนุญาตได้โดยการตั้งค่า <code>ประเภทที่เชื่อถือ</code> เพิ่มเติม (ตัวอย่างเช่น <code>trusted-types myPolicy</code>) แต่ก็ไม่ได้ถือเป็นข้อกำหนด </aside>
-
กำหนดนโยบาย
นโยบาย:
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\/g, '>');
}
});
}
-
ใช้นโยบาย
ใช้นโยบายเมื่อเขียนข้อมูลไปยัง DOM
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.</p>
<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src="x" onerror="alert(1)">');
el.innerHTML = escaped; // '<img src=x onerror=alert(1)>'
สำหรับ 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: nosniff
สำหรับทรัพยากรทั้งหมดที่ให้บริการจาก
เซิร์ฟเวอร์ของคุณพร้อมกับส่วนหัว Content-Type
ที่ถูกต้อง
ตัวอย่างส่วนหัวที่ส่งพร้อม HTML ของเอกสาร
X-Content-Type-Options: nosniff Content-Type: text/html; charset=utf-8
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
X-Frame-Options
หากเว็บไซต์ที่เป็นอันตรายสามารถฝังเว็บไซต์ของคุณเป็น iframe ได้ ผู้โจมตีที่จะเรียกใช้การดำเนินการที่ไม่คาดคิดจากผู้ใช้ การหลอกให้คลิก และในบางกรณี กรณี Spectre-type การโจมตีให้ เว็บไซต์ที่เป็นอันตรายมีโอกาสเรียนรู้เกี่ยวกับเนื้อหาในเอกสารที่ฝัง
X-Frame-Options
ระบุว่าควรอนุญาตให้เบราว์เซอร์แสดงผลหรือไม่
หน้าเว็บใน <frame>
, <iframe>
, <embed>
หรือ <object>
เอกสารทั้งหมด
ขอแนะนำให้ส่งส่วนหัวนี้เพื่อระบุว่า
ที่ฝังโดยเอกสารอื่น
ตัวอย่างการใช้งาน
X-Frame-Options: DENY
การใช้งานที่แนะนำ
เอกสารทั้งหมดที่ไม่ได้ออกแบบมาให้ฝังควรใช้ส่วนหัว X-Frame-Options
คุณสามารถลองใช้การกำหนดค่าต่อไปนี้ส่งผลต่อการโหลด iframe ใน
การสาธิต เปลี่ยน X-Frame-Options
เมนูแบบเลื่อนลง แล้วคลิกปุ่มโหลด iframe ซ้ำ
ป้องกันไม่ให้มีการฝังเว็บไซต์ของคุณโดยเว็บไซต์อื่นๆ
ปฏิเสธการฝังโดยเอกสารอื่น
X-Frame-Options: DENY
ป้องกันไม่ให้มีการฝังเว็บไซต์โดยเว็บไซต์แบบข้ามต้นทาง
อนุญาตให้ฝังโดยเอกสารที่มีต้นทางเดียวกันเท่านั้น
X-Frame-Options: SAMEORIGIN
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
นโยบายทรัพยากรข้ามโดเมน (CORP)
ผู้โจมตีสามารถฝังทรัพยากรจากต้นทางอื่น เช่น จากเว็บไซต์ของคุณ เพื่อศึกษาข้อมูลเกี่ยวกับตัวคุณด้วยการใช้ประโยชน์จากเว็บไซต์แบบข้ามเว็บไซต์ การรั่วไหลของข้อมูล
Cross-Origin-Resource-Policy
ช่วยลดความเสี่ยงนี้โดยการระบุชุดของ
ที่โหลดปลายทางได้ ส่วนหัวจะใช้ค่าใดค่าหนึ่งจาก 3 ค่าดังนี้
same-origin
, same-site
และ cross-origin
แหล่งข้อมูลทั้งหมด
แนะนำให้ส่งส่วนหัวนี้เพื่อระบุว่าอนุญาตการโหลดโดย
เว็บไซต์อื่นๆ
ตัวอย่างการใช้งาน
Cross-Origin-Resource-Policy: same-origin
การใช้งานที่แนะนำ
เราขอแนะนำให้แสดงทรัพยากรทั้งหมดด้วยรายการใดรายการหนึ่งต่อไปนี้ ส่วนหัวสามแบบ
คุณสามารถลองใช้การกำหนดค่าต่อไปนี้ส่งผลต่อการโหลดทรัพยากรภายใต้
สภาพแวดล้อม Cross-Origin-Embedder-Policy: require-corp
ในนี้
การสาธิต เปลี่ยน
เมนูแบบเลื่อนลง Cross-Origin-Resource-Policy แล้วคลิก โหลดซ้ำ
iframe หรือปุ่มโหลดรูปภาพซ้ำเพื่อดูเอฟเฟกต์
อนุญาตให้โหลดทรัพยากร cross-origin
เราขอแนะนำให้บริการแบบ 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
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
นโยบายเครื่องมือเปิดแบบข้ามต้นทาง (COOP)
เว็บไซต์ของผู้โจมตีอาจเปิดเว็บไซต์อื่นๆ ในหน้าต่างป๊อปอัปเพื่อดูข้อมูล เกี่ยวกับเรื่องนี้โดยใช้ประโยชน์จากเว็บแบบข้ามเว็บไซต์ การรั่วไหลของข้อมูล ในบางกรณี วิธีนี้อาจทำให้ การแสวงหาประโยชน์จากการโจมตี Side-channels Spectre
ส่วนหัว Cross-Origin-Opener-Policy
แสดงวิธีแยกเอกสาร
เองจากหน้าต่างข้ามต้นทางที่เปิดผ่าน window.open()
หรือลิงก์ที่มี
target="_blank"
ที่ไม่มี rel="noopener"
ด้วยเหตุนี้ เครื่องมือเปิดแบบข้ามต้นทาง
ของเอกสารจะไม่มีการอ้างอิง และจะไม่สามารถโต้ตอบ
ด้วย
ตัวอย่างการใช้งาน
Cross-Origin-Opener-Policy: same-origin-allow-popups
การใช้งานที่แนะนำ
คุณสามารถลองใช้การกำหนดค่าต่อไปนี้ ส่งผลต่อการสื่อสารกับ หน้าต่างป๊อปอัปแบบข้ามต้นทางในการสาธิตนี้ เปลี่ยนเมนูแบบเลื่อนลง Cross-Origin-Opener-Policy สำหรับทั้งเอกสาร และหน้าต่างป๊อปอัป ให้คลิกปุ่มเปิดป๊อปอัป แล้วคลิกส่ง postMessage เพื่อดูว่าส่งข้อความแล้วจริงๆ หรือไม่
แยกเอกสารจากหน้าต่างข้ามต้นทาง
การตั้งค่า same-origin
จะทำให้เอกสารถูกแยกออกจากแบบข้ามต้นทาง
หน้าต่างเอกสาร
Cross-Origin-Opener-Policy: same-origin
แยกเอกสารจากหน้าต่างแบบข้ามต้นทาง แต่อนุญาตป๊อปอัปได้
การตั้งค่า same-origin-allow-popups
จะอนุญาตให้เอกสารเก็บการอ้างอิงถึง
หน้าต่างป๊อปอัป เว้นแต่จะตั้งค่า COOP ด้วย same-origin
หรือ
same-origin-allow-popups
ซึ่งหมายความว่า same-origin-allow-popups
ยังคงทำสิ่งต่อไปนี้ได้
ป้องกันไม่ให้มีการอ้างอิงเอกสารเมื่อเปิดเป็นหน้าต่างป๊อปอัป
ทำให้สื่อสารกับป๊อปอัปของตัวเองได้
Cross-Origin-Opener-Policy: same-origin-allow-popups
อนุญาตให้หน้าต่างแบบข้ามต้นทางอ้างอิงเอกสารได้
unsafe-none
คือค่าเริ่มต้น แต่คุณระบุอย่างชัดแจ้งได้ว่า
สามารถเปิดเอกสารโดยหน้าต่างข้ามต้นทางและยังคงมีสิทธิ์เข้าถึงร่วมกัน
Cross-Origin-Opener-Policy: unsafe-none
รูปแบบรายงานที่ใช้ร่วมกับ COOP ไม่ได้
คุณสามารถรับรายงานเมื่อ COOP ป้องกันการโต้ตอบข้ามกรอบเวลากับ API การรายงาน
Cross-Origin-Opener-Policy: same-origin; report-to="coop"
COOP ยังสนับสนุนโหมดรายงานเท่านั้นเพื่อให้คุณสามารถรับรายงาน บล็อกการสื่อสารระหว่างเอกสารข้ามต้นทางได้
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
กลไกการแชร์ทรัพยากรข้ามโดเมน (CORS)
กลไกการแชร์ทรัพยากรข้ามโดเมน (CORS) ไม่เหมือนรายการอื่นๆ ในบทความนี้ ส่วนหัว แต่เป็นกลไกของเบราว์เซอร์ที่ส่งคำขอและอนุญาตการเข้าถึง ทรัพยากรแบบข้ามต้นทาง
โดยค่าเริ่มต้น เบราว์เซอร์จะบังคับใช้นโยบายต้นทางเดียวกันเพื่อ ป้องกันไม่ให้หน้าเว็บเข้าถึงทรัพยากรแบบข้ามต้นทาง ตัวอย่างเช่น เมื่อ โหลดรูปภาพข้ามต้นทาง แม้ว่าจะแสดงในหน้าเว็บก็ตาม JavaScript ในหน้าเว็บจะไม่มีสิทธิ์เข้าถึงข้อมูลของรูปภาพ ผู้ให้บริการทรัพยากรสามารถผ่อนปรนข้อจำกัดและอนุญาตให้เว็บไซต์อื่นๆ อ่านได้ โดยเลือกใช้ CORS
ตัวอย่างการใช้งาน
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
ก่อนที่จะหาวิธีกำหนดค่า 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
ช่วยให้ ผู้ส่งคำขอตั้งค่าส่วนหัว HTTPX-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 วินาที
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
นโยบายเครื่องมือฝังแบบข้ามต้นทาง (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 ใช้ค่าเดียวคือ 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"
เบราว์เซอร์ที่รองรับ
ดูข้อมูลเพิ่มเติม
HTTP Strict Transport Security (HSTS)
การสื่อสารผ่านการเชื่อมต่อ HTTP แบบธรรมดาจะไม่มีการเข้ารหัส ทำให้ ที่ผู้ลักลอบขโมยข้อมูลระดับเครือข่ายเข้าถึงได้
ส่วนหัว Strict-Transport-Security
แจ้งเบราว์เซอร์ว่าไม่ควรมีการโหลด
เว็บไซต์ที่ใช้ HTTP และใช้ HTTPS แทน เมื่อตั้งค่าแล้ว เบราว์เซอร์จะใช้
ใช้ HTTPS แทน HTTP เพื่อเข้าถึงโดเมนโดยไม่มีการเปลี่ยนเส้นทางเป็นระยะเวลาหนึ่ง
ที่กำหนดไว้ในส่วนหัว
ตัวอย่างการใช้งาน
Strict-Transport-Security: max-age=31536000
การใช้งานที่แนะนำ
เว็บไซต์ทั้งหมดที่เปลี่ยนจาก HTTP ไปเป็น HTTPS ควรตอบสนองด้วย
ส่วนหัว Strict-Transport-Security
เมื่อได้รับคำขอที่มี HTTP
Strict-Transport-Security: max-age=31536000
เบราว์เซอร์ที่รองรับ