AI ส่ง URL มา อย่าให้ Server โหลดทันที: บทเรียนจาก Vercel AI SDK

ข่าวนี้คืออะไรในภาษาคนทำงาน

เวลาเราเรียก AI provider เพื่อสร้างรูป เสียง วิดีโอ หรือทำงานแบบ background ผลลัพธ์ไม่ได้กลับมาเป็นไฟล์ทันทีเสมอไปครับ

หลาย provider จะตอบกลับมาเป็น URL เช่น URL สำหรับดาวน์โหลดรูปที่สร้างเสร็จแล้ว หรือ URL สำหรับ polling เพื่อตรวจว่างานเรนเดอร์เสร็จหรือยัง จากนั้น Server ของเราจะ fetch URL นั้นต่ออัตโนมัติ

วันที่ 13 กรกฎาคม 2026 Vercel AI SDK ออก @ai-sdk/[email protected] พร้อมการเปลี่ยนแปลงเรื่อง Secure URL Fetching โดยระบุว่า URL ที่มาจาก provider response ต้องถือเป็นข้อมูลที่ยังไม่ trusted

อัปเดตนี้ทำให้ URL สำหรับดาวน์โหลดไฟล์และ polling ผ่านการตรวจมากขึ้น ได้แก่

• ปฏิเสธเป้าหมายที่เป็น private, loopback และ link-local address
• ตรวจ URL ใหม่ทุกครั้งที่มี redirect
• ตัด proxy, metadata และ cookie header ที่ไม่ควรถูกส่งออกไป
• ไม่ส่ง credential ไปยัง origin อื่น
• ถ้า URL ถูกบล็อก ระบบจะคืน DownloadError แทนการ fetch ต่อ

พูดง่าย ๆ คือ AI SDK ไม่ได้ดูแค่ว่า “มี URL ส่งกลับมาแล้ว” แต่ดูต่อว่า “URL นี้จะพา Server ของเราไปคุยกับที่ไหน”

นี่เป็นข่าว patch เล็ก ๆ แต่มีบทเรียนที่ใช้ได้กับ AI workflow แทบทุกแบบครับ

So what: ทำไม founder/operator/ทีมเล็กควรสนใจ

ทีมเล็กมักต่อระบบแบบเร็วที่สุดก่อน เช่น

1. ส่ง prompt ไปยัง provider
2. รอ job เสร็จ
3. รับ URL กลับมา
4. ให้ Server โหลดไฟล์
5. เก็บเข้า storage หรือส่งต่อให้ลูกค้า

flow นี้ดูธรรมดามาก แต่มีจุดที่คนมักมองข้าม: URL ที่ตอบกลับมาสามารถสั่งให้ Server ของเราเป็นคนออก request ต่อได้

ถ้า provider ถูกตั้งค่าผิด, response ถูกแก้ระหว่างทาง หรือระบบรองรับ endpoint ภายนอกหลายตัว URL นั้นอาจชี้ไปยังปลายทางที่เราไม่ตั้งใจ เช่น localhost, private service หรือ cloud metadata endpoint

ประเด็นจึงไม่ใช่แค่เรื่องของ Vercel หรือ JavaScript ครับ แต่เป็นนิสัยการออกแบบระบบ AI:

อย่าดูแค่ output ที่ผู้ใช้เห็น ให้ดูด้วยว่า output นั้นทำให้ระบบของเราลงมือทำอะไรต่อ

ตัวอย่างใกล้ตัวคือ workflow สร้างภาพสินค้า AI ถ้า provider ส่ง URL กลับมาแล้วระบบโหลดเข้า WordPress, R2 หรือ S3 อัตโนมัติ จุดรับ URL คือส่วนหนึ่งของ network flow ไม่ใช่แค่ขั้นตอนจัดการไฟล์

How to use: เอาไปใช้กับงานตัวเองยังไง

1) หาให้เจอว่า workflow ไหนรับ URL จากภายนอก

เริ่มจาก inventory สั้น ๆ ไม่ต้องรื้อทั้งระบบ

ลองค้นหา flow ที่มีคำหรือพฤติกรรมแบบนี้:

