Connection-Allowlist คืออะไร? เฮดเดอร์ใหม่ของ Chrome ที่กันโค้ด AI ส่งข้อมูลออกนอกบ้าน

โดย Nokka (นก-กา) | 2 พ.ย. 2026

เว็บสมัยนี้ไม่ได้รันแต่โค้ดที่เรเขียนเองอีกแล้ว

มันรันสคริปต์ของบุคคลที่สาม รันโค้ดที่ AI สร้างให้ และบางทีรันโค้ดที่ผู้ใช้พิมพ์เข้ามาเองด้วย

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

Chrome 152 แก้จุดนี้ด้วยเฮดเดอร์ชื่อ Connection-Allowlist [1]

ปัญหาที่ CSP แก้ไม่ได้

หลายคนอาจคิดว่าเรามี Content Security Policy อยู่แล้ว น่าจะพอ

แต่ทีม Chrome เขียนไว้ตรง ๆ ว่า CSP ออกแบบมาคุมสิ่งที่หน้าเว็บ โหลดและรัน ไม่ใช่ปลายทางที่มัน ส่งข้อมูลไป [1]

ยิ่งกว่านั้น CSP แบ่งประเภทคำขอละเอียดเกินจำเป็น และยังไม่ครอบคลุมกลไกของแพลตฟอร์มเว็บหลายตัว เช่น DNS prefetch, การนำทาง (navigation) และ WebRTC [1]

ช่องพวกนี้คือทางที่ข้อมูลจะรั่วออกไปได้โดยที่ CSP ไม่เห็น

กลไกทำงานอย่างไร

Connection-Allowlist เป็น HTTP response header ที่บอกเบราว์เซอร์ว่าหน้านี้ได้รับอนุญาตให้เชื่อมต่อกับปลายทางใดได้บ้าง

หลักการคือ ห้ามโดยค่าเริ่มต้น ก่อนจะเปิดการเชื่อมต่อใด ๆ เบราว์เซอร์จะเทียบปลายทางกับรายการที่อนุญาตก่อน ถ้าไม่ตรงก็บล็อกที่ระดับเครือข่าย [1]

จุดที่ผมคิดว่าสำคัญคือคำว่า "ระดับเครือข่าย"

มันไม่ได้บล็อกที่ชั้น JavaScript ซึ่งโค้ดอาจหลบได้หลายวิธี แต่บล็อกก่อนที่แพ็กเก็ตจะออกไป

เขียน header อย่างไร

รูปแบบใช้ไวยากรณ์ URLPattern และมี token พิเศษชื่อ response-origin ที่เติมโอริจินของหน้าที่เสิร์ฟ header ให้อัตโนมัติ [1]

Connection-Allowlist: ("https://api.example.com/*" response-origin)

ถ้าต้องการเปิดทางให้ redirect และ WebRTC ต้องระบุเอง เพราะทั้งสองอย่างถูกบล็อกเป็นค่าเริ่มต้น [1]

Connection-Allowlist: ("https://api.example.com/*"); redirects=allow; webrtc=allow

จุดที่คนมักตั้งพลาด

นโยบายนี้แยกต่อบริบท หนึ่งหน้าต่าง หรือหนึ่ง worker คือหนึ่งนโยบาย [1]

ฟังดูเป็นรายละเอียดเล็ก แต่มีผลมากกับสถาปัตยกรรม เพราะมันแปลว่าคุณใส่ header ครั้งเดียวแล้วหวังให้ทั้งเว็บปลอดภัยไม่ได้

ทีม Chrome เตือนเพิ่มอีกข้อที่ผมคิดว่าสำคัญที่สุดในบทความทั้งหมด

ถ้าคุณจะใช้กลไกนี้กับโค้ดที่ไม่น่าไว้ใจ ให้แยกโค้ดนั้นไว้ใน iframe ต่างหาก แล้วใส่ header เฉพาะ iframe นั้น และ iframe ต้องเป็นแบบข้ามโอริจินหรือแบบ sandbox ด้วย [1]

เหตุผลคือถ้า iframe อยู่ในโดเมนเดียวกับหน้าแม่ โค้ดข้างในจะเข้าถึงบริบทของกันและกันได้ แล้วหาทางหลบข้อจำกัดนี้

ลองก่อนโดยไม่ทำให้เว็บพัง

การใส่ header ผิดครั้งเดียวสามารถทำให้หน้าเว็บติดต่ออะไรไม่ได้เลย

Chrome จึงมีโหมดรายงานอย่างเดียว ซึ่งตรวจและส่งรายงานแต่ไม่บล็อก [1]

Connection-Allowlist-Report-Only: ("https://trusted.com/*"); report-to=security-endpoint
Reporting-Endpoints: security-endpoint="https://example.com/reports"

คุณต้องประกาศ Reporting-Endpoints คู่กันเสมอ ไม่งั้นรายงานจะไม่รู้ว่าจะไปไหน [1]

ครอบคลุมอะไรบ้าง

ตามเอกสารข้อกำหนดของ WICG กลไกนี้ตั้งใจคุมช่องทางสื่อสารที่หน้าเว็บเป็นฝ่ายเริ่มเอง ได้แก่ [2]

• คำขอผ่าน Fetch และ API ของแพลตฟอร์มเว็บ
• การเชื่อมต่อ TURN และ STUN ที่ WebRTC ใช้
• ช่องทาง WebTransport
• DNS prefetch
• การนำทางไปหน้าอื่น
• manifest ที่โหลดผ่าน Web Install API

แต่มันไม่ได้แก้ปัญหาทุกอย่าง เอกสารเขียนไว้ชัดว่าช่องโจมตีแบบ side channel เช่น การวัดการใช้หน่วยความจำหรือซีพียู และปัญหา XSLeaks ไม่ได้อยู่ในขอบเขตของกลไกนี้ [2]

พูดง่าย ๆ คือมันกันการส่งข้อมูลออกไปตรง ๆ ได้ดี แต่ไม่ได้กันทุกวิธีที่ข้อมูลจะรั่ว

ใช้กับงานแบบไหนได้จริง

หนึ่ง ซับซ้อนสุดคือโค้ดที่ AI สร้าง ถ้าแอปคุณรัน UI ที่โมเดลสร้าง หรือรัน sandbox สำหรับให้ผู้ใช้ลองโค้ด กลไกนี้คือกำแพงชั้นสุดท้ายที่กันไม่ให้โค้ดนั้นส่งข้อมูลออกไปข้างนอก [1]

สอง สคริปต์บุคคลที่สาม ถ้าสคริปต์ถูกยึด คุณยังรู้ได้ว่ามันส่งข้อมูลออกไปที่ไหนได้บ้าง [1]

สาม ขอบเขตของระบบภายใน บริการที่อ่อนไหวที่สุดของคุณสามารถบังคับให้คุยกับแบ็กเอนด์ที่ระบุไว้เท่านั้น [1]

ข้อจำกัดที่ต้องรู้ก่อนใช้

• รองรับเฉพาะ Chrome 152 ขึ้นไป ซึ่งปล่อยเสถียรเมื่อ 25 ส.ค. 2026 [3]
• ยังไม่ใช่มาตรฐาน W3C ตอนนี้อยู่ที่ WICG และ ChromeStatus ระบุสถานะข้อกำหนดว่ายังอยู่ในขั้น incubation ใน Community Group [2] [4]
• MDN ยังไม่มีหน้าเอกสารของเฮดเดอร์นี้ ผมลองเปิดทั้งสองเส้นทางที่ MDN ใช้ แล้วได้ 404 ทั้งคู่ (ตรวจเมื่อ 2 พ.ย. 2026)
• ต้องคุมฝั่งเซิร์ฟเวอร์ ถ้าเซิร์ฟเวอร์ไม่ส่ง header ก็ไม่มีอะไรเกิดขึ้น

เรื่องที่ผมคิดว่าคนอ่านควรตั้งข้อสังเกตคือช่องเวลาระหว่างการปล่อยของจริงกับประกาศ

Chrome 152 ออกเสถียร 25 ส.ค. 2026 แต่บทความอธิบายวิธีใช้เพิ่งลง 23 ก.ย. 2026 [1] [3]

แปลว่าฟีเจอร์นี้ทำงานอยู่ในเบราว์เซอร์มาเกือบหนึ่งเดือน (29 วัน) ก่อนจะมีคู่มือภาษาเว็บให้อ่าน

ลำดับที่ผมคิดว่าควรลอง

ถ้าคุณดูแลแอปที่มีโค้ดไม่น่าไว้ใจปนอยู่ ผมแนะนำลำดับนี้

1. เริ่มจาก Connection-Allowlist-Report-Only บน staging
2. เปิดดูรายงานว่ามีคำขอใดถูกบล็อก และคำขอเหล่านั้นเป็นของใคร
3. ย้ายโค้ดที่ไม่น่าไว้ใจเข้า iframe ข้ามโอริจินหรือแบบ sandbox
4. ใส่ header แบบบังคับเฉพาะ iframe นั้น
5. ค่อยขยายไปหน้าหลัก เมื่อมั่นใจว่ารายการปลายทางครบแล้ว

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

สิ่งที่ผมยังไม่ได้ทำ

ผมยังไม่ได้เปิด Chrome 152 และทดสอบเฮดเดอร์นี้กับเว็บจริง

ผมเปิดประกาศบน developer.chrome.com ที่ลงวันที่ 23 ก.ย. 2026 เปิดหน้า ChromeStatus ของฟีเจอร์ เปิดบันทึกการปล่อย Chrome 152 และเปิดเอกสารข้อกำหนดบน WICG

ตัวอย่าง Connection-Allowlist และ Connection-Allowlist-Report-Only คัดจากประกาศของ Chrome ตรง ๆ ส่วนบรรทัด Reporting-Endpoints ผมเขียนเองตามไวยากรณ์ของ Reporting API ทั้งหมดยังไม่ได้ทดสอบบนเซิร์ฟเวอร์ของผมเอง

แหล่งอ้างอิง

[1] Chrome for Developers · "Connection allowlists: Secure your web application's network access" (23 ก.ย. 2026) · https://developer.chrome.com/blog/connection-allowlist-announcement
[2] WICG · Connection Allowlists specification (เข้าถึง 2 พ.ย. 2026) · https://wicg.github.io/connection-allowlists/
[3] Chrome for Developers · Release notes 152, stable 25 ส.ค. 2026 (เข้าถึง 2 พ.ย. 2026) · https://developer.chrome.com/release-notes/152
[4] ChromeStatus · Connection Allowlists (เข้าถึง 2 พ.ย. 2026) · https://chromestatus.com/feature/5175745573945344

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)