OWASP API Security Top 10:2023

API1:2023

Broken Object Level Authorization

Broken Object Level Authorization หรือ BOLA คือ API รับ identifier ของ object เช่น userId, orderId หรือ documentId แล้วไม่ตรวจว่าผู้เรียกเป็นเจ้าของหรือมีสิทธิ์ต่อ object นั้นจริง ผู้ใช้ทั่วไปจึงอาจเปลี่ยนเลข ID ใน request เพื่ออ่าน แก้ไข หรือลบข้อมูลของบัญชีอื่นได้.

ผลกระทบที่ควรพิจารณา

การเปลี่ยนตัวระบุอาจเปิดเผยหรือแก้ไขข้อมูล ไฟล์ การชำระเงิน หรือธุรกรรมของลูกค้ารายอื่น

แนวทางลดความเสี่ยง

• ตรวจสิทธิ์ทุกการอ้างอิงออบเจ็กต์บนเซิร์ฟเวอร์
• ใช้รูปแบบการเข้าถึงข้อมูลที่รับรู้ผู้เช่า
• ทดสอบเส้นทาง create read update delete และ export

// ตัวอย่างที่มีช่องโหว่: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// ตัวอย่างที่แก้ไขแล้ว: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }

API2:2023

Broken Authentication

Broken Authentication คือ API พิสูจน์ตัวตนของ client หรือปกป้อง credential และ token ไม่ถูกต้อง เช่น ออก token ที่คาดเดาได้, ไม่ตรวจ signature หรือ expiry, เปิดให้เดารหัสผ่านไม่จำกัด หรือไม่ยกเลิก session หลังเปลี่ยนรหัสผ่าน เมื่อกลไกนี้พัง ทุก endpoint ที่เชื่อ token นั้นอาจถูกเรียกในนามผู้อื่นได้.

ผลกระทบที่ควรพิจารณา

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

แนวทางลดความเสี่ยง

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

// ตัวอย่างที่มีช่องโหว่: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// ตัวอย่างที่แก้ไขแล้ว: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }

API3:2023

Broken Object Property Level Authorization

Broken Object Property Level Authorization เกิดเมื่อ API ตรวจสิทธิ์ระดับ object แล้ว แต่ไม่ตรวจว่าผู้เรียกควรเห็นหรือแก้ field ใดภายใน object เช่น response ส่ง salary หรือ internal flag เกินมา หรือ request ยอมให้เปลี่ยน isAdmin ได้ ปัญหานี้รวมทั้ง excessive data exposure และ mass assignment ที่รากเหง้าเดียวกัน.

ผลกระทบที่ควรพิจารณา

field สำคัญอาจรั่วไหล หรือ client สามารถเปลี่ยน role ราคา สถานะ workflow หรือคุณสมบัติภายในได้

แนวทางลดความเสี่ยง

• กำหนด schema สำหรับอ่านและเขียนตาม role อย่างชัดเจน
• ส่งกลับเฉพาะ field ที่แต่ละ use case ต้องใช้
• ปฏิเสธ mass assignment และคุณสมบัติที่ไม่รู้จัก

// ตัวอย่างที่มีช่องโหว่: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// ตัวอย่างที่แก้ไขแล้ว: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }

API4:2023

Unrestricted Resource Consumption

Unrestricted Resource Consumption คือ API ไม่มีขอบเขตที่เหมาะสมต่อจำนวน request, ขนาด payload, pagination, query complexity หรือการเรียกบริการที่มีค่าใช้จ่าย เช่น SMS และการตรวจ biometric ผู้โจมตีหรือ client ที่ผิดพลาดอาจใช้ CPU, memory, bandwidth หรือเครดิตผู้ให้บริการจนระบบช้าหรือต้นทุนพุ่ง.

ผลกระทบที่ควรพิจารณา

client อาจทำให้บริการช้าลง สร้างค่าใช้จ่ายที่ไม่คาดคิด หรือทำให้ฟังก์ชัน API สำคัญใช้ไม่ได้สำหรับผู้อื่น

แนวทางลดความเสี่ยง

• กำหนดขีดจำกัดอัตรา ขนาด ความลึก และเวลา
• ใช้ quota และการควบคุมตามต้นทุนแยกตาม client
• ติดตามภาวะอิ่มตัวของทรัพยากรและลดระดับบริการอย่างปลอดภัย

// ตัวอย่างที่มีช่องโหว่: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// ตัวอย่างที่แก้ไขแล้ว: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }

API5:2023

Broken Function Level Authorization

Broken Function Level Authorization คือ API แยก endpoint สำหรับผู้ใช้ทั่วไปและผู้ดูแลไม่ชัด หรือไม่ตรวจ role ทุกครั้งที่เรียก function สำคัญ เช่น endpoint export, approve, refund หรือจัดการผู้ใช้ ผู้โจมตีที่มี token ปกติอาจเดา path หรือ method แล้วเรียกคำสั่งระดับสูงได้โดยตรง.

ผลกระทบที่ควรพิจารณา

ผู้ใช้ทั่วไปสามารถเรียกคำสั่งของผู้ดูแล การอนุมัติ รายงาน หรือการกำหนดค่าได้

แนวทางลดความเสี่ยง

• บังคับใช้สิทธิ์ของฟังก์ชันในชั้น API
• ปฏิเสธเป็นค่าเริ่มต้นและรวมศูนย์การตัดสินนโยบาย
• ทดสอบทุก role กับทุก endpoint ที่สำคัญ

// ตัวอย่างที่มีช่องโหว่: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// ตัวอย่างที่แก้ไขแล้ว: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }

API6:2023

Unrestricted Access to Sensitive Business Flows

Unrestricted Access to Sensitive Business Flows คือ API เปิด flow ธุรกิจที่ถูกต้องตามหน้าที่ แต่ไม่มีการชดเชยความเสี่ยงเมื่อถูก automation จำนวนมาก เช่น กดซื้อตั๋ว, ใช้ coupon, สมัครบัญชี หรือส่ง comment ซ้ำ ๆ ปัญหาไม่ได้เกิดจาก injection เสมอไป แต่เกิดจากกติกาธุรกิจไม่รับมือการใช้งานในระดับเครื่องจักร.

ผลกระทบที่ควรพิจารณา

ผู้โจมตีอาจทำให้สินค้าหมด บิดเบือนโปรโมชัน ไล่ดูข้อเสนอ หรือทำให้ขั้นตอนยืนยันและจองล้น

แนวทางลดความเสี่ยง

• จำลองกรณีใช้ผิดวัตถุประสงค์สำหรับ workflow ที่มีมูลค่าสูง
• ใช้การควบคุมอัตรา ความเร็ว และทุจริตให้เหมาะกับ flow
• สังเกต metric ทางธุรกิจและตรวจสอบความผิดปกติ

// ตัวอย่างที่มีช่องโหว่: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// ตัวอย่างที่แก้ไขแล้ว: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }

API7:2023

Server Side Request Forgery

Server Side Request Forgery หรือ SSRF เกิดเมื่อ API ให้ผู้ใช้ระบุ URL แล้ว server ไปดึงทรัพยากรนั้นโดยไม่ตรวจปลายทางอย่างเข้มงวด ผู้โจมตีจึงอาจบังคับให้ server ที่อยู่ในเครือข่ายเชื่อถือได้เรียก internal service, metadata endpoint หรือปลายทางที่ firewall ภายนอกเข้าถึงไม่ได้.

ผลกระทบที่ควรพิจารณา

เซิร์ฟเวอร์อาจถูกใช้เพื่อเข้าถึงบริการภายใน endpoint metadata หรือทรัพยากรเครือข่ายที่เชื่อถือได้

แนวทางลดความเสี่ยง

• อนุญาตเฉพาะปลายทางและโปรโตคอลที่จำเป็น
• บล็อกช่วง private loopback และ metadata ตามความเหมาะสม
• ใช้การควบคุม egress และบันทึกคำขอขาออก

// ตัวอย่างที่มีช่องโหว่: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// ตัวอย่างที่แก้ไขแล้ว: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }

API8:2023

Security Misconfiguration

API Security Misconfiguration คือ gateway, server, cloud, CORS, TLS, error handling หรือ feature ของ API ถูกตั้งค่าไม่สอดคล้องกับสิ่งที่ควรเปิดใช้งานจริง เช่น เปิด GraphQL introspection หรือ debug endpoint ใน production, ใช้ CORS แบบ wildcard กับ credential หรือเปิด method เกินจำเป็น สิ่งเหล่านี้ขยาย attack surface แม้ business logic ถูกต้อง.

ผลกระทบที่ควรพิจารณา

ผู้ใช้ API อาจได้รับข้อมูล debug เรียกใช้ method ที่ไม่จำเป็น หรือเชื่อมต่อกับส่วนจัดการที่ถูกเปิดเผย

แนวทางลดความเสี่ยง

• hardening gateway และบริการคลาวด์จาก baseline
• ปิด method ที่ไม่ใช้และข้อความผิดพลาดละเอียดใน production
• ทดสอบ configuration drift อย่างต่อเนื่อง

// ตัวอย่างที่มีช่องโหว่: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// ตัวอย่างที่แก้ไขแล้ว: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }

API9:2023

Improper Inventory Management

Improper Inventory Management คือองค์กรไม่รู้ครบว่ามี API host, endpoint, version, environment และ owner ใดถูกเปิดใช้งานอยู่ API เก่าที่ไม่ได้เลิกใช้จริง, staging ที่เปิดสาธารณะ หรือ endpoint debug ที่เอกสารไม่กล่าวถึงจึงหลุดจาก patching และ monitoring ได้ ผู้โจมตีมักเลือกเส้นทางที่ทีมลืมไปแล้ว.

ผลกระทบที่ควรพิจารณา

endpoint เก่าหรือ shadow endpoint อาจยังเปิดสู่อินเทอร์เน็ตพร้อมการควบคุมล้าสมัยหรือข้อมูลสำคัญที่ไม่ได้บันทึกไว้

แนวทางลดความเสี่ยง

• รักษาบัญชี API version และ host ที่มีเจ้าของชัดเจน
• เลิกใช้ endpoint อย่างเป็นระบบและลบ DNS/route ที่ล้าสมัย
• บันทึกการจัดชั้นข้อมูลและ contract ของผู้ใช้ API

// ตัวอย่างที่มีช่องโหว่: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// ตัวอย่างที่แก้ไขแล้ว: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }

API10:2023

Unsafe Consumption of APIs

Unsafe Consumption of APIs คือบริการของเรารับข้อมูลจาก third-party API แล้วเชื่อถือเกินกว่าข้อมูลจากผู้ใช้ เช่น นำ response ไป render, query, redirect หรืออัปเดต record โดยไม่ตรวจ schema และสิทธิ์ หากผู้ให้บริการภายนอกถูกโจมตีหรือส่งข้อมูลผิด ระบบของเราอาจกลายเป็นจุดส่งผ่านผลกระทบต่อผู้ใช้เอง.

ผลกระทบที่ควรพิจารณา

ผู้ให้บริการที่ถูกโจมตีหรือไม่น่าเชื่อถืออาจส่งข้อมูลผิด ทำให้เกิด action ที่ไม่ปลอดภัย หรือทำให้บริการที่พึ่งพาเสื่อมลง

แนวทางลดความเสี่ยง

• ตรวจสอบและจำกัด response จากต้นทาง
• ใช้ timeout การยืนยันตัวตน และสิทธิ์น้อยที่สุดสำหรับ integration
• วางแผนสำหรับความล้มเหลวของผู้ให้บริการและติดตามสุขภาพของ dependency

// ตัวอย่างที่มีช่องโหว่: trust request-controlled target
app.Get("/records/:id", func(c fiber.Ctx) error {
  return c.JSON(repo.Find(c.Params("id")))
})

// ตัวอย่างที่แก้ไขแล้ว: authorize server-side
if !policy.CanRead(c.Locals("principal"), id) { return fiber.ErrForbidden }