# OWASP API Security Top 10:2023 สรุปช่องโหว่ API

Locale: `th`

Source: `/th/compliance/owasp-top-10/api/`

Summary: สรุป 10 หมวดความเสี่ยงสำคัญตามมาตรฐาน OWASP API Security Top 10:2023 สำหรับ Web API สถาปัตยกรรม Microservices และการเชื่อมต่อระหว่างระบบ

สารบัญ

1. [ภาพรวม](/th/compliance/owasp-top-10/api/#topic-overview)
2. [API1:2023 Broken Object Level Authorization](/th/compliance/owasp-top-10/api/#broken-object-level-authorization)
3. [API2:2023 Broken Authentication](/th/compliance/owasp-top-10/api/#broken-authentication)
4. [API3:2023 Broken Object Property Level Authorization](/th/compliance/owasp-top-10/api/#broken-object-property-level-authorization)
5. [API4:2023 Unrestricted Resource Consumption](/th/compliance/owasp-top-10/api/#unrestricted-resource-consumption)
6. [API5:2023 Broken Function Level Authorization](/th/compliance/owasp-top-10/api/#broken-function-level-authorization)
7. [API6:2023 Unrestricted Access to Sensitive Business Flows](/th/compliance/owasp-top-10/api/#unrestricted-access-to-sensitive-business-flows)
8. [API7:2023 Server Side Request Forgery](/th/compliance/owasp-top-10/api/#server-side-request-forgery)
9. [API8:2023 Security Misconfiguration](/th/compliance/owasp-top-10/api/#security-misconfiguration)
10. [API9:2023 Improper Inventory Management](/th/compliance/owasp-top-10/api/#improper-inventory-management)
11. [API10:2023 Unsafe Consumption of APIs](/th/compliance/owasp-top-10/api/#unsafe-consumption-of-apis)
12. [ประเมินความพร้อม](/th/compliance/owasp-top-10/api/#compliance-readiness-checklist)
13. [หัวข้อที่เกี่ยวข้อง](/th/compliance/owasp-top-10/api/#related-compliance-frameworks)

# OWASP API Security Top 10:2023 สรุปช่องโหว่ API

สรุป 10 หมวดความเสี่ยงสำคัญตามมาตรฐาน OWASP API Security Top 10:2023 สำหรับ Web API สถาปัตยกรรม Microservices และการเชื่อมต่อระหว่างระบบ

อ้างอิงตามกรอบ OWASP ฉบับปี 2023 โดยระบุชื่อหมวดความเสี่ยงตามเอกสารทางการ

API1:2023

## Broken Object Level Authorization

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

**สรุปความเสี่ยงแบบย่อ**

| สิ่งที่อาจผิดพลาด | API รับตัวระบุออบเจ็กต์โดยไม่ยืนยันว่าผู้เรียกมีสิทธิ์เข้าถึงออบเจ็กต์นั้นจริง |
| --- | --- |
| ผลกระทบต่อธุรกิจ | การเปลี่ยนตัวระบุอาจเปิดเผยหรือแก้ไขข้อมูล ไฟล์ การชำระเงิน หรือธุรกรรมของลูกค้ารายอื่น |
| จุดควบคุมแรกที่ควรตรวจ | ตรวจสิทธิ์ทุกการอ้างอิง Object บน Server |

[![API1:2023 Broken Object Level Authorization: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-api-broken-object-level-authorization-th-v1.webp)](/assets/compliance/owasp-api-broken-object-level-authorization-th-v1.webp)

**API1:2023 Broken Object Level Authorization**

ทุก Object reference ต้องตรวจสิทธิ์

- **จุดเริ่มโจมตี** — เปลี่ยน Object ID ในคำขอ API
- **การควบคุมที่ล้มเหลว** — ไม่ตรวจสิทธิ์เจ้าของ Object
- **ผลกระทบ** — ข้อมูลลูกค้ารายอื่นถูกอ่านหรือแก้ไข
- **การหยุดการโจมตี** — ตรวจสิทธิ์ Object ฝั่ง Server ทุกครั้ง

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

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

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

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

- ตรวจสิทธิ์ทุกการอ้างอิง Object บน Server
- ใช้รูปแบบการเข้าถึงข้อมูลที่รับรู้ Tenant
- ทดสอบเส้นทาง Create, Read, Update, Delete และ Export

**ตัวอย่างโค้ดภาษา Go ที่พัฒนาเว็บด้วย Fiber v3**

```go
// ตัวอย่างที่มีช่องโหว่: 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 นั้นอาจถูกเรียกในนามผู้อื่นได้

**สรุปความเสี่ยงแบบย่อ**

| สิ่งที่อาจผิดพลาด | กลไกยืนยันตัวตน token session credential หรือการกู้คืนบัญชีของ API สามารถถูกข้าม ใช้ซ้ำ หรือใช้ในทางที่ผิด |
| --- | --- |
| ผลกระทบต่อธุรกิจ | ผู้โจมตีอาจปลอมเป็นผู้ใช้หรือบริการและเข้าถึง API ด้วยตัวตนที่ไม่ถูกต้องหรือถูกขโมย |
| จุดควบคุมแรกที่ควรตรวจ | ใช้โปรโตคอลตัวตนที่เป็นมาตรฐานและตรวจสอบ Token |

[![API2:2023 Broken Authentication: จุดเริ่มโจมตี, ความผิดพลาด, ผลกระทบ, มาตรการลดความเสี่ยง](/assets/compliance/owasp-api-broken-authentication-th-v2.webp)](/assets/compliance/owasp-api-broken-authentication-th-v2.webp)

**API2:2023 Broken Authentication**

Token ต้องพิสูจน์ตัวตนที่ถูกต้อง

- **จุดเริ่มโจมตี** — ผู้โจมตีนำ Token หมดอายุกลับมาใช้
- **ความผิดพลาด** — API ไม่ตรวจอายุ Token ก่อนยืนยันตัวตน
- **ผลกระทบ** — ยังเข้าถึงบัญชีหรือบริการด้วย Token ที่ใช้ไม่ได้แล้ว
- **มาตรการลดความเสี่ยง** — ตรวจลายเซ็น อายุ Token และสถานะ Session

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

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

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

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

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

**ตัวอย่างโค้ดภาษา Go ที่พัฒนาเว็บด้วย Fiber v3**

```go
// ตัวอย่างที่มีช่องโหว่: 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 ส่งข้อมูลเงินเดือนหรือ Internal Flag เกินมา หรือ Request ยอมให้เปลี่ยน isAdmin ได้ ปัญหานี้รวมทั้ง Excessive Data Exposure และ Mass Assignment ที่รากเหง้าเดียวกัน

**สรุปความเสี่ยงแบบย่อ**

| สิ่งที่อาจผิดพลาด | API เปิดเผยหรือยอมรับคุณสมบัติของออบเจ็กต์ที่ผู้เรียกไม่ควรอ่านหรือแก้ไขได้ |
| --- | --- |
| ผลกระทบต่อธุรกิจ | field สำคัญอาจรั่วไหล หรือ client สามารถเปลี่ยน role ราคา สถานะ workflow หรือคุณสมบัติภายในได้ |
| จุดควบคุมแรกที่ควรตรวจ | กำหนด Schema สำหรับอ่านและเขียนตาม Role อย่างชัดเจน |

[![API3:2023 Broken Object Property Level Authorization: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-api-broken-object-property-level-authorization-th-v1.webp)](/assets/compliance/owasp-api-broken-object-property-level-authorization-th-v1.webp)

**API3:2023 Broken Object Property Level Authorization**

สิทธิ์ระดับ Object ต้องรวมทุก Field

- **จุดเริ่มโจมตี** — เพิ่ม Field Role ลง JSON
- **การควบคุมที่ล้มเหลว** — Property ไม่ถูกจำกัดตามสิทธิ์
- **ผลกระทบ** — Role ราคา หรือข้อมูลลับเปลี่ยนหรือรั่ว
- **การหยุดการโจมตี** — ใช้ Read Write Schema ตามบทบาท

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

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

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

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

- กำหนด Schema สำหรับอ่านและเขียนตาม Role อย่างชัดเจน
- ส่งกลับเฉพาะ Field ที่แต่ละ Use Case ต้องใช้
- ปฏิเสธ Mass Assignment และคุณสมบัติที่ไม่รู้จัก

**ตัวอย่างโค้ดภาษา Go ที่พัฒนาเว็บด้วย Fiber v3**

```go
// ตัวอย่างที่มีช่องโหว่: 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 หรือเครดิตผู้ให้บริการจนระบบช้าหรือต้นทุนพุ่ง

**สรุปความเสี่ยงแบบย่อ**

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

[![API4:2023 Unrestricted Resource Consumption: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-api-unrestricted-resource-consumption-th-v1.webp)](/assets/compliance/owasp-api-unrestricted-resource-consumption-th-v1.webp)

**API4:2023 Unrestricted Resource Consumption**

ทรัพยากร API ต้องมีขอบเขต

- **จุดเริ่มโจมตี** — ส่งคำขอขนาดใหญ่ซ้ำ
- **การควบคุมที่ล้มเหลว** — ไม่มี Rate Size Depth Timeout
- **ผลกระทบ** — บริการช้าและค่าใช้จ่ายเพิ่ม
- **การหยุดการโจมตี** — บังคับใช้ Quota และขีดจำกัด

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

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

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

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

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

**ตัวอย่างโค้ดภาษา Go ที่พัฒนาเว็บด้วย Fiber v3**

```go
// ตัวอย่างที่มีช่องโหว่: 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 แล้วเรียกคำสั่งระดับสูงได้โดยตรง

**สรุปความเสี่ยงแบบย่อ**

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

[![API5:2023 Broken Function Level Authorization: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-api-broken-function-level-authorization-th-v2.webp)](/assets/compliance/owasp-api-broken-function-level-authorization-th-v2.webp)

**API5:2023 Broken Function Level Authorization**

Endpoint ที่ซ่อนไม่ป้องกัน Action

- **จุดเริ่มโจมตี** — เดา Route ผู้ดูแล
- **การควบคุมที่ล้มเหลว** — ไม่ตรวจสิทธิ์ตาม Function
- **ผลกระทบ** — ผู้ใช้ทั่วไปสั่งงานผู้ดูแล
- **การหยุดการโจมตี** — ตรวจ Permission ในชั้น API

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

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

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

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

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

**ตัวอย่างโค้ดภาษา Go ที่พัฒนาเว็บด้วย Fiber v3**

```go
// ตัวอย่างที่มีช่องโหว่: 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 เสมอไป แต่เกิดจากกติกาธุรกิจไม่รับมือการใช้งานในระดับเครื่องจักร

**สรุปความเสี่ยงแบบย่อ**

| สิ่งที่อาจผิดพลาด | API อนุญาตให้ทำ automation หรือเรียกซ้ำ workflow ทางธุรกิจที่มีมูลค่าสูงโดยไม่มีการต้านทานการใช้ในทางที่ผิดเพียงพอ |
| --- | --- |
| ผลกระทบต่อธุรกิจ | ผู้โจมตีอาจทำให้สินค้าหมด บิดเบือนโปรโมชัน ไล่ดูข้อเสนอ หรือทำให้ขั้นตอนยืนยันและจองล้น |
| จุดควบคุมแรกที่ควรตรวจ | จำลองกรณีใช้ผิดวัตถุประสงค์สำหรับ Workflow ที่มีมูลค่าสูง |

[![API6:2023 Unrestricted Access to Sensitive Business Flows: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-api-unrestricted-access-to-sensitive-business-flows-th-v1.webp)](/assets/compliance/owasp-api-unrestricted-access-to-sensitive-business-flows-th-v1.webp)

**API6:2023 Unrestricted Access to Sensitive Business Flows**

คำขอถูกต้องอาจใช้ Flow ผิดวัตถุประสงค์

- **จุดเริ่มโจมตี** — Bot เรียก Flow จองซ้ำ
- **การควบคุมที่ล้มเหลว** — ไม่มีการต้าน Automation
- **ผลกระทบ** — สินค้าและ Flow สำคัญล้นเกิน
- **การหยุดการโจมตี** — จำกัด Automation ตามความเสี่ยง

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

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

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

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

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

**ตัวอย่างโค้ดภาษา Go ที่พัฒนาเว็บด้วย Fiber v3**

```go
// ตัวอย่างที่มีช่องโหว่: 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 ภายนอกเข้าถึงไม่ได้

**สรุปความเสี่ยงแบบย่อ**

| สิ่งที่อาจผิดพลาด | เซิร์ฟเวอร์ดึง URL หรือปลายทางเครือข่ายที่ผู้เรียกควบคุมโดยไม่มีการควบคุมปลายทางเพียงพอ |
| --- | --- |
| ผลกระทบต่อธุรกิจ | เซิร์ฟเวอร์อาจถูกใช้เพื่อเข้าถึงบริการภายใน endpoint metadata หรือทรัพยากรเครือข่ายที่เชื่อถือได้ |
| จุดควบคุมแรกที่ควรตรวจ | อนุญาตเฉพาะปลายทางและโปรโตคอลที่จำเป็น |

[![API7:2023 Server Side Request Forgery: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-api-server-side-request-forgery-th-v1.webp)](/assets/compliance/owasp-api-server-side-request-forgery-th-v1.webp)

**API7:2023 Server Side Request Forgery**

ปลายทาง URL จากผู้เรียกไม่น่าเชื่อถือ

- **จุดเริ่มโจมตี** — ส่ง URL ให้ Server Fetch
- **การควบคุมที่ล้มเหลว** — ไม่จำกัดปลายทางและโปรโตคอล
- **ผลกระทบ** — เข้าถึงบริการภายใน
- **การหยุดการโจมตี** — Allow-list ปลายทางและโปรโตคอล

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

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

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

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

- อนุญาตเฉพาะปลายทางและโปรโตคอลที่จำเป็น
- บล็อกช่วง Private, Loopback และ Metadata ตามความเหมาะสม
- ใช้การควบคุม Egress และบันทึกคำขอขาออก

**ตัวอย่างโค้ดภาษา Go ที่พัฒนาเว็บด้วย Fiber v3**

```go
// ตัวอย่างที่มีช่องโหว่: 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 หรือฟีเจอร์ของ API ถูกตั้งค่าไม่สอดคล้องกับสิ่งที่ควรเปิดใช้งานจริง เช่น เปิด GraphQL Introspection หรือ Debug Endpoint ใน Production, ใช้ CORS แบบ Wildcard กับ Credential หรือเปิด Method เกินจำเป็น สิ่งเหล่านี้ขยาย Attack Surface แม้ Business Logic ถูกต้อง

**สรุปความเสี่ยงแบบย่อ**

| สิ่งที่อาจผิดพลาด | API gateway, CORS, header ทรัพยากรคลาวด์ การจัดการข้อผิดพลาด หรือค่าเริ่มต้นเปิดเผยมากกว่าที่ตั้งใจ |
| --- | --- |
| ผลกระทบต่อธุรกิจ | ผู้ใช้ API อาจได้รับข้อมูล debug เรียกใช้ method ที่ไม่จำเป็น หรือเชื่อมต่อกับส่วนจัดการที่ถูกเปิดเผย |
| จุดควบคุมแรกที่ควรตรวจ | Hardening Gateway และบริการ Cloud จาก Baseline |

[![API8:2023 Security Misconfiguration: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-api-security-misconfiguration-th-v1.webp)](/assets/compliance/owasp-api-security-misconfiguration-th-v1.webp)

**API8:2023 Security Misconfiguration**

Gateway กำหนดขอบเขต API

- **จุดเริ่มโจมตี** — พบ CORS เปิดกว้าง
- **การควบคุมที่ล้มเหลว** — Gateway และ Cloud ไม่ Harden
- **ผลกระทบ** — Debug และจุดจัดการถูกเผยแพร่
- **การหยุดการโจมตี** — Harden จาก Baseline

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

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

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

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

- Hardening Gateway และบริการ Cloud จาก Baseline
- ปิด Method ที่ไม่ใช้และข้อความผิดพลาดละเอียดใน Production
- ทดสอบ Configuration Drift อย่างต่อเนื่อง

**ตัวอย่างโค้ดภาษา Go ที่พัฒนาเว็บด้วย Fiber v3**

```go
// ตัวอย่างที่มีช่องโหว่: 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 ได้ ผู้โจมตีมักเลือกเส้นทางที่ทีมลืมไปแล้ว

**สรุปความเสี่ยงแบบย่อ**

| สิ่งที่อาจผิดพลาด | ทีมไม่ทราบ API host เวอร์ชัน environment เจ้าของ และ data flow ที่เปิดเผยครบถ้วน |
| --- | --- |
| ผลกระทบต่อธุรกิจ | endpoint เก่าหรือ shadow endpoint อาจยังเปิดสู่อินเทอร์เน็ตพร้อมการควบคุมล้าสมัยหรือข้อมูลสำคัญที่ไม่ได้บันทึกไว้ |
| จุดควบคุมแรกที่ควรตรวจ | รักษาบัญชี API Version และ Host ที่มีเจ้าของชัดเจน |

[![API9:2023 Improper Inventory Management: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-api-improper-inventory-management-th-v1.webp)](/assets/compliance/owasp-api-improper-inventory-management-th-v1.webp)

**API9:2023 Improper Inventory Management**

ป้องกัน API ที่ไม่รู้จักไม่ได้

- **จุดเริ่มโจมตี** — พบ API เวอร์ชันเก่า
- **การควบคุมที่ล้มเหลว** — ไม่รู้ Host Version และ Owner
- **ผลกระทบ** — Shadow Endpoint ออนไลน์พร้อม Control ล้าสมัย
- **การหยุดการโจมตี** — ดูแล Inventory ที่มี Owner

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

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

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

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

- รักษาบัญชี API Version และ Host ที่มีเจ้าของชัดเจน
- เลิกใช้ Endpoint อย่างเป็นระบบและลบ DNS / Route ที่ล้าสมัย
- บันทึกการจัดชั้นข้อมูลและ Contract ของผู้ใช้ API

**ตัวอย่างโค้ดภาษา Go ที่พัฒนาเว็บด้วย Fiber v3**

```go
// ตัวอย่างที่มีช่องโหว่: 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 และสิทธิ์ หากผู้ให้บริการภายนอกถูกโจมตีหรือส่งข้อมูลผิด ระบบของเราอาจกลายเป็นจุดส่งผ่านผลกระทบต่อผู้ใช้เอง

**สรุปความเสี่ยงแบบย่อ**

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

[![API10:2023 Unsafe Consumption of APIs: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-api-unsafe-consumption-of-apis-th-v2.webp)](/assets/compliance/owasp-api-unsafe-consumption-of-apis-th-v2.webp)

**API10:2023 Unsafe Consumption of APIs**

API ภายนอกคือ Trust Boundary

- **จุดเริ่มโจมตี** — Upstream ส่ง Response อันตราย
- **การควบคุมที่ล้มเหลว** — เชื่อข้อมูลต้นทางเกินไป
- **ผลกระทบ** — ข้อมูลผิดสั่งงานไม่ปลอดภัย
- **การหยุดการโจมตี** — ตรวจและจำกัด Response

ภาพเปรียบเทียบเส้นทางที่ไม่ปลอดภัยกับจุดควบคุมที่ตัดเส้นทางนั้น กดภาพเพื่อดูขนาดเต็ม

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

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

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

- ตรวจสอบและจำกัด Response จากต้นทาง
- ใช้ Timeout, การยืนยันตัวตน และสิทธิ์ Least Privilege สำหรับ Integration
- วางแผนสำหรับความล้มเหลวของผู้ให้บริการและติดตามสถานะของ Dependency

**ตัวอย่างโค้ดภาษา Go ที่พัฒนาเว็บด้วย Fiber v3**

```go
// ตัวอย่างที่มีช่องโหว่: 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 }
```

### เครื่องมือประเมินความพร้อม

คลิกเลือกรายการที่องค์กรของท่านได้ดำเนินการแล้ว เพื่อคำนวณระดับความพร้อมเบื้องต้น

0%

API1:2023 - ตรวจสอบสิทธิ์การเข้าถึงระดับ Object (Broken Object Level Authorization - BOLA)
          
          
            
            API2:2023 - กำหนดระบบยืนยันตัวตนสำหรับทุก API Endpoint ให้รัดกุม (Broken Authentication)
          
          
            
            API3:2023 - จำกัดการส่งคืน Property และ Field ของ Object เฉพาะที่จำเป็น (Broken Property Level Authorization)
          
          
            
            API4:2023 - จำกัดปริมาณการเรียกใช้งานเพื่อป้องกันการใช้งานทรัพยากรเกินขนาด (Unrestricted Resource Consumption)
          
          
            
            API5:2023 - ตรวจสอบสิทธิ์การเข้าถึงฟังก์ชันระดับผู้ดูแลระบบ (Broken Function Level Authorization - BFLA)
          
          
            
            API6:2023 - ตรวจสอบความปลอดภัยการเข้าถึงธุรกิจหลักและการส่งข้อมูลอัตโนมัติ (Unrestricted Access to Business Flows)
          
          
            
            API7:2023 - ป้องกันช่องโหว่การเรียกขอข้อมูลฝั่งเซิร์ฟเวอร์ (Server-Side Request Forgery - SSRF)
          
          
            
            API8:2023 - ตั้งค่าระบบความปลอดภัย API ให้มั่นคงและปิดการแสดงผลข้อความข้อผิดพลาดภายใน
          
          
            
            API9:2023 - จัดทำบัญชีรายการ API Endpoint ทั้งหมดและยกเลิก Endpoint ที่ล้าสมัย
          
          
            
            API10:2023 - ตรวจสอบความน่าเชื่อถือของการใช้งาน API ร่วมกับบุคคลที่สาม (Unsafe Consumption of APIs)

ประเมินความพร้อม

เลือกรายการด้านบนเพื่อประเมินผล

[ปรึกษาผู้เชี่ยวชาญ และขอใบเสนอราคา](/th/#contact)

## หัวข้อและกฎหมายกำกับดูแลที่เกี่ยวข้อง

- [
                OWASP Top 10:2025 สำหรับเว็บแอปพลิเคชัน
                
              ](/th/compliance/owasp-top-10/web/)
- [
                ธุรกิจภายใต้ ก.ล.ต. ต้องทำ Penetration Testing ไหม
                
              ](/th/compliance/sec/)
- [
                สมาชิก NDID ต้องทำ Penetration Testing อะไรบ้าง
                
              ](/th/compliance/ndid/)
- [
                PCI DSS v4.0.1: VA, ASV Scan, Pentest และ Segmentation
                
              ](/th/compliance/pci-dss/)

## เอกสารอ้างอิง OWASP

[เปิดเอกสาร OWASP ฉบับทางการ ](https://owasp.org/API-Security/editions/2023/en/0x00-header/)

เปิดภาพขนาดเต็มเพื่อซูม

## ต้องการทำ Pentest ให้สอดคล้องกับข้อกำหนดเหล่านี้?

เล่าขอบเขตระบบและข้อกำหนดที่ต้องปฏิบัติตามให้เราฟัง ทีม STH จะช่วยประเมินแนวทางและจัดทำใบเสนอราคาให้

[ขอใบเสนอราคา Pentest](/th/#contact)

อัปเดตล่าสุด 16 ตุลาคม 2569