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

A01:2025

Broken Access Control

Broken Access Control คือระบบยอมให้ผู้ใช้ทำสิ่งที่บทบาทหรือความเป็นเจ้าของข้อมูลไม่ควรอนุญาต แม้ผู้ใช้จะล็อกอินถูกต้องก็ตาม เช่น เปลี่ยน ID ใน URL แล้วเปิดใบแจ้งหนี้ของคนอื่น หรือเรียก 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 }

A02:2025

Security Misconfiguration

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

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

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

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

• รักษา baseline การตั้งค่าที่ hardened และมีเวอร์ชัน
• นำบริการ บัญชี header และเนื้อหาตัวอย่างที่ไม่ใช้ออก
• ทบทวนการตั้งค่าคลาวด์ เซิร์ฟเวอร์ และเบราว์เซอร์อย่างต่อเนื่อง

// ตัวอย่างที่มีช่องโหว่: 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 รั่ว ซอฟต์แวร์ที่ส่งถึงลูกค้าอาจถูกแก้ไขได้แม้ทีมพัฒนาไม่ได้เขียนบั๊กนั้นเอง.

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

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

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

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

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

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

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

// ตัวอย่างที่มีช่องโหว่: 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 ฐานข้อมูล คำสั่งแอปพลิเคชัน การค้นหาไดเรกทอรี หรือหน้าเว็บที่ render เกินกว่าคำขอที่ตั้งใจ

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

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

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

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

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

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

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

// ตัวอย่างที่มีช่องโหว่: 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 ซ้ำ หรือใช้ช่องโหว่ของการกู้คืนบัญชีเพื่อกระทำการแทนผู้ใช้อื่น

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

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

// ตัวอย่างที่มีช่องโหว่: 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 และข้อมูลภายนอกไม่น่าเชื่อถือ
• ปกป้องการอนุมัติ CI/CD และตรวจสอบการเปลี่ยนแปลงของ release

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

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

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

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

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

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

// ตัวอย่างที่มีช่องโหว่: 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 จึงกลายเป็นช่องทางที่กระทบข้อมูลหรือธุรกิจได้.

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

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

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

• ล้มเหลวอย่างปลอดภัยด้วยการจัดการข้อผิดพลาดและข้อความผู้ใช้ที่สม่ำเสมอ
• ทำให้การดำเนินการสำคัญ idempotent และจำกัดด้วย timeout
• ทดสอบ dependency ที่เสื่อมสภาพ การ retry และการกู้คืนสถานะ

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