ต่อ API ยังไงให้ปลอดภัย: คู่มือสำหรับคนเริ่มทำเว็บ แอป และ AI Workflow

ปัญหาจริงของคนเริ่มทำเว็บ แอป และ AI workflow ไม่ใช่ต่อ API ไม่เป็นอย่างเดียว แต่คือเข้าใจว่าการต่อ API คือแค่เอา key ไปแปะให้ request สำเร็จ พอระบบตอบกลับมาได้ ก็คิดว่างานจบแล้ว

ความจริง API คือประตูเข้าระบบ ถ้าคุณเปิดประตูผิดที่ คนอื่นอาจใช้ key ของคุณยิง API แทนคุณ ดึงข้อมูลลูกค้า แก้ข้อมูลหลังบ้าน สร้างค่าใช้จ่าย หรือทำให้ระบบโดนระงับได้ การต่อ API จึงไม่ใช่แค่เรื่อง code แต่เป็นเรื่อง security, permission, cost และ accountability ด้วย

API คือช่องทางให้ระบบหนึ่งคุยกับอีกระบบหนึ่ง เช่น เว็บของคุณคุยกับ Stripe เพื่อรับเงิน คุยกับ LINE เพื่อส่งข้อความ คุยกับ OpenAI เพื่อสร้างคำตอบ คุยกับ Supabase เพื่ออ่านฐานข้อมูล หรือคุยกับ n8n เพื่อสั่ง workflow ทำงาน

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

API key, access token, service role key, webhook secret และ database password ต้องถูกมองเป็นกุญแจเข้าระบบ ไม่ใช่ข้อความธรรมดาที่จะส่งต่อหรือแปะไว้ที่ไหนก็ได้ ถ้า key หลุด คนอื่นอาจไม่ต้องรู้รหัสผ่านของคุณก็สามารถเรียก service แทนคุณได้

ข้อผิดพลาดที่พบบ่อยคือเอา API key ไปใส่ในไฟล์ frontend เช่น React component, Next.js client component, JavaScript ที่โหลดใน browser หรือใส่ใน GitHub repo แบบ public พอ deploy แล้วใครเปิด DevTools หรือดู source ก็อาจเจอ key ได้

สำหรับโปรเจกต์เว็บทั่วไป ควรเก็บ API key ใน Environment Variables ของระบบที่รันฝั่ง server เช่น Vercel Environment Variables, Supabase Edge Function Secrets, GitHub Actions Secrets, Docker/Kubernetes secrets หรือ cloud secret manager เช่น AWS Secrets Manager, Google Secret Manager หรือ Azure Key Vault

หลักง่าย ๆ คือ secret ต้องอยู่ในที่ที่ frontend อ่านไม่ได้ และต้องถูกแยกตาม environment เช่น local, staging, production อย่าใช้ key เดียวกันทุกที่ เพราะถ้าหลุดจากเครื่อง dev หรือ staging จะกระทบ production ทันที

คำตอบคือได้เฉพาะ API ที่ออกแบบมาให้เรียกจาก frontend และไม่มี secret ที่ต้องปิด เช่น public anon key บางประเภท หรือ endpoint ที่มี authentication ของผู้ใช้คุมอยู่ แต่ถ้า API ต้องใช้ secret, service role, admin key หรือ payment secret ห้ามเรียกจาก frontend โดยตรง

วิธีที่ปลอดภัยกว่าคือสร้าง backend route, server action, API route หรือ edge function เป็นตัวกลาง ให้ browser เรียก endpoint ของเรา แล้ว server ของเราค่อยใส่ secret ไปเรียก third-party API อีกที แบบนี้ secret จะไม่ถูกส่งไปที่ browser

Authentication คือการพิสูจน์ว่าใครกำลังเรียก API เช่น login แล้วได้ session หรือ token ส่วน Authorization คือการตรวจว่าคนคนนั้นมีสิทธิ์ทำสิ่งนี้กับข้อมูลชิ้นนี้จริงไหม หลายระบบพังเพราะมี login แล้ว แต่ไม่ได้เช็กสิทธิ์ระดับ object

ตัวอย่างเช่น user A login แล้วเรียก /orders/123 ได้ แต่ order 123 เป็นของ user B ถ้าระบบเช็กแค่ว่า login แล้ว แต่ไม่เช็กว่า order นี้เป็นของ user A จริงไหม นี่คือช่องโหว่แบบ Broken Object Level Authorization ซึ่งเป็นหนึ่งในปัญหา API ที่สำคัญมาก

