API Security (ความปลอดภัยของ API) คือการป้องกันช่องทางที่โปรแกรมหนึ่งใช้ขอข้อมูลหรือสั่งงานโปรแกรมอื่น ช่องทางนั้นเรียกว่า API (Application Programming Interface) ตัวอย่างคือช่องทางที่แอปธนาคารบนมือถือใช้ขอข้อมูลบัญชีจากเซิร์ฟเวอร์ของธนาคาร OWASP API Security Top 10 คือรายการความเสี่ยงของ API 10 ข้อ จัดทำโดย OWASP ซึ่งเป็นชุมชนที่ทำงานด้านความปลอดภัยของแอปพลิเคชัน บทความนี้อธิบายทั้ง 10 ข้อด้วยภาษาที่ผู้บริหารและทีมไอทีอ่านแล้วเข้าใจ พร้อมแนวทางป้องกัน
API คืออะไร และทำไมจึงถูกโจมตี
API ทำงานแบบถามตอบ โปรแกรมฝั่งผู้เรียก (client) ส่งคำขอไปยังที่อยู่ที่เรียกว่า endpoint แล้วเซิร์ฟเวอร์ตอบกลับเป็นข้อมูล ตัวอย่างสมมติคือคำขอ GET /orders/1001 ซึ่งขอคำสั่งซื้อหมายเลข 1001 หมายเลขนี้คือ object ID (รหัสที่ชี้ไปยังข้อมูลหนึ่งรายการ) endpoint แต่ละตัวต้องตัดสินเองว่าผู้เรียกมีสิทธิ์ดูข้อมูลรายการนั้นหรือไม่
API เป็นเป้าหมายของผู้โจมตี เพราะโปรแกรมเรียกได้โดยตรง ผู้โจมตีไม่ต้องกดทีละหน้าจอ สคริปต์ (โปรแกรมสั้น ๆ ที่สั่งงานอัตโนมัติ) ส่งคำขอได้เป็นพันครั้ง หน้าจอของแอปก็ซ่อนจุดอ่อนไม่ได้ เพราะผู้โจมตีส่งคำขอได้เองโดยไม่ต้องใช้หน้าจอเลย
OWASP API Security Top 10 ฉบับ 2023 มีอะไรบ้าง
ฉบับล่าสุดที่ลงไว้บนเว็บไซต์ของโครงการ (ตรวจเมื่อ 27 ตุลาคม 2026) คือฉบับ 2023 เราไม่พบประกาศฉบับที่ใหม่กว่า ทั้ง 10 ข้อมีดังนี้:
- API1:2023 Broken Object Level Authorization: API ไม่ตรวจว่าผู้เรียกมีสิทธิ์ใช้ข้อมูลรายการนั้น เมื่อเปลี่ยนรหัส (ID) ในคำขอ จึงได้ข้อมูลของคนอื่น
- API2:2023 Broken Authentication: ระบบ login การกู้รหัสผ่าน หรือ token (ข้อมูลที่ใช้แทนตัวผู้ใช้หลัง login) ถูกใช้ในทางที่ผิดได้ เช่น เดารหัสผ่านซ้ำได้ไม่จำกัดครั้ง
- API3:2023 Broken Object Property Level Authorization: ไม่ตรวจสิทธิ์ระดับฟิลด์ (แต่ละช่องข้อมูลในรายการ) จึงส่งฟิลด์ลับออกไป หรือยอมให้ผู้ใช้แก้ฟิลด์ที่ไม่ควรแก้
- API4:2023 Unrestricted Resource Consumption: ไม่จำกัดทรัพยากรที่คำขอใช้ได้ ระบบจึงล่ม หรือค่าใช้จ่ายพุ่งสูง
- API5:2023 Broken Function Level Authorization: ไม่ตรวจว่าผู้ใช้มีสิทธิ์เรียกฟังก์ชันนั้น เช่น ผู้ใช้ทั่วไปเรียกฟังก์ชันของผู้ดูแลระบบได้
- API6:2023 Unrestricted Access to Sensitive Business Flows: สคริปต์ทำขั้นตอนทางธุรกิจ เช่น ซื้อสินค้าหรือจองคิว ซ้ำโดยอัตโนมัติจนธุรกิจเสียหาย
- API7:2023 Server Side Request Forgery: API ไปดึง URL (ที่อยู่เว็บ) ที่ผู้ใช้ส่งมาโดยไม่ตรวจ ผู้โจมตีจึงใช้เซิร์ฟเวอร์ไปเรียกระบบภายในได้
- API8:2023 Security Misconfiguration: ตั้งค่าเริ่มต้นไว้ไม่ปลอดภัย หรือเปิดฟีเจอร์ที่ไม่จำเป็นทิ้งไว้
- API9:2023 Improper Inventory Management: องค์กรไม่รู้ว่ามีโฮสต์ (เครื่องที่ให้บริการ API) และเวอร์ชันของ API อะไรบ้าง ตัวเก่าที่ถูกลืมจึงยังเปิดอยู่
- API10:2023 Unsafe Consumption of APIs: เชื่อข้อมูลจาก API ของบุคคลที่สาม (ผู้ให้บริการภายนอกองค์กร) มากกว่าข้อมูลจากผู้ใช้
ข้อ API3 ในฉบับ 2023 รวมสองปัญหาที่เดิมแยกกัน คือการส่งข้อมูลเกินจำเป็น (excessive data exposure) และการยอมให้ผู้ใช้แก้ฟิลด์ที่ไม่ควรแก้ (mass assignment) รายการนี้เป็นจุดเริ่มต้นสำหรับการตรวจ ไม่ใช่รายการช่องโหว่ทั้งหมด จึงควรใช้ควบคู่กับการทดสอบและมาตรฐานอื่น
กลุ่มปัญหาเรื่องสิทธิ์: API1, API3 และ API5
สามข้อนี้คือปัญหาเดียวกันใน 3 ระดับ ระดับแรกคือข้อมูลทีละรายการ (object) เช่น คำสั่งซื้อหนึ่งใบ ระดับที่สองคือฟิลด์ (property) ในข้อมูลนั้น เช่น ราคาหรือสถานะ ระดับที่สามคือฟังก์ชัน (function) เช่น การออกคำเชิญผู้ดูแลระบบ ต้องตรวจสิทธิ์ทั้งสามระดับที่ฝั่งเซิร์ฟเวอร์ ทุกครั้งที่มีคำขอ
ตัวอย่างข้อ API1 จากหน้าทางการของ OWASP คือ API ที่รับรหัสข้อมูลจากผู้เรียก แต่ไม่ตรวจว่ารหัสนั้นเป็นของผู้เรียกจริง ผู้โจมตีจึงเปลี่ยนรหัสในคำขอเพื่อดึงข้อมูลของคนอื่น OWASP ยกกรณีผู้โจมตีที่ไล่ดูชื่อร้านค้าได้ครบทุกร้าน แล้วเขียนสคริปต์ดึงข้อมูลยอดขายของร้านค้าหลายพันร้าน GUID (รหัสสุ่มยาว ๆ ที่เดายาก) ช่วยป้องกันได้อีกชั้น แต่ใช้แทนการตรวจสิทธิ์ไม่ได้
ความเสี่ยงอีก 7 ข้อในภาพรวม
ข้อที่เหลือเป็นปัญหาคนละแบบ หน้าทางการของ OWASP มีตัวอย่างและวิธีป้องกันของแต่ละข้อ สรุปได้ดังนี้:
- API2 การยืนยันตัวตนบกพร่อง: ใช้มาตรฐานที่มีอยู่แล้วแทนโค้ดที่เขียนเอง จำกัดจำนวนครั้งที่ลอง login และกู้รหัสผ่าน ขอให้ผู้ใช้ยืนยันตัวตนซ้ำก่อนทำงานสำคัญ เพิ่ม MFA (การยืนยันตัวตนมากกว่าหนึ่งวิธีพร้อมกัน) ถ้าทำได้ และไม่ใช้ API key (รหัสที่ใช้แทนโปรแกรม) ยืนยันตัวผู้ใช้
- API4 ใช้ทรัพยากรไม่จำกัด: ตั้งขีดจำกัดเรื่องเวลา หน่วยความจำ ขนาดไฟล์ที่อัปโหลด และจำนวนรายการต่อหน้า ใช้ rate limiting (การจำกัดจำนวนคำขอในช่วงเวลาหนึ่ง) และตั้งเพดานค่าใช้จ่ายหรือการแจ้งเตือนบิลกับผู้ให้บริการภายนอก OWASP ยกตัวอย่างสคริปต์ที่สั่งส่ง SMS รีเซ็ตรหัสผ่านซ้ำ ๆ จนผู้ให้บริการส่งข้อความหลายหมื่นฉบับในไม่กี่นาที
- API6 ขั้นตอนธุรกิจที่ถูกใช้อัตโนมัติ: ระบุขั้นตอนที่ถ้าถูกเรียกถี่เกินไปแล้วธุรกิจจะเสียหาย เช่น การซื้อสินค้าที่มีจำกัดเพื่อนำไปขายต่อ จากนั้นตรวจจับพฤติกรรมที่ไม่ใช่คน เช่น ทำเร็วเกินกว่าคนทำได้ และป้องกัน API ที่โปรแกรมเรียกกันเอง (เครื่องต่อเครื่อง) ให้เข้มขึ้น
- API7 SSRF (หลอกให้เซิร์ฟเวอร์เรียกที่อยู่ที่ผู้โจมตีเลือก): แยกส่วนที่ดึง URL ออกจากเครือข่ายภายใน อนุญาตเฉพาะโดเมน โปรโตคอล และพอร์ตที่อนุมัติไว้ ปิดการเปลี่ยนเส้นทางอัตโนมัติ (redirect) และไม่ส่งคำตอบดิบกลับไปให้ผู้ใช้
- API8 การตั้งค่าไม่ปลอดภัย: มีขั้นตอนทำให้ระบบรัดกุม (hardening คือปิดช่องทางที่ไม่จำเป็นและตั้งค่าให้ปลอดภัย) ที่ทำซ้ำได้ ตรวจการตั้งค่าเป็นระยะ เข้ารหัสการสื่อสารทุกเส้นทาง จำกัดชนิดคำขอที่รับ และไม่ให้ข้อความ error เผยรายละเอียดภายในระบบ
- API9 ไม่รู้ว่ามี API อะไรบ้าง: ทำบัญชีรายการของโฮสต์ เวอร์ชัน และบริการที่เชื่อมต่อ พร้อมบันทึกว่าแต่ละตัวจัดการข้อมูลอ่อนไหวอะไร ป้องกันทุกเวอร์ชันที่เปิดอยู่ด้วยมาตรการเดียวกัน และเลิกใช้หรือแก้ไขเวอร์ชันเก่า
- API10 เชื่อ API ภายนอกมากเกินไป: ประเมินความปลอดภัยของผู้ให้บริการ เข้ารหัสการเชื่อมต่อทุกจุด ตรวจสอบและทำความสะอาดข้อมูลจากภายนอกก่อนใช้ และไม่ตามการเปลี่ยนเส้นทาง (redirect) โดยไม่ตรวจกับรายการปลายทางที่อนุมัติไว้
แนวป้องกันโดยรวม
ทีมทำตามขั้นตอนเหล่านี้ตามลำดับได้ โดยเริ่มจาก API ที่คนภายนอกเรียกถึงได้ก่อน:
- ทำบัญชีรายการ API: บันทึกโฮสต์ เวอร์ชัน endpoint และข้อมูลอ่อนไหวที่แต่ละตัวจัดการ
- ตรวจสิทธิ์ที่เซิร์ฟเวอร์ทุกคำขอ: ตรวจทั้งระดับข้อมูลรายการ ฟิลด์ และฟังก์ชัน และเขียนการทดสอบสิทธิ์แบบอัตโนมัติ
- จำกัดการใช้ทรัพยากร: จำกัดจำนวนคำขอ ขนาดข้อมูล และค่าใช้จ่ายกับผู้ให้บริการภายนอก
- ตรวจข้อมูลที่รับเข้า: รวมถึงข้อมูลจาก API ของบุคคลที่สาม และจำกัดปลายทางที่เซิร์ฟเวอร์ไปดึงข้อมูลได้
- ตั้งค่าให้รัดกุมและตรวจซ้ำ: ใช้ขั้นตอนทำให้ระบบรัดกุมที่ทำซ้ำได้ และตรวจการตั้งค่าอย่างสม่ำเสมอ
API gateway (ด่านหน้าของ API ที่บังคับ login จำกัดจำนวนคำขอ และบันทึกคำขอ) และ WAF (ไฟร์วอลล์ที่กรองคำขอเว็บ) ช่วยได้ในบางข้อ เช่น การจำกัดจำนวนคำขอ แต่แทนการตรวจสิทธิ์ในโค้ดของแอปไม่ได้ เพราะมีแต่แอปที่รู้ว่าข้อมูลแต่ละรายการเป็นของใคร
เมื่อ AI agent (ซอฟต์แวร์ AI ที่ลงมือทำงานแทนผู้ใช้) หรือเครื่องมือเชื่อมต่อเรียกระบบในนามผู้ใช้ ก็มักเรียกผ่าน API เช่นกัน ปัญหาเรื่องสิทธิ์ข้างต้นจึงเกิดกับงานเหล่านั้นได้ด้วย อ่านต่อได้ที่ MCP คืออะไร: สถาปัตยกรรม ความเสี่ยง และวิธีรับมือเชิงเทคนิค และ Agentic AI Security ส่วนความเสี่ยงของตัวเว็บแอป ดู OWASP Top 10 สำหรับเว็บแอป
ข้อผิดพลาดที่พบบ่อย
- เชื่อว่ารหัสที่เดายากแปลว่าปลอดภัย: GUID ช่วยได้ แต่ถ้าไม่ตรวจสิทธิ์ ใครได้รหัสไปก็ดึงข้อมูลได้
- ตรวจสิทธิ์แค่ที่หน้าจอแอป: ผู้โจมตีส่งคำขอเองได้โดยไม่ผ่านหน้าจอ
- ปล่อย API เวอร์ชันเก่าหรือโฮสต์ทดสอบเปิดไว้: ตัวที่ถูกลืมมักไม่มีมาตรการป้องกันเท่าตัวหลัก
- เชื่อข้อมูลจาก API ของบุคคลที่สามมากกว่าข้อมูลจากผู้ใช้: ต้องตรวจก่อนใช้เหมือนกัน
- ไม่ตั้งเพดานค่าใช้จ่ายกับบริการภายนอก: เช่น บริการส่ง SMS ที่ถูกเรียกซ้ำจนบิลพุ่ง
ขั้นแรกที่ทำได้ทันที
- เลือก API ที่เปิดสู่ภายนอก 5 ตัวแรกและทำบัญชีรายการ โดยบันทึกเจ้าของและข้อมูลที่แต่ละตัวจัดการ
- ในระบบทดสอบของตนเอง ลอง login เป็นผู้ใช้สองคน แล้วให้คนหนึ่งลองเรียกข้อมูลของอีกคน ถ้าทำได้ แสดงว่ามีช่องโหว่ API1
- ตรวจว่า endpoint ของ login การกู้รหัสผ่าน และการส่งรหัสยืนยันครั้งเดียว มีการจำกัดจำนวนครั้ง
- ตั้งการแจ้งเตือนค่าใช้จ่ายกับผู้ให้บริการภายนอกที่ API เรียกใช้
- หา API เวอร์ชันเก่าและโฮสต์ทดสอบที่ยังเปิดอยู่ แล้วตัดสินใจว่าจะเลิกใช้หรือป้องกันให้เท่าตัวหลัก
ดูว่าองค์กรอยู่ตรงไหนได้ที่ แบบประเมินตนเอง
แหล่งอ้างอิงและข้อมูลเพิ่มเติม
- OWASP API Security Project: หน้าโครงการ แสดงฉบับ 2023 และ 2019
- OWASP API Security Top 10 2023: รายการ 10 ข้อฉบับ 2023
- API1:2023 Broken Object Level Authorization: ตัวอย่างและวิธีป้องกันข้อ API1
- API9:2023 Improper Inventory Management: ตัวอย่างและวิธีป้องกันข้อ API9
- OWASP REST Security Cheat Sheet: แนวปฏิบัติสำหรับ REST API
- OWASP Authorization Cheat Sheet: แนวทางตรวจสิทธิ์
- OWASP SSRF Prevention Cheat Sheet: วิธีป้องกัน SSRF