• image, audio หรือ video generation
• transcription และ media processing
• background job ที่มี status URL
• webhook ที่ส่ง file URL กลับมา
• import ไฟล์จาก URL
• agent tool ที่ fetch เอกสารหรือ asset ต่อ

สำหรับแต่ละ flow ให้ตอบให้ได้ว่า URL มาจาก config ที่ทีมกำหนดเอง หรือมาจาก response body ของระบบอื่น

ถ้า host หรือ scheme มาจาก response body ให้ถือว่าเป็น untrusted URL ก่อนครับ

2) อัปเดต SDK แล้วอ่าน lockfile จริง

ถ้าใช้ Vercel AI SDK ให้ตรวจ package ที่ใช้งานจริง ไม่ใช่ดูแค่ version ที่เขียนไว้ใน package.json

อัปเดต dependency จากนั้นตรวจ lockfile และ build output ว่า provider package ที่ production โหลดอยู่ได้รับ patch แล้ว โดยเฉพาะ flow ที่ใช้ image, audio, video และ polling

ข่าวนี้กระจายการเปลี่ยนแปลงไปยัง provider adapters หลายตัว การเห็นชื่อ AI SDK เวอร์ชันใหม่อย่างเดียวจึงยังไม่พอ ต้องดู package ที่ runtime ใช้จริงด้วย

3) ทดสอบ redirect ไม่ใช่ทดสอบแค่ URL แรก

URL แรกอาจดูปกติ แต่ตอบกลับด้วย redirect ไปยังปลายทางอีกแห่งได้

อย่างน้อยควรมี test 4 แบบ:

• public URL ไปยัง public asset และโหลดสำเร็จ
• public URL redirect ไปยัง public CDN และโหลดสำเร็จ
• public URL redirect ไปยัง private หรือ loopback address แล้วต้องถูกปฏิเสธ
• redirect ข้าม origin แล้ว credential ต้องไม่ถูกส่งตามไป

นี่คือจุดที่อัปเดตของ AI SDK น่าสนใจ เพราะมันตรวจทุก redirect hop ไม่ใช่เช็กเฉพาะ URL ตั้งต้น

4) แยก app check ออกจาก network protection

ตัว SDK ตรวจ URL แบบ string และ literal IP แต่เอกสารของ Vercel ระบุชัดว่ายังไม่ครอบคลุม hostname ที่ resolve ไป private IP และ DNS rebinding

ถ้า Server ของคุณรับ URL จากภายนอกจริง ควรเสริมที่ network layer ด้วย เช่น

• ปิด outbound access ไปยัง metadata endpoint
• ปฏิเสธ RFC 1918, loopback และ link-local range ที่ไม่จำเป็น
• ใช้ DNS resolution ที่ตรวจ IP ตอน connect
• จำกัด egress ให้ไปเฉพาะปลายทางที่ workflow ต้องใช้

ไม่ต้องทำทุกอย่างในวันแรกครับ แต่ต้องรู้ว่าการอัปเดต SDK กับการคุม network เป็นคนละชั้น และช่วยกันคนละแบบ

5) เก็บ log ที่พอแก้ปัญหาได้ แต่ไม่พา secret หลุด

เมื่อ URL ถูกบล็อก ทีมต้องรู้ว่าเกิดที่ provider ไหน, workflow ไหน และ redirect hop ไหน

แต่ log ไม่ควรเก็บ credential, signed URL เต็มเส้น หรือ query string ที่มี token

ข้อมูลที่พอใช้ได้มักเป็น:

• provider และ workflow name
• hostname แบบตัด query string
• redirect count
• block reason
• timestamp และ correlation ID
• retry decision

เป้าหมายคือให้ทีมแก้ flow ได้ โดยไม่สร้างปัญหาใหม่จาก log ครับ

Operator Kit: Provider URL Download Checklist

ใช้ checklist นี้กับ workflow หนึ่งเส้นที่รับ URL จาก AI provider หรือ external service

A. ระบุ flow

• [ ] URL มาจาก config หรือ response body
• [ ] ใครเป็นคน trigger การ fetch
• [ ] Server ไหนเป็นคนออก request
• [ ] ไฟล์ถูกเก็บหรือส่งต่อไปที่ไหน
• [ ] มี polling หรือ redirect กี่ชั้น

B. ตรวจ URL ก่อน fetch

• [ ] อนุญาตเฉพาะ http และ https
• [ ] ปฏิเสธ localhost, loopback, private และ link-local address
• [ ] ตรวจ redirect ใหม่ทุก hop
• [ ] จำกัดจำนวน redirect
• [ ] ตั้ง timeout และขนาดไฟล์สูงสุด
• [ ] ตรวจ content type ก่อนเก็บไฟล์

C. ดูแล credential

• [ ] ส่ง API key เฉพาะ origin ที่ตั้งใจ
• [ ] ตัด Authorization, cookie และ custom credential เมื่อข้าม origin
• [ ] ไม่ log signed URL หรือ query token เต็มค่า
• [ ] แยก credential สำหรับ download flow ออกจาก credential งานหลักถ้าทำได้

D. ทดสอบก่อนใช้กับข้อมูลจริง

• [ ] public asset ปกติผ่าน
• [ ] public redirect ปกติผ่าน
• [ ] redirect ไป private IP ถูกบล็อก
• [ ] cross-origin redirect ไม่มี credential ติดไป
• [ ] DNS ที่ resolve ผิดปลายทางถูก network layer ปฏิเสธ
• [ ] error ไม่วน retry จนเกิดค่าใช้จ่ายเงียบ

E. Done criteria

ถือว่า flow พร้อมทดลองเมื่อทีมตอบได้ครบ 5 ข้อ:

1. URL มาจากไหน
2. Server จะออกไปที่ไหน
3. credential ใดถูกแนบไป
4. redirect และ DNS ถูกจัดการอย่างไร
5. เมื่อถูกบล็อก ใครจะเห็น error และทำอะไรต่อ

ถ้าอยากเริ่มวันนี้ ให้เลือก workflow ที่โหลดไฟล์อัตโนมัติหนึ่งตัว แล้วลอง test public URL, redirect และ private IP ให้ครบก่อนครับ

Caveat: สิ่งที่ยังต้องระวัง

อัปเดตนี้ไม่ใช่ประกาศ CVE และแหล่งข้อมูลไม่ได้ระบุว่ามีเหตุโจมตีเกิดขึ้นจริง บทความนี้จึงอธิบายเป็นการปรับปรุงความปลอดภัยของ download flow ไม่ใช่ข่าว breach

อีกข้อคือ built-in validation ยังไม่ resolve DNS เอง จึงไม่ปิดช่อง hostname ที่ชี้เข้า private network หรือ DNS rebinding ได้ทั้งหมด ทีมที่รัน Server ใน cloud ควรใช้ network egress restriction หรือ hardened fetch เพิ่มตามระดับความเสี่ยงของงาน

สุดท้าย ถ้าใช้ self-hosted provider ที่ตั้งใจรันบน localhost หรือ private network อย่าบล็อกแบบเหมารวม Vercel AI SDK มีแนวคิด trustedOrigin สำหรับ endpoint ที่ developer เป็นคนตั้งค่าเอง แต่ origin นี้ต้องมาจาก config ของทีม ไม่ใช่หยิบจาก response ที่กำลังตรวจ

สรุป

ข่าวนี้สอนเรื่องเล็กที่สำคัญมากครับ: AI provider ตอบ URL กลับมา ไม่ได้แปลว่า Server ของเราควรโหลดต่อทันที

วิธีที่ใช้ได้จริงคือแยกให้ชัดว่า URL มาจาก config หรือ response, ตรวจทุก redirect, ไม่พา credential ข้าม origin และเสริม network protection ในจุดที่ SDK มองไม่เห็นเรื่อง DNS

Data-Espresso และ OPB Stack จะคอยทำหน้าที่แบบนี้ต่อครับ แปลงข่าว AI และ agent tooling ให้กลายเป็น workflow, SOP และ checklist ที่คนทำงานเอาไปลองกับระบบของตัวเองได้ทันที