Webhook คือการที่ระบบภายนอกยิงข้อมูลกลับมาหาเรา เช่น Stripe แจ้งว่าจ่ายเงินสำเร็จ LINE ส่ง event ข้อความเข้า Telegram ส่ง update หรือ n8n เรียก webhook เพื่อให้ระบบทำงานต่อ ปัญหาคือถ้าเราไม่ verify signature ใครก็อาจยิงข้อมูลปลอมเข้ามาได้

ทุก webhook ที่สำคัญควรตรวจ signature หรือ shared secret ตามวิธีของ provider ก่อนทำ action จริง เช่น อัปเดตสถานะออเดอร์ เพิ่มเครดิตสมาชิก ส่งไฟล์ดาวน์โหลด หรือให้สิทธิ์ผู้ใช้ ถ้า signature ไม่ถูกต้องต้อง reject ทันที

API หลายตัวคิดเงินตามจำนวน request, token, message หรือเครดิต ถ้าคุณเปิด endpoint โดยไม่มี rate limit คนอื่นอาจยิงซ้ำจนค่าใช้จ่ายบาน หรือทำให้ระบบคุณช้าลงจนผู้ใช้จริงใช้งานไม่ได้

Rate limit ไม่ได้มีไว้กัน hacker อย่างเดียว แต่มีไว้กัน bug, loop ผิด, bot, user ใช้งานหนักเกินควบคุม และ workflow ที่ยิงซ้ำโดยไม่ตั้งใจ โดยเฉพาะระบบ AI ที่คิดเงินตาม token หรือเครดิต ต้องมี limit ต่อ user, ต่อ IP, ต่อ workspace และต่อช่วงเวลา

ระบบที่ดีต้องมี log เพื่อดูว่าใครเรียก API ไหน เวลาไหน สำเร็จหรือ fail ใช้เวลานานเท่าไร และเกิด error อะไร แต่ log ต้องไม่เก็บ API key, access token, password, full payload ที่มีข้อมูลส่วนตัว หรือข้อมูลบัตร/การเงินโดยไม่จำเป็น

ให้คิดว่า log คือหลักฐานสำหรับตรวจสอบ ไม่ใช่ถังขยะที่โยนทุกอย่างลงไป ถ้า log หลุดหรือมีคนในทีมเข้าถึง log มากเกินไป ข้อมูลสำคัญก็รั่วได้เหมือนกัน

หลายคนเข้าใจผิดว่าเปิด CORS ให้เฉพาะ domain ตัวเองแล้ว API ปลอดภัย ความจริง CORS เป็นกลไกของ browser ไม่ใช่กำแพงกันคนยิง API จาก server, script, curl หรือ bot โดยตรง ถ้า endpoint ไม่มี authentication และ authorization ที่ดี คนอื่นยังยิงมาหา API ได้

CORS ควรถูกตั้งให้ถูกต้องเพื่อลดความเสี่ยงจาก browser แต่ห้ามใช้แทนระบบ login, token, permission, rate limit หรือ server-side validation

ก่อนต่อ API ทุกครั้ง ควรมี checklist สั้น ๆ เพื่อให้ทีมไม่รีบเอา key ไปแปะแล้วจบ โดยเฉพาะยุคที่ใช้ AI เขียนโค้ดเร็วมาก ยิ่งต้องมี checklist เพื่อกันความเร็วกลายเป็นความเสี่ยง

ถ้าตอบคำถามพื้นฐานไม่ได้ เช่น key อยู่ไหน ใครเห็น key ได้ endpoint ไหนเรียกได้ มี rate limit ไหม log อยู่ที่ไหน หรือถ้า key หลุดต้อง revoke อย่างไร แปลว่ายังไม่ควรเอา API นั้นไปใช้กับข้อมูลจริง

การต่อ API ให้ request ผ่านเป็นแค่จุดเริ่มต้น แต่ระบบที่ใช้งานจริงต้องตอบได้ว่า secret อยู่ที่ไหน ใครเรียกอะไรได้ ข้อมูลไหนถูกส่งออกไป มี log ตรวจย้อนหลังไหม และถ้า key หลุดจะแก้อย่างไร

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