# OWASP Top 10:2025 สำหรับเว็บแอปพลิเคชัน

Locale: `th`

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

Summary: สรุป 10 หมวดความเสี่ยงสำคัญตามมาตรฐาน OWASP Top 10:2025 สำหรับเว็บแอปพลิเคชัน ใช้เป็นแนวทางกำหนดขอบเขตการทดสอบ ประเมินช่องโหว่ และวางแผนยกระดับความมั่นคงปลอดภัย

สารบัญ

1. [ภาพรวม](/th/compliance/owasp-top-10/web/#topic-overview)
2. [A01:2025 Broken Access Control](/th/compliance/owasp-top-10/web/#broken-access-control)
3. [A02:2025 Security Misconfiguration](/th/compliance/owasp-top-10/web/#security-misconfiguration)
4. [A03:2025 Software Supply Chain Failures](/th/compliance/owasp-top-10/web/#software-supply-chain-failures)
5. [A04:2025 Cryptographic Failures](/th/compliance/owasp-top-10/web/#cryptographic-failures)
6. [A05:2025 Injection](/th/compliance/owasp-top-10/web/#injection)
7. [A06:2025 Insecure Design](/th/compliance/owasp-top-10/web/#insecure-design)
8. [A07:2025 Authentication Failures](/th/compliance/owasp-top-10/web/#authentication-failures)
9. [A08:2025 Software or Data Integrity Failures](/th/compliance/owasp-top-10/web/#software-or-data-integrity-failures)
10. [A09:2025 Security Logging and Alerting Failures](/th/compliance/owasp-top-10/web/#security-logging-and-alerting-failures)
11. [A10:2025 Mishandling of Exceptional Conditions](/th/compliance/owasp-top-10/web/#mishandling-exceptional-conditions)
12. [ประเมินความพร้อม](/th/compliance/owasp-top-10/web/#compliance-readiness-checklist)
13. [หัวข้อที่เกี่ยวข้อง](/th/compliance/owasp-top-10/web/#related-compliance-frameworks)

# OWASP Top 10:2025 สำหรับเว็บแอปพลิเคชัน

สรุป 10 หมวดความเสี่ยงสำคัญตามมาตรฐาน OWASP Top 10:2025 สำหรับเว็บแอปพลิเคชัน ใช้เป็นแนวทางกำหนดขอบเขตการทดสอบ ประเมินช่องโหว่ และวางแผนยกระดับความมั่นคงปลอดภัย

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

A01:2025

## Broken Access Control

Broken Access Control คือระบบยอมให้ผู้ใช้ทำสิ่งที่บทบาทหรือความเป็นเจ้าของข้อมูลไม่ควรอนุญาต แม้ผู้ใช้จะล็อกอินถูกต้องก็ตาม เช่น เปลี่ยน ID ใน URL แล้วเปิดใบแจ้งหนี้ของคนอื่น หรือเรียก API สำหรับผู้ดูแลโดยตรง การซ่อนปุ่มบนหน้าเว็บไม่ใช่การป้องกัน เพราะผู้โจมตียังส่งคำขอไปยัง Server ได้เอง

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

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

[![A01:2025 Broken Access Control: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-web-broken-access-control-th-v1.webp)](/assets/compliance/owasp-web-broken-access-control-th-v1.webp)

**A01:2025 Broken Access Control**

การซ่อนปุ่มไม่ป้องกันคำขอที่ผู้โจมตีส่งถึงเซิร์ฟเวอร์โดยตรง

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

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

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

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

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

- บังคับใช้การตรวจสิทธิ์กับทุกคำขอฝั่งเซิร์ฟเวอร์
- ปฏิเสธเป็นค่าเริ่มต้นและทดสอบขอบเขตของออบเจ็กต์ ฟังก์ชัน และ Tenant
- บันทึกความล้มเหลวของการควบคุมสิทธิ์และทบทวนเส้นทางสิทธิ์สูง

**ตัวอย่างโค้ดภาษา 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 }
```

A02:2025

## Security Misconfiguration

Security Misconfiguration คือความเสี่ยงที่เกิดจากการตั้งค่าระบบไม่ปลอดภัย ไม่ใช่บั๊กในโค้ดโดยตรง เช่น เปิด Debug ไว้ใน Production, ใช้บัญชีหรือรหัสผ่านเริ่มต้น, เปิด Bucket สาธารณะ หรือให้ CORS กว้างเกินจำเป็น การตั้งค่าหนึ่งจุดอาจทำให้ข้อมูลหรือฟังก์ชันที่ควรอยู่หลังขอบเขตความปลอดภัยถูกเข้าถึงได้

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

| สิ่งที่อาจผิดพลาด | ค่าเริ่มต้นที่ไม่ปลอดภัย ฟีเจอร์ที่ไม่จำเป็น การตั้งค่าคลาวด์ที่เปิดกว้าง หรือการ hardening ที่ขาดหายทำให้ระบบเปิดรับความเสี่ยง |
| --- | --- |
| ผลกระทบต่อธุรกิจ | หน้า debug ข้อความผิดพลาดละเอียด พื้นที่เก็บข้อมูลที่เปิดเผย หรือนโยบายเบราว์เซอร์ที่อ่อนแออาจเปิดเผยข้อมูลหรือสร้างช่องทางเข้าที่ไม่ตั้งใจ |
| จุดควบคุมแรกที่ควรตรวจ | รักษา Baseline การตั้งค่าที่ Hardened และมีเวอร์ชัน |

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

**A02:2025 Security Misconfiguration**

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

- **จุดเริ่มโจมตี** — ผู้โจมตีค้นพบ Storage สาธารณะหรือหน้า Debug ของระบบจริง
- **การควบคุมที่ล้มเหลว** — ค่าเริ่มต้นไม่ปลอดภัยและการ Hardening ของสภาพแวดล้อมขาดหาย
- **ผลกระทบ** — ข้อมูลและช่องทางเข้าที่ไม่ควรเผยแพร่ปรากฏนอกขอบเขตความปลอดภัย
- **การหยุดการโจมตี** — ใช้ Baseline ที่ Hardened มีเวอร์ชัน และตรวจ Cloud Server Browser ต่อเนื่อง

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

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

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

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

- รักษา Baseline การตั้งค่าที่ Hardened และมีเวอร์ชัน
- นำ Service, Account, Header และเนื้อหาตัวอย่างที่ไม่ใช้ออก
- ทบทวนการตั้งค่า Cloud, Server และเบราว์เซอร์อย่างต่อเนื่อง

**ตัวอย่างโค้ดภาษา 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 }
```

A03:2025

## Software Supply Chain Failures

Software Supply Chain Failures คือความเชื่อมั่นในแพ็กเกจ, Dependency, ระบบ Build หรือช่องทางอัปเดตที่ไม่ถูกควบคุมเพียงพอ หากไลบรารีถูกฝังโค้ดอันตราย หรือ Token สำหรับ Release รั่ว ซอฟต์แวร์ที่ส่งถึงลูกค้าอาจถูกแก้ไขได้แม้ทีมพัฒนาไม่ได้เขียนบั๊กนั้นเอง

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

| สิ่งที่อาจผิดพลาด | แพ็กเกจภายนอก ระบบ build ช่องทางอัปเดต และ dependency ไม่ได้รับการกำกับดูแลเพียงพอที่จะรักษาความถูกต้องสมบูรณ์ |
| --- | --- |
| ผลกระทบต่อธุรกิจ | คอมโพเนนต์ที่ถูกโจมตีหรือมีช่องโหว่อาจเข้าสู่ production ได้ แม้โค้ดขององค์กรเองจะถูกต้อง |
| จุดควบคุมแรกที่ควรตรวจ | จัดทำบัญชี Dependency และตรึงเวอร์ชันที่เชื่อถือได้ |

[![A03:2025 Software Supply Chain Failures: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-web-software-supply-chain-failures-th-v1.webp)](/assets/compliance/owasp-web-software-supply-chain-failures-th-v1.webp)

**A03:2025 Software Supply Chain Failures**

ความน่าเชื่อถือของซอฟต์แวร์รวมถึงทุกแพ็กเกจ ระบบ Build และช่องทางอัปเดต

- **จุดเริ่มโจมตี** — แพ็กเกจภายนอกหรือ Token สำหรับ Release ถูกแก้ไขหรือรั่วไหล
- **การควบคุมที่ล้มเหลว** — Build Pipeline ไม่ยืนยันที่มาและความถูกต้องของ Dependency
- **ผลกระทบ** — คอมโพเนนต์อันตรายเข้าสู่ Release แม้โค้ดขององค์กรไม่มีบั๊กโดยตรง
- **การหยุดการโจมตี** — ตรึงเวอร์ชัน ตรวจ Provenance และปกป้องข้อมูลลับของ Build และ Release

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

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

คอมโพเนนต์ที่ถูกโจมตีหรือมีช่องโหว่อาจเข้าสู่ production ได้ แม้โค้ดขององค์กรเองจะถูกต้อง

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

- จัดทำบัญชี Dependency และตรึงเวอร์ชันที่เชื่อถือได้
- ตรวจสอบที่มาและปกป้องข้อมูลลับของ Build และ Release
- ติดตามประกาศช่องโหว่และระบุผู้รับผิดชอบการแก้ไขให้ชัดเจน

**ตัวอย่างโค้ดภาษา 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 }
```

A04:2025

## Cryptographic Failures

Cryptographic Failures คือการปกป้องข้อมูลสำคัญด้วยการเข้ารหัสหรือการจัดการกุญแจที่ไม่เหมาะสม เช่น ส่งข้อมูลผ่านช่องทางที่ไม่ปลอดภัย, ใช้อัลกอริทึมล้าสมัย, เก็บ Key ไว้กับข้อมูล หรือไม่เข้ารหัส Backup ผลคือผู้ที่ดักฟังหรือเข้าถึงสื่อเก็บข้อมูลอาจอ่านข้อมูลส่วนบุคคล รหัสผ่าน หรือข้อมูลธุรกิจได้

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

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

[![A04:2025 Cryptographic Failures: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-web-cryptographic-failures-th-v1.webp)](/assets/compliance/owasp-web-cryptographic-failures-th-v1.webp)

**A04:2025 Cryptographic Failures**

การเข้ารหัสที่ดีต้องครอบคลุมการจำแนกข้อมูล การส่ง การเก็บ และวงจรชีวิตกุญแจ

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

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

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

ข้อมูลส่วนบุคคล 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 }
```

A05:2025

## Injection

Injection เกิดเมื่อแอปพลิเคชันนำข้อมูลที่ผู้ใช้ควบคุมได้ไปต่อเป็นคำสั่งหรือ Query จนระบบปลายทางตีความข้อมูลนั้นเป็นส่วนหนึ่งของภาษา เช่น SQL, Shell, LDAP หรือ Template แทนที่จะเป็นข้อมูลธรรมดา ผู้โจมตีจึงอาจเปลี่ยนความหมายของคำสั่ง อ่านข้อมูลเพิ่ม หรือสั่งงานที่ไม่ได้อยู่ในหน้าจอปกติ

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

| สิ่งที่อาจผิดพลาด | ข้อมูลนำเข้าที่ไม่น่าเชื่อถือถูกตีความเป็นคำสั่ง query template หรือ expression โดยคอมโพเนนต์ปลายทาง |
| --- | --- |
| ผลกระทบต่อธุรกิจ | ผู้โจมตีอาจเปลี่ยน query ฐานข้อมูล คำสั่งแอปพลิเคชัน การค้นหาไดเรกทอรี หรือหน้าเว็บที่ render เกินกว่าคำขอที่ตั้งใจ |
| จุดควบคุมแรกที่ควรตรวจ | ใช้ Interface แบบ Parameterized และ Encoder ตามบริบท |

[![A05:2025 Injection: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-web-injection-th-v1.webp)](/assets/compliance/owasp-web-injection-th-v1.webp)

**A05:2025 Injection**

ข้อมูลจากผู้เรียกต้องเป็นข้อมูล ไม่ใช่ส่วนหนึ่งของภาษาในคำสั่งปลายทาง

- **จุดเริ่มโจมตี** — ผู้โจมตีส่งข้อมูลที่มีคำสั่ง SQL หรือ Shell แฝงในช่องรับข้อมูล
- **การควบคุมที่ล้มเหลว** — แอปต่อข้อความ Input เข้ากับ Query หรือคำสั่งโดยตรง
- **ผลกระทบ** — ความหมายของ Query เปลี่ยนจนอ่านข้อมูลเพิ่มหรือสั่งงานที่ไม่ได้ออกแบบ
- **การหยุดการโจมตี** — ใช้ Parameterized Interface ตรวจ Allow-list และจำกัดสิทธิ์ของแอปพลิเคชัน

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

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

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

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

- ใช้ Interface แบบ Parameterized และ Encoder ตามบริบท
- ใช้การตรวจสอบแบบ Allow-list ที่ขอบเขตความเชื่อถือ
- กำหนดสิทธิ์ของแอปพลิเคชันเท่าที่จำเป็นเท่านั้น

**ตัวอย่างโค้ดภาษา 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 }
```

A06:2025

## Insecure Design

Insecure Design คือช่องว่างที่อยู่ในกติกาของผลิตภัณฑ์หรือ Workflow ตั้งแต่ก่อนเขียนโค้ด ไม่ใช่เพียงเขียนโค้ดผิด ตัวอย่างเช่น ระบบอนุมัติวงเงินโดยไม่มีการแบ่งหน้าที่, ขั้นตอนกู้บัญชีที่ยืนยันตัวตนอ่อนเกินไป หรือไม่มีข้อจำกัดการใช้งานผิดวัตถุประสงค์ โค้ดที่ทำตามข้อกำหนดได้ครบก็ยังอาจไม่ปลอดภัย

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

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

[![A06:2025 Insecure Design: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-web-insecure-design-th-v1.webp)](/assets/compliance/owasp-web-insecure-design-th-v1.webp)

**A06:2025 Insecure Design**

การออกแบบที่ไม่ปลอดภัยเป็นช่องว่างของกติกาธุรกิจก่อนเริ่มเขียนโค้ด

- **จุดเริ่มโจมตี** — ผู้โจมตีใช้ Workflow อนุมัติที่ไม่มีการแบ่งหน้าที่หรือขีดจำกัด
- **การควบคุมที่ล้มเหลว** — ข้อกำหนดผลิตภัณฑ์ไม่มี Abuse Case และเกณฑ์ยอมรับด้านความปลอดภัย
- **ผลกระทบ** — ระบบที่เขียนโค้ดถูกต้องยังเอื้อต่อการทุจริตหรือกู้บัญชีไม่ปลอดภัย
- **การหยุดการโจมตี** — ทำ Threat Modeling กำหนดเกณฑ์เส้นทางสำคัญ และทบทวนการออกแบบโดยอิสระ

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

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

แม้โค้ดจะพัฒนาได้ถูกต้อง ระบบอาจเอื้อต่อการทุจริต ข้ามขีดจำกัดการอนุมัติ หรือกู้คืนบัญชีที่ไม่ปลอดภัยจากการออกแบบ

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

- จำลองกรณีใช้งานผิดวัตถุประสงค์และความล้มเหลวของกฎธุรกิจก่อนพัฒนา
- กำหนดเกณฑ์ยอมรับด้านความปลอดภัยสำหรับเส้นทางสำคัญ
- ใช้ Threat Modeling และการทบทวนการออกแบบโดยอิสระ

**ตัวอย่างโค้ดภาษา 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 }
```

A07:2025

## Authentication Failures

Authentication Failures คือระบบพิสูจน์หรือรักษาตัวตนผู้ใช้ได้ไม่มั่นคง เช่น รับรหัสผ่านที่เดาง่าย, จัดการ Session ไม่ถูกต้อง, ไม่จำกัดการลองเข้าสู่ระบบ หรือให้กู้บัญชีด้วยข้อมูลที่หาได้ง่าย ความผิดพลาดนี้ทำให้ผู้โจมตีสวมรอยเป็นผู้ใช้อื่นและเข้าถึงสิทธิ์ทั้งหมดของบัญชีนั้น

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

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

[![A07:2025 Authentication Failures: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-web-authentication-failures-th-v2.webp)](/assets/compliance/owasp-web-authentication-failures-th-v2.webp)

**A07:2025 Authentication Failures**

ระบบต้องพิสูจน์และรักษาตัวตนที่ถูกต้องตลอดเส้นทางการใช้งาน

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

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

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

ผู้โจมตีอาจยึดบัญชี ใช้ session ซ้ำ หรือใช้ช่องโหว่ของการกู้คืนบัญชีเพื่อกระทำการแทนผู้ใช้อื่น

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

- ใช้ MFA ที่ต้าน Phishing ได้เมื่อความเสี่ยงเหมาะสม
- หมุนเวียน Session หลังเข้าสู่ระบบและหลังเปลี่ยนข้อมูลสำคัญ
- จำกัดอัตรา ติดตาม และออกแบบขั้นตอนกู้คืนบัญชีอย่างปลอดภัย

**ตัวอย่างโค้ดภาษา 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 }
```

A08:2025

## Software or Data Integrity Failures

Software or Data Integrity Failures คือการเชื่อโค้ด, อัปเดต, ข้อมูลภายนอก หรือออบเจ็กต์ที่ Serialize แล้ว โดยไม่ได้พิสูจน์ว่าไม่ถูกแก้ไขระหว่างทาง เช่น รับ Update ที่ไม่ตรวจลายเซ็น หรือรับข้อมูลจาก Webhook โดยไม่ตรวจแหล่งที่มา ผลกระทบอาจเป็นการเปลี่ยนข้อมูลธุรกิจหรือรันโค้ดที่องค์กรไม่ได้อนุมัติ

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

| สิ่งที่อาจผิดพลาด | แอปพลิเคชันเชื่อถือโค้ด อัปเดต Serialized Object หรือข้อมูลจากขอบเขตที่ยังไม่ได้ตรวจสอบความถูกต้องสมบูรณ์ (Integrity) |
| --- | --- |
| ผลกระทบต่อธุรกิจ | ข้อมูลที่ถูกแก้ไขหรืออัปเดตที่ไม่น่าเชื่อถืออาจเปลี่ยนพฤติกรรมแอปพลิเคชัน ข้อมูลธุรกิจ หรือซอฟต์แวร์ที่ส่งมอบให้ผู้ใช้ |
| จุดควบคุมแรกที่ควรตรวจ | ตรวจสอบลายเซ็นและที่มาของโค้ดกับอัปเดต |

[![A08:2025 Software or Data Integrity Failures: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-web-software-or-data-integrity-failures-th-v1.webp)](/assets/compliance/owasp-web-software-or-data-integrity-failures-th-v1.webp)

**A08:2025 Software or Data Integrity Failures**

ข้อมูลหรือโค้ดจากขอบเขตภายนอกต้องพิสูจน์ความถูกต้องก่อนนำไปใช้

- **จุดเริ่มโจมตี** — Update หรือ Webhook ที่ถูกแก้ไขส่งเข้าระบบโดยไม่มีการพิสูจน์ความถูกต้อง
- **การควบคุมที่ล้มเหลว** — แอปเชื่อโค้ด ข้อมูลภายนอก หรือ Serialized Object ที่ไม่ตรวจ Integrity
- **ผลกระทบ** — พฤติกรรมแอป ข้อมูลธุรกิจ หรือซอฟต์แวร์ที่ส่งมอบถูกเปลี่ยนแปลง
- **การหยุดการโจมตี** — ตรวจลายเซ็นและ Provenance ปกป้องการอนุมัติ CI/CD และ Audit Release

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

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

ข้อมูลที่ถูกแก้ไขหรืออัปเดตที่ไม่น่าเชื่อถืออาจเปลี่ยนพฤติกรรมแอปพลิเคชัน ข้อมูลธุรกิจ หรือซอฟต์แวร์ที่ส่งมอบให้ผู้ใช้

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

- ตรวจสอบลายเซ็นและที่มาของโค้ดกับอัปเดต
- ถือว่าข้อมูล Serialized และข้อมูลภายนอกไม่น่าเชื่อถือ
- ปกป้องการอนุมัติ CI/CD และตรวจสอบการเปลี่ยนแปลงของ Release

**ตัวอย่างโค้ดภาษา 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 }
```

A09:2025

## Security Logging and Alerting Failures

Security Logging and Alerting Failures คือเหตุการณ์สำคัญเกิดขึ้นแล้วไม่มีหลักฐานหรือไม่มีใครรับรู้ทันเวลา เช่น ไม่มี Log การเปลี่ยนสิทธิ์, Log ถูกแก้ไขได้, ไม่มีการเชื่อมโยงเหตุการณ์ หรือ Alert ส่งไปยังทีมที่ไม่สามารถตอบสนองได้ ผลคือการบุกรุกอยู่นานขึ้นและทีมย้อนหาว่าเกิดอะไรขึ้นกับข้อมูลใดไม่ได้

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

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

[![A09:2025 Security Logging and Alerting Failures: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, มาตรการลดความเสี่ยง](/assets/compliance/owasp-web-security-logging-and-alerting-failures-th-v2.webp)](/assets/compliance/owasp-web-security-logging-and-alerting-failures-th-v2.webp)

**A09:2025 Security Logging and Alerting Failures**

การตรวจจับที่มีประโยชน์ต้องรวมหลักฐานที่เชื่อถือได้ การแจ้งเตือน และทีมตอบสนอง

- **จุดเริ่มโจมตี** — ผู้โจมตีเรียกคำสั่งสิทธิ์สูงและลองเข้าสู่ระบบผิดซ้ำโดยไม่มีผู้ตอบสนอง
- **การควบคุมที่ล้มเหลว** — เหตุการณ์สำคัญไม่ถูกบันทึก ปกป้อง เชื่อมโยง หรือแจ้งเตือนอย่างใช้งานได้
- **ผลกระทบ** — การบุกรุกยืดเยื้อและทีมไม่สามารถย้อนรอยกิจกรรมหรือข้อมูลที่ได้รับผลกระทบ
- **มาตรการลดความเสี่ยง** — บันทึก Audit Trail ที่ป้องกันการแก้ไข กำหนด Alert และฝึก Incident Response

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

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

การบุกรุกอาจดำเนินต่อได้นานขึ้น เพราะผู้ตรวจสอบไม่สามารถย้อนรอยกิจกรรม หรือทีม Incident Response และผู้ดูแลระบบไม่ได้รับการแจ้งเตือนที่ใช้งานได้จริง

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

- บันทึกเหตุการณ์การยืนยันตัวตน การตรวจสิทธิ์ ผู้ดูแล และธุรกรรมธุรกิจมูลค่าสูง
- ปกป้องความถูกต้องของ Log และกำหนดเกณฑ์แจ้งเตือนที่ใช้ได้จริง
- ฝึกตอบสนองเหตุการณ์ด้วย Telemetry ที่เป็นตัวแทนของระบบจริง

**ตัวอย่างโค้ดภาษา 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 }
```

A10:2025

## Mishandling of Exceptional Conditions

Mishandling of Exceptional Conditions คือระบบจัดการ Error, Timeout, Retry, ภาระงานเกิน หรือสถานะผิดปกติแบบไม่ปลอดภัยหรือไม่สอดคล้องกัน เช่น Timeout แล้วอนุมัติธุรกรรมซ้ำ, Dependency ล่มแล้วข้ามการตรวจสิทธิ์ หรือคืนข้อความภายในให้ผู้ใช้เห็น เส้นทางที่ไม่ใช่ Happy Path จึงกลายเป็นช่องทางที่กระทบข้อมูลหรือธุรกิจได้

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

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

[![A10:2025 Mishandling of Exceptional Conditions: จุดเริ่มโจมตี, การควบคุมที่ล้มเหลว, ผลกระทบ, การหยุดการโจมตี](/assets/compliance/owasp-web-mishandling-exceptional-conditions-th-v1.webp)](/assets/compliance/owasp-web-mishandling-exceptional-conditions-th-v1.webp)

**A10:2025 Mishandling of Exceptional Conditions**

เส้นทางที่ไม่ใช่ Happy Path ต้องปลอดภัยและรักษาสถานะธุรกิจให้สอดคล้องกัน

- **จุดเริ่มโจมตี** — ผู้โจมตีทำให้ธุรกรรมหลายขั้นตอนเกิด Timeout หรือเครือข่ายขาดช่วง
- **การควบคุมที่ล้มเหลว** — ระบบจัดการ Error Retry และการ Rollback ไม่สม่ำเสมอหรือ Fail Open
- **ผลกระทบ** — เกิดธุรกรรมซ้ำ เปิดเผยรายละเอียดภายใน หรือข้ามการตรวจสิทธิ์ในสถานะผิดปกติ
- **การหยุดการโจมตี** — จัดการข้อผิดพลาดแบบรวมศูนย์ Fail Closed และทดสอบ Retry กับการกู้คืนสถานะ

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

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

เส้นทางเมื่อเกิดข้อผิดพลาดอาจเปิดเผยรายละเอียด สร้างธุรกรรมซ้ำ ลดความเข้มของการตรวจสิทธิ์ หรือทำให้ผู้ใช้อยู่ในสถานะที่ทำให้เข้าใจผิด

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

- ล้มเหลวอย่างปลอดภัยด้วยการจัดการข้อผิดพลาดและข้อความผู้ใช้ที่สม่ำเสมอ
- ทำให้การดำเนินการสำคัญ Idempotent และจำกัดด้วย Timeout
- ทดสอบ Dependency ที่เสื่อมสภาพ การ Retry และการกู้คืนสถานะ

**ตัวอย่างโค้ดภาษา 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%

A01:2025 - ตรวจสอบการควบคุมสิทธิ์เข้าถึง (Broken Access Control) บนทุก URL, Resource และ API Endpoint
          
          
            
            A02:2025 - ปิดการตั้งค่าที่ไม่จำเป็นและเปลี่ยนรหัสผ่านเริ่มต้นของระบบทั้งหมด (Security Misconfiguration)
          
          
            
            A03:2025 - ตรวจสอบความเสี่ยงห่วงโซ่อุปทานซอฟต์แวร์และการจัดการ Dependency (Software Supply Chain Failures)
          
          
            
            A04:2025 - บังคับใช้การเข้ารหัสข้อมูลสำคัญและใช้การสื่อสารด้วยโปรโตคอล TLS เวอร์ชันปัจจุบัน (Cryptographic Failures)
          
          
            
            A05:2025 - ตรวจสอบข้อมูลนำเข้าและใช้ Parameterized Query เพื่อป้องกัน Injection (SQL, Command, XSS)
          
          
            
            A06:2025 - ทบทวนสถาปัตยกรรมและการออกแบบความปลอดภัยตั้งแต่ระยะเริ่มแรก (Insecure Design)
          
          
            
            A07:2025 - ตรวจสอบกลไกการยืนยันตัวตนและการจัดการเซสชันให้มั่นคงปลอดภัย (Authentication Failures)
          
          
            
            A08:2025 - ตรวจสอบความถูกต้องของซอฟต์แวร์ อัปเดต และ Serialized Object ก่อนนำไปใช้งาน (Software or Data Integrity Failures)
          
          
            
            A09:2025 - จัดทำระบบบันทึกเหตุการณ์ความปลอดภัย (Logging) และการแจ้งเตือนที่ตอบสนองทันท่วงที (Security Logging and Alerting Failures)
          
          
            
            A10:2025 - ทดสอบการจัดการสภาวะผิดปกติ Exception handling และขีดจำกัดทรัพยากรระบบ (Mishandling of Exceptional Conditions)

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

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

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

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

- [
                มาตรฐานการรักษาความมั่นคงปลอดภัยสำหรับเว็บไซต์ พ.ศ. 2568
                
              ](/th/compliance/ncsa-website-standard/)
- [
                PDPA กำหนดให้ทำ Penetration Testing หรือไม่
                
              ](/th/compliance/pdpa/)
- [
                OWASP API Security Top 10:2023 สรุปช่องโหว่ API
                
              ](/th/compliance/owasp-top-10/api/)
- [
                ISO/IEC 27001:2022 ต้องทำ Penetration Testing ไหม
                
              ](/th/compliance/iso-27001/)

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

[เปิดเอกสาร OWASP ฉบับทางการ ](https://owasp.org/Top10/2025/)

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

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

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

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

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