ลดการใช้ Cross-site Scripting (XSS) ด้วยนโยบายรักษาความปลอดภัยเนื้อหา (CSP) ที่เข้มงวด

Lukas Weichselbaum

Cross-site Scripting (XSS) ความสามารถในการแทรกสคริปต์ที่เป็นอันตรายลงในเว็บแอปถือเป็นหนึ่งใน ช่องโหว่ด้านความปลอดภัยที่ใหญ่ที่สุดของเว็บ มากว่า 10 ปี

นโยบายรักษาความปลอดภัยเนื้อหา (CSP) เป็นการรักษาความปลอดภัยอีกชั้นหนึ่งซึ่งช่วยลด XSS วิธีกำหนดค่า CSP เพิ่มส่วนหัว HTTP ของ Content-Security-Policy ลงในหน้าเว็บและตั้งค่าที่ ควบคุมทรัพยากรที่ User Agent โหลดได้สำหรับหน้าเว็บนั้น

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

คำศัพท์สำคัญ: nonce คือตัวเลขสุ่มที่ใช้เพียงครั้งเดียวเท่านั้นที่คุณสามารถใช้เพื่อทำเครื่องหมาย แท็ก <script> ว่าเชื่อถือได้

คำศัพท์สำคัญ: ฟังก์ชันแฮชเป็นฟังก์ชันทางคณิตศาสตร์ที่แปลงอินพุต เป็นค่าตัวเลขที่บีบอัดซึ่งเรียกว่า hash คุณสามารถใช้แฮช (เช่น SHA-256) เพื่อทำเครื่องหมายในหน้า แท็ก <script> ว่าเชื่อถือได้

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

เหตุใดคุณจึงควรใช้ CSP ที่เข้มงวด

หากเว็บไซต์มี CSP ที่มีลักษณะคล้ายกับ script-src www.googleapis.com อยู่แล้ว วิธีนี้อาจไม่มีประสิทธิภาพสำหรับข้ามเว็บไซต์ CSP ประเภทนี้เรียกว่า CSP ที่อนุญาต ต้องมีการปรับแต่งอย่างมากและ หลบเลี่ยงได้โดยผู้โจมตี

CSP ที่เข้มงวดซึ่งอิงตามการเข้ารหัสหรือแฮชที่ไม่เข้ารหัสจะช่วยหลีกเลี่ยงหลุมพรางเหล่านี้

โครงสร้าง CSP ที่เข้มงวด

นโยบายรักษาความปลอดภัยเนื้อหาที่เข้มงวดขั้นพื้นฐานจะใช้การตอบกลับ HTTP รายการใดรายการหนึ่งต่อไปนี้ ส่วนหัว:

CSP ที่ไม่ใช่แบบเข้มงวด

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

CSP ที่เข้มงวดที่ใช้แฮช

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

พร็อพเพอร์ตี้ต่อไปนี้ทำให้ CSP มีลักษณะแบบนี้ "เข้มงวด" ดังนั้นจึงปลอดภัยด้วย

• โดยใช้ nonces 'nonce-{RANDOM}' หรือแฮช 'sha256-{HASHED_INLINE_SCRIPT}' เพื่อระบุว่าแท็ก <script> ใดที่นักพัฒนาของเว็บไซต์เชื่อถือให้เรียกใช้ เบราว์เซอร์ของผู้ใช้
• ตั้งค่า 'strict-dynamic' เพื่อลดความจำเป็นในการติดตั้งใช้งาน CSP แบบ Nonce หรือแฮชโดยอัตโนมัติ อนุญาตให้เรียกใช้สคริปต์ที่สคริปต์ที่เชื่อถือได้สร้างขึ้น ยัง เลิกบล็อกการใช้ไลบรารีและวิดเจ็ต JavaScript ของบุคคลที่สามส่วนใหญ่
• บริการนี้ไม่ได้อิงตามรายการ URL ที่อนุญาต ดังนั้นจึงไม่ได้รับผลกระทบจาก การข้าม CSP ทั่วไป
• โหมดนี้จะบล็อกสคริปต์ในหน้าที่ไม่น่าเชื่อถือ เช่น เครื่องจัดการเหตุการณ์ในบรรทัดหรือ javascript: URI
• จำกัดไม่ให้ object-src ปิดใช้ปลั๊กอินที่เป็นอันตราย เช่น Flash
• จะจำกัด base-uri เพื่อบล็อกการแทรกแท็ก <base> วิธีนี้จะช่วย ผู้โจมตีจากการเปลี่ยนตำแหน่งของสคริปต์ที่โหลดจาก URL สัมพัทธ์

ใช้ CSP ที่เข้มงวด

หากต้องการใช้ CSP ที่เข้มงวด คุณต้องทำดังนี้

1. เลือกว่าแอปพลิเคชันควรตั้งค่า CSP แบบ Nonce หรือแฮช
2. คัดลอก CSP จากส่วนโครงสร้าง CSP ที่เข้มงวดแล้วตั้งค่า เป็นส่วนหัวการตอบกลับในแอปพลิเคชันของคุณ
3. เปลี่ยนโครงสร้างภายในโค้ดของเทมเพลต HTML และโค้ดฝั่งไคลเอ็นต์เพื่อลบรูปแบบที่ ไม่สามารถใช้ร่วมกับ CSP
4. ทำให้ CSP ใช้งานได้

คุณสามารถใช้ Lighthouse (เวอร์ชัน 7.3.0 และสูงกว่าพร้อมแฟล็ก --preset=experimental) การตรวจสอบแนวทางปฏิบัติแนะนำ ตลอดกระบวนการนี้เพื่อตรวจสอบว่าเว็บไซต์ของคุณมี CSP หรือไม่ และ เข้มงวดพอที่จะใช้กับ XSS

วันที่

ขั้นตอนที่ 1: ตัดสินใจว่าต้องใช้ CSP แบบ Nonce หรือแฮช

การทำงานของ CSP ที่เข้มงวดทั้ง 2 ประเภทมีดังนี้

CSP แบบ Nonce

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

ใช้ CSP แบบ Nonce สำหรับหน้า HTML ที่แสดงผลบนเซิร์ฟเวอร์ สำหรับหน้าเหล่านี้ คุณสามารถสร้างตัวเลขสุ่มใหม่สำหรับทุกคำตอบ

CSP ที่อิงตามแฮช

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

ใช้ CSP ที่อิงตามแฮชสำหรับหน้า HTML ที่แสดงแบบคงที่ หรือหน้าที่ต้อง แคช ตัวอย่างเช่น คุณสามารถใช้ CSP ที่อิงตามแฮชสำหรับเว็บหน้าเดียว แอปพลิเคชันที่สร้างด้วยกรอบการทำงาน เช่น Angular, React หรืออื่นๆ ที่ แสดงแบบคงที่โดยไม่มีการแสดงผลฝั่งเซิร์ฟเวอร์

ขั้นตอนที่ 2: กำหนด CSP ที่เข้มงวดและเตรียมสคริปต์

เมื่อตั้งค่า CSP คุณจะมี 3 ตัวเลือกดังนี้

• โหมดรายงานเท่านั้น (Content-Security-Policy-Report-Only) หรือโหมดการบังคับใช้ (Content-Security-Policy). ในโหมดรายงานเท่านั้น CSP จะไม่บล็อก ทรัพยากรมากขึ้น เพื่อให้ไซต์ไม่ทำงาน แต่คุณเห็นข้อผิดพลาดและ รายงานใดๆ ก็ตามที่อาจถูกบล็อก ในระดับท้องถิ่น เมื่อคุณ การตั้งค่า CSP ของคุณ สิ่งนี้ไม่ใช่เรื่องสำคัญ เพราะทั้ง 2 โหมดจะแสดง ในคอนโซลเบราว์เซอร์ หากมีสิ่งใด โหมดการบังคับใช้จะช่วยคุณค้นหาได้ ทรัพยากรที่ CSP ฉบับร่างได้บล็อก เนื่องจากการบล็อกทรัพยากรอาจทำให้ ดูเหมือนไม่ได้อัปเดต โหมดรายงานเท่านั้นจะมีประโยชน์มากที่สุดในขั้นตอนนี้ (ดูขั้นตอนที่ 5)
• ส่วนหัวหรือแท็ก HTML <meta> สําหรับการพัฒนาในเครื่อง แท็ก <meta> อาจมีค่ามากกว่า ซึ่งสะดวกในการปรับแต่ง CSP และดูผลกระทบที่มีต่อเว็บไซต์ได้อย่างรวดเร็ว อย่างไรก็ตาม
  • เมื่อทำให้ CSP ใช้งานได้จริงในภายหลัง เราขอแนะนำให้ตั้งค่าเป็น ส่วนหัว HTTP
  • หากคุณต้องการตั้งค่า CSP ในโหมดรายงานเท่านั้น คุณจะต้องตั้งค่า CSP เป็น เนื่องจากเมตาแท็ก CSP ไม่รองรับโหมดรายงานเท่านั้น

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

const app = express();

app.get('/', function(request, response) {
  // Generate a new random nonce value for every response.
  const nonce = crypto.randomBytes(16).toString("base64");

  // Set the strict nonce-based CSP response header
  const csp = `script-src 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'none';`;
  response.set("Content-Security-Policy", csp);

  // Every <script> tag in your application should set the `nonce` attribute to this value.
  response.render(template, { nonce: nonce });
});

ตัวเลือก B: ส่วนหัวการตอบกลับ CSP แบบแฮช

ตั้งค่าการตอบกลับ HTTP ของ Content-Security-Policy ต่อไปนี้ ส่วนหัวในแอปพลิเคชันของคุณ

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

สำหรับสคริปต์ในหน้าหลายรายการ ไวยากรณ์จะเป็นดังนี้ 'sha256-{HASHED_INLINE_SCRIPT_1}' 'sha256-{HASHED_INLINE_SCRIPT_2}'

โหลดสคริปต์ที่มีแหล่งที่มาแบบไดนามิก

เนื่องจากแฮช CSP จะทำได้ในเบราว์เซอร์ กับสคริปต์ในหน้าเท่านั้น คุณต้องโหลดสคริปต์ของบุคคลที่สามทั้งหมดแบบไดนามิกโดยใช้สคริปต์ในหน้า แฮชสําหรับสคริปต์ที่มีแหล่งที่มาไม่รองรับการใช้งานร่วมกันในเบราว์เซอร์ต่างๆ

วันที่

ได้รับอนุญาตจาก CSP

<script>
  var scripts = [ 'https://example.org/foo.js', 'https://example.org/bar.js'];

  scripts.forEach(function(scriptUrl) {
    var s = document.createElement('script');
    s.src = scriptUrl;
    s.async = false; // to preserve execution order
    document.head.appendChild(s);
  });
</script>

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

บล็อกโดย CSP

<script src="https://example.org/foo.js"></script>
<script src="https://example.org/bar.js"></script>

CSP บล็อกสคริปต์เหล่านี้เนื่องจากแฮชได้เฉพาะสคริปต์ในหน้าเท่านั้น

ข้อควรพิจารณาเกี่ยวกับการโหลดสคริปต์

ตัวอย่างสคริปต์ในหน้าจะเพิ่ม s.async = false เพื่อให้ ที่ foo จะดำเนินการก่อน bar แม้ว่า bar โหลดก่อน ในข้อมูลโค้ดนี้ s.async = false ไม่บล็อกโปรแกรมแยกวิเคราะห์ขณะโหลดสคริปต์ เนื่องจากสคริปต์ แบบไดนามิก โปรแกรมแยกวิเคราะห์จะหยุดเฉพาะเมื่อสคริปต์ทำงาน กับสคริปต์ async รายการ แต่ด้วยข้อมูลโค้ดนี้ ข้อควรทราบมีดังนี้

• สคริปต์ 1 หรือทั้งคู่อาจทำงานก่อนที่เอกสารจะเสร็จสิ้น กำลังดาวน์โหลด ถ้าต้องการให้เอกสารพร้อมก่อนถึงเวลา รันสคริปต์แล้ว โปรดรอให้ เหตุการณ์ DOMContentLoaded ปรากฏก่อน คุณจะเพิ่มสคริปต์ต่อท้าย หากการดำเนินการนี้ทำให้เกิดปัญหาด้านประสิทธิภาพเนื่องจาก สคริปต์ไม่เริ่มดาวน์โหลดเร็วพอ ให้ใช้โหลดแท็กล่วงหน้าก่อนในหน้าเว็บ
• defer = trueไม่ทำอะไรเลย ถ้าต้องการแบบนั้น ให้เรียกใช้สคริปต์ด้วยตนเองเมื่อจำเป็น

ขั้นตอนที่ 3: เปลี่ยนโครงสร้างภายในโค้ดของเทมเพลต HTML และโค้ดฝั่งไคลเอ็นต์

เครื่องจัดการเหตุการณ์ในบรรทัด (เช่น onclick="…", onerror="…") และ URI ของ JavaScript (<a href="javascript:…">) เพื่อเรียกใช้สคริปต์ ซึ่งหมายความว่า ผู้โจมตีที่พบข้อบกพร่อง XSS สามารถแทรก HTML ประเภทนี้และเรียกใช้ JavaScript CSP ที่ใช้ค่า Nonce หรือแฮชไม่อนุญาตให้ใช้มาร์กอัปประเภทนี้ หากเว็บไซต์ใช้รูปแบบเหล่านี้ คุณจะต้องเปลี่ยนโครงสร้างภายในโค้ดให้ปลอดภัยยิ่งขึ้น ทางเลือก

หากเปิดใช้ CSP ในขั้นตอนก่อนหน้า คุณจะเห็นการละเมิด CSP ใน คอนโซลนี้ทุกครั้งที่ CSP บล็อกรูปแบบที่ใช้ร่วมกันไม่ได้

วันที่

ในกรณีส่วนใหญ่ การแก้ไขจะไม่ซับซ้อน:

เปลี่ยนโครงสร้างของเครื่องจัดการเหตุการณ์ในบรรทัด

<span id="things">A thing.</span>
<script nonce="${nonce}">
  document.getElementById('things').addEventListener('click', doThings);
</script>

<span onclick="doThings();">A thing.</span>

เปลี่ยนโครงสร้างภายใน URI javascript: ใหม่

<a id="foo">foo</a>
<script nonce="${nonce}">
  document.getElementById('foo').addEventListener('click', linkClicked);
</script>

<a href="javascript:linkClicked()">foo</a>

นำ eval() ออกจาก JavaScript ของคุณ

หากแอปพลิเคชันใช้ eval() เพื่อแปลงการเรียงอันดับสตริง JSON เป็น JS คุณควรเปลี่ยนโครงสร้างภายในโค้ดของอินสแตนซ์ดังกล่าวเป็น JSON.parse() ซึ่งเป็น เร็วขึ้น

หากนําการใช้งาน eval() ทั้งหมดออกไม่ได้ คุณจะยังตั้งค่าตาม Nonce แบบเข้มงวดได้ CSP แต่คุณต้องใช้คีย์เวิร์ด 'unsafe-eval' CSP ซึ่งทำให้ นโยบายมีความปลอดภัยน้อยกว่าเล็กน้อย

คุณดูตัวอย่างเหล่านี้และตัวอย่างการเปลี่ยนโครงสร้างภายในโค้ดได้ใน CSP ที่เข้มงวดนี้ codelab:

ขั้นตอนที่ 4 (ไม่บังคับ): เพิ่มเบราว์เซอร์สำรองเพื่อรองรับเบราว์เซอร์เวอร์ชันเก่า

หากคุณต้องการรองรับเบราว์เซอร์เวอร์ชันเก่า ให้ทำดังนี้

• การใช้ strict-dynamic จำเป็นต้องมีการเพิ่ม https: เป็นทางเลือกสำหรับก่อนหน้านี้ Safari เวอร์ชันต่างๆ เมื่อคุณทำดังนี้
  • เบราว์เซอร์ทั้งหมดที่รองรับ strict-dynamic จะไม่สนใจ https: สำรอง วิธีนี้ไม่ได้ลดคุณภาพของนโยบาย
  • ในเบราว์เซอร์รุ่นเก่า สคริปต์ที่มาจากภายนอกจะโหลดได้ต่อเมื่อสคริปต์มาจาก ต้นทาง HTTPS วิธีนี้มีความปลอดภัยน้อยกว่า CSP ที่เข้มงวด ป้องกันสาเหตุทั่วไปของ XSS บางอย่าง เช่น การแทรก URI javascript:
• เพื่อให้สามารถทำงานร่วมกับเบราว์เซอร์เวอร์ชันเก่ามาก (มากกว่า 4 ปี) คุณสามารถเพิ่ม unsafe-inline เป็นตัวสำรอง เบราว์เซอร์ล่าสุดทั้งหมดจะไม่สนใจ unsafe-inline หากมี Nonce หรือแฮชของ CSP

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

ขั้นตอนที่ 5: ทำให้ CSP ใช้งานได้

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

1. (ไม่บังคับ) ทำให้ CSP ใช้งานได้ในโหมดรายงานเท่านั้นโดยใช้ ส่วนหัว Content-Security-Policy-Report-Only โหมดรายงานเท่านั้นมีประโยชน์ ทดสอบการเปลี่ยนแปลงที่อาจส่งผลกับส่วนอื่นอย่าง CSP ใหม่ในเวอร์ชันที่ใช้งานจริงก่อน เริ่มบังคับใช้ข้อจำกัดของ CSP ในโหมดรายงานเท่านั้น CSP จะไม่ ส่งผลต่อลักษณะการทำงานของแอป แต่เบราว์เซอร์ยังคงสร้างข้อผิดพลาดของคอนโซล และรายงานการละเมิดเมื่อพบรูปแบบที่เข้ากันไม่ได้กับ CSP เพื่อให้คุณดูได้ว่าปัญหาเกิดจากอะไรสำหรับผู้ใช้ปลายทาง สำหรับข้อมูลเพิ่มเติม โปรดดูข้อมูลใน Reporting API
2. เมื่อคุณมั่นใจว่า CSP จะไม่ทำให้เว็บไซต์เสียหายสำหรับผู้ใช้ปลายทาง ทำให้ CSP ใช้งานได้โดยใช้ส่วนหัวการตอบกลับ Content-Security-Policy พ ขอแนะนำให้ตั้งค่า CSP โดยใช้ส่วนหัว HTTP จากฝั่งเซิร์ฟเวอร์เพราะ ปลอดภัยกว่าแท็ก <meta> หลังจากทำขั้นตอนนี้เสร็จแล้ว CSP จะเริ่มต้น การปกป้องแอปของคุณจาก XSS

ข้อจำกัด

โดยทั่วไป CSP ที่เข้มงวดจะช่วยเพิ่มความปลอดภัยอีกชั้น ซึ่งจะช่วย ลด XSS ในกรณีส่วนใหญ่ CSP จะลดพื้นที่ในการโจมตีลงอย่างมาก การปฏิเสธรูปแบบที่เป็นอันตราย เช่น URI ของ javascript: อย่างไรก็ตาม ทั้งนี้ขึ้นอยู่กับประเภท ของ CSP ที่คุณใช้อยู่ (nonces, แฮชที่มีหรือไม่มี 'strict-dynamic') คือกรณีที่ CSP ไม่ปกป้องแอปของคุณด้วยเช่นกัน

• หากคุณระบุสคริปต์ แต่มีการแทรกเข้าไปในเนื้อหาโดยตรงหรือ พารามิเตอร์ src ขององค์ประกอบ <script> ดังกล่าว
• หากมีการแทรกลงในตำแหน่งของสคริปต์ที่สร้างขึ้นแบบไดนามิก (document.createElement('script')) รวมถึงฟังก์ชันต่างๆ ของไลบรารี ที่สร้างโหนด DOM script โหนดตามค่าของอาร์กิวเมนต์ ช่วงเวลานี้ มี API ทั่วไปบางส่วน เช่น .html() ของ jQuery รวมถึง .get() และ .post() ใน jQuery < 3.0
• หากมีการแทรกเทมเพลตในแอปพลิเคชัน AngularJS แบบเก่า ผู้โจมตี ที่สามารถแทรกลงในเทมเพลต AngularJS สามารถใช้เพื่อ เรียกใช้ JavaScript ที่กำหนดเอง
• หากนโยบายมี 'unsafe-eval' การแทรกใน eval() setTimeout() และ API อื่นๆ ที่ไม่ค่อยใช้งาน

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

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

• CSP ตายแล้ว แค่ CSP เล่นนาน เกี่ยวกับความไม่ปลอดภัยของรายการที่อนุญาตพิเศษและอนาคตของนโยบายรักษาความปลอดภัยเนื้อหา
• ผู้ประเมิน CSP
• การประชุม LocoMoco: นโยบายรักษาความปลอดภัยเนื้อหา - ความวุ่นวายที่ประสบความสำเร็จระหว่างการปิดช่องโหว่และการบรรเทาปัญหา
• พูดคุยเรื่อง Google I/O: การรักษาความปลอดภัยเว็บแอปด้วยฟีเจอร์แพลตฟอร์มสมัยใหม่