OWASP Top 10 2025 คืออะไร — 10 ความเสี่ยงเว็บแอปที่ต้องรู้
OWASP Top 10 เป็นเอกสารอ้างอิงที่ใช้กันแพร่หลายที่สุดในการระบุความเสี่ยงด้านความปลอดภัยของเว็บแอปพลิเคชัน ฉบับ 2025 มีการปรับปรุงสำคัญจากฉบับ 2021 รวมถึง 2 หมวดหมู่ใหม่ บทความนี้อธิบายทั้ง 10 ข้อพร้อมตัวอย่างจริงและวิธีป้องกัน
OWASP คืออะไร
OWASP (Open Worldwide Application Security Project) คือมูลนิธิไม่แสวงผลกำไรที่มุ่งเน้นการปรับปรุงความปลอดภัยของซอฟต์แวร์ ก่อตั้งเมื่อปี 2001 OWASP จัดทำเครื่องมือ เอกสาร และมาตรฐานที่เปิดให้ใช้งานฟรี (Open Source) รวมถึง OWASP Top 10 ที่เป็นที่รู้จักมากที่สุด [1]
OWASP Top 10 ไม่ใช่มาตรฐานบังคับ แต่เป็น เอกสารสร้างความตระหนัก (Awareness Document) ที่ Regulator หลายแห่งอ้างอิง รวมถึงมาตรฐานเว็บไซต์ สกมช. 2568 ข้อ 6.2.2 ที่กำหนดให้ใช้ OWASP เป็นกรอบอ้างอิงในการทดสอบความปลอดภัยของเว็บไซต์ [2]
สิ่งที่เปลี่ยนจาก OWASP Top 10:2021 เป็น 2025
OWASP Top 10:2025 มีการเปลี่ยนแปลงสำคัญ [1]:
- หมวดหมู่ใหม่ 2 ข้อ: Software Supply Chain Failures (A03) และ Mishandling of Exceptional Conditions (A10)
- Security Misconfiguration ขยับจากอันดับ 5 ขึ้นเป็นอันดับ 2
- Broken Access Control ยังคงอันดับ 1 แต่ขยายขอบเขตครอบคลุม BOLA/BFLA ของ API
- SSRF (Server-Side Request Forgery) ที่เคยเป็นหมวดหมู่แยกใน 2021 ถูกรวมเข้ากับ A01
A01:2025 — Broken Access Control
อธิบาย
ช่องโหว่ที่ผู้ใช้สามารถเข้าถึงข้อมูลหรือฟังก์ชันที่ไม่ได้รับอนุญาต ยังคงเป็นอันดับ 1 ต่อเนื่องจากปี 2021 ใน OWASP Top 10:2025 ขยายขอบเขตให้ครอบคลุม [1]:
- BOLA (Broken Object Level Authorization) — เข้าถึงข้อมูลของผู้ใช้อื่นผ่าน API
- BFLA (Broken Function Level Authorization) — เรียกใช้ function ระดับ admin โดยผู้ใช้ทั่วไป
- SSRF (Server-Side Request Forgery) — หลอกให้ server ส่ง request ไปยังเป้าหมายภายใน
- Privilege Escalation — ยกระดับสิทธิ์จากผู้ใช้ธรรมดาเป็น admin
ตัวอย่างจริง
ผู้ใช้เปลี่ยน URL จาก /api/orders/123 เป็น /api/orders/456 แล้วเห็นคำสั่งซื้อของผู้ใช้อื่น เพราะ API ไม่ตรวจสอบว่า user ID ตรงกับ order owner หรือไม่
วิธีป้องกัน
- ตรวจสอบสิทธิ์ (Authorization) ทุก request ฝั่ง server — ไม่พึ่ง client-side
- ใช้หลัก Deny by Default — ปิดทุกอย่างก่อน แล้วเปิดเฉพาะที่จำเป็น
- ใช้ RBAC (Role-Based Access Control) หรือ ABAC (Attribute-Based Access Control)
A02:2025 — Security Misconfiguration
อธิบาย
การตั้งค่าที่ไม่ปลอดภัยในทุกระดับของ application stack ตั้งแต่ web server, framework, database, cloud service ไปจนถึง container ขยับจากอันดับ 5 ขึ้นมาอันดับ 2 สะท้อนปัญหา Continuous Deployment ที่ไม่มี Continuous Security Scanning [1]
ตัวอย่างจริง
- เปิด directory listing บน web server ทำให้เห็นไฟล์ configuration
- ใช้ default credentials ของ admin console (เช่น admin/admin)
- เปิด debug mode บน production ทำให้ error message เปิดเผย stack trace
- S3 bucket ตั้งเป็น public โดยไม่ตั้งใจ
วิธีป้องกัน
- ใช้ hardening guide สำหรับทุก component (CIS Benchmarks)
- สแกน configuration อัตโนมัติในทุก deployment (IaC scanning)
- ปิด feature, port, service ที่ไม่จำเป็น
- ใช้ separate configuration สำหรับ development, staging, production
A03:2025 — Software Supply Chain Failures (ใหม่)
อธิบาย
หมวดหมู่ใหม่ที่ครอบคลุมช่องโหว่ใน dependency, CI/CD pipeline และ distribution infrastructure การโจมตี supply chain เป็นแนวโน้มที่เพิ่มขึ้นอย่างชัดเจน — Verizon DBIR 2025 รายงานว่า third-party involvement ในเหตุการณ์รั่วไหลเพิ่มขึ้นเป็นสองเท่า จาก 15% เป็น 30% [3]
ตัวอย่างจริง
- ใช้ npm/pip package ที่ถูก compromise (dependency confusion attack)
- CI/CD pipeline ที่ไม่มีการ verify integrity ของ artifact
- ใช้ Docker image จาก public registry โดยไม่ตรวจสอบ
วิธีป้องกัน
- ใช้ Software Composition Analysis (SCA) สแกน dependency ทุก build
- ลงนาม (sign) และตรวจสอบ (verify) ทุก artifact ใน CI/CD pipeline
- ใช้ lockfile (package-lock.json, poetry.lock) และตรวจสอบ hash
- จำกัด dependency ให้เท่าที่จำเป็นจริง ๆ
A04:2025 — Cryptographic Failures
อธิบาย
ความล้มเหลวในการใช้การเข้ารหัส (Cryptography) เพื่อปกป้องข้อมูลระหว่างการส่ง (in transit) และการจัดเก็บ (at rest) ลดอันดับจาก 2 เป็น 4 แต่ยังคงเป็นปัญหาที่พบบ่อย [1]
ตัวอย่างจริง
- ส่งข้อมูลผ่าน HTTP แทน HTTPS
- ใช้ algorithm ที่ล้าสมัย เช่น MD5, SHA-1 สำหรับ hash password
- เก็บ encryption key ร่วมกับข้อมูลที่เข้ารหัส
- ใช้ TLS 1.0/1.1 ที่มีช่องโหว่
วิธีป้องกัน
- บังคับใช้ HTTPS ทั้งหมด (HSTS)
- ใช้ algorithm ที่แนะนำ: AES-256 สำหรับ encryption, bcrypt/Argon2 สำหรับ password hashing
- จัดการ key แยกจากข้อมูล (ใช้ KMS หรือ HSM)
- ใช้ TLS เวอร์ชันที่ปลอดภัย เป็นขั้นต่ำ, แนะนำ TLS 1.3
A05:2025 — Injection
อธิบาย
ผู้โจมตีส่งข้อมูลที่ถูกตีความเป็นคำสั่งหรือ query โดยไม่ได้ตั้งใจ ครอบคลุม SQL Injection, NoSQL Injection, OS Command Injection, LDAP Injection และ Cross-Site Scripting (XSS) [1]
ตัวอย่างจริง
ผู้โจมตีใส่ ' OR 1=1 -- ในช่อง login แทนรหัสผ่าน ถ้า application นำไปต่อกับ SQL query โดยตรง จะทำให้เข้าสู่ระบบได้โดยไม่ต้องรู้รหัสผ่าน
วิธีป้องกัน
- ใช้ Parameterized Queries / Prepared Statements สำหรับทุก database query
- ใช้ ORM ที่ escape input อัตโนมัติ
- Validate และ sanitize input ทุก field — ทั้ง whitelist (preferred) และ blacklist
- ใช้ Content Security Policy (CSP) สำหรับป้องกัน XSS
A06:2025 — Insecure Design
อธิบาย
ปัญหาที่เกิดจากการออกแบบที่ไม่ปลอดภัยตั้งแต่ต้น ไม่ใช่ bug ในโค้ด แต่เป็นข้อบกพร่องในสถาปัตยกรรมหรือ business logic ที่ไม่สามารถแก้ไขได้ด้วยการ implement ที่ดีเพียงอย่างเดียว [1]
ตัวอย่างจริง
- ระบบ password reset ที่ส่ง OTP 4 หลักโดยไม่มี rate limiting — สามารถ brute force ได้ใน 10,000 ครั้ง
- ระบบ e-commerce ที่ราคาสินค้าถูกกำหนดจาก client-side
วิธีป้องกัน
- ทำ Threat Modeling ตั้งแต่ขั้นตอนออกแบบ
- ใช้ Secure Design Patterns (เช่น fail-safe defaults, complete mediation)
- ทำ Abuse Case Testing ร่วมกับ use case ปกติ
A07:2025 — Authentication Failures
อธิบาย
เดิมชื่อ “Identification and Authentication Failures” ช่องโหว่ในกลไกการยืนยันตัวตน รวมถึง session management ที่อ่อนแอ [1]
ตัวอย่างจริง
- อนุญาตรหัสผ่านง่าย เช่น “password123”
- ไม่มี brute force protection — ผู้โจมตีลองรหัสผ่านได้ไม่จำกัด
- Session token ไม่ถูก invalidate หลัง logout
- MFA ที่ bypass ได้ง่าย
วิธีป้องกัน
- บังคับ password policy ที่เหมาะสม (ความยาวขั้นต่ำ 12 ตัวอักษร)
- ใช้ MFA (Multi-Factor Authentication)
- ใช้ rate limiting และ account lockout
- Invalidate session ทุกจุด — logout, password change, privilege change
A08:2025 — Software or Data Integrity Failures
อธิบาย
ระบบไม่ตรวจสอบ integrity ของซอฟต์แวร์หรือข้อมูลก่อนใช้งาน แตกต่างจาก A03 (Supply Chain) ที่เน้นระดับ supply chain ส่วน A08 เน้นระดับ artifact และ data [1]
ตัวอย่างจริง
- Auto-update ที่ไม่ตรวจสอบ digital signature ก่อนติดตั้ง
- Deserialization ของข้อมูลจาก untrusted source
- CI/CD pipeline ที่ pull image โดยไม่ verify digest/hash
วิธีป้องกัน
- ตรวจสอบ digital signature ของทุก update และ package
- ใช้ Subresource Integrity (SRI) สำหรับ CDN resources
- หลีกเลี่ยง deserialization จาก untrusted source — ใช้ safe format เช่น JSON แทน
A09:2025 — Security Logging and Alerting Failures
อธิบาย
เดิมชื่อ “Security Logging and Monitoring Failures” เปลี่ยนเพื่อเน้นว่าการ log อย่างเดียวไม่เพียงพอ ต้องมี alerting ที่ทำให้เกิดการตอบสนองด้วย [1]
IBM Cost of a Data Breach Report 2025 ระบุว่าระยะเวลาเฉลี่ยในการตรวจจับเหตุการณ์อยู่ที่ 241 วัน [4] — การมี logging และ alerting ที่มีประสิทธิภาพช่วยลดระยะเวลานี้ได้อย่างมาก
ตัวอย่างจริง
- ไม่ log การ login ที่ล้มเหลว — ไม่สามารถตรวจจับ brute force
- Log ครบแต่ไม่มีใครดู (ไม่มี SIEM หรือ alerting)
- Log เก็บข้อมูลส่วนบุคคลเกินจำเป็น (ผิด PDPA)
วิธีป้องกัน
- Log authentication events, access control failures, input validation failures
- ส่ง log ไปยัง centralized SIEM พร้อมตั้ง alert สำหรับ event สำคัญ
- ทดสอบว่า alerting ทำงานจริง — อย่าเพียงตั้งแล้วลืม
- ระวังไม่ log ข้อมูลส่วนบุคคล (PII) เกินจำเป็น
A10:2025 — Mishandling of Exceptional Conditions (ใหม่)
อธิบาย
หมวดหมู่ใหม่ที่ครอบคลุม 24 CWE เกี่ยวกับการจัดการ error และ exceptional conditions ที่ไม่เหมาะสม เช่น improper error handling, logical errors และ fail-open scenarios [1]
ตัวอย่างจริง
- ระบบ authentication ที่ “fail open” เมื่อ backend ล่ม — อนุญาตเข้าใช้งานทุกคน
- Error message ที่เปิดเผย stack trace, database name หรือ internal IP
- Exception ที่ไม่ถูก catch ทำให้ application crash และเปิดเผยข้อมูล
วิธีป้องกัน
- ใช้หลัก Fail-Secure — เมื่อเกิดข้อผิดพลาดให้ปฏิเสธการเข้าถึง (deny) ไม่ใช่อนุญาต
- จัดการ exception ทุกจุด — แสดง error message ทั่วไปแก่ผู้ใช้ แต่ log รายละเอียดไว้ภายใน
- ทดสอบ edge cases และ error paths ด้วย negative testing
มาตรฐานเว็บไซต์ สกมช. 2568 กับ OWASP
ประกาศมาตรฐานการรักษาความมั่นคงปลอดภัยสำหรับเว็บไซต์ พ.ศ. 2568 ข้อ 6.2.2 กำหนดให้อ้างอิง OWASP เป็นกรอบในการทดสอบความปลอดภัยของเว็บแอปพลิเคชัน [2] — หมายความว่าหน่วยงานที่อยู่ภายใต้มาตรฐานนี้ต้องทดสอบช่องโหว่ตาม OWASP Top 10 เป็นขั้นต่ำ
อ่านรายละเอียดมาตรฐานเว็บไซต์ สกมช. 2568 ที่ สรุปมาตรฐานเว็บไซต์
ขั้นตอนถัดไป
- ตรวจสอบว่าเว็บแอปพลิเคชันขององค์กรได้รับการทดสอบตาม OWASP Top 10 ฉบับล่าสุดหรือยัง
- พิจารณาใช้บริการ Web Application Pentest ที่ครอบคลุม OWASP Top 10 2025
- อ่าน Pentest คืออะไร สำหรับภาพรวมการทดสอบเจาะระบบ
- เตรียมตัวด้วย Checklist 15 ข้อก่อนจ้าง Pentest
แหล่งอ้างอิง
- OWASP, OWASP Top 10:2025 Introduction — top10.owasp.org
- ประกาศ กมช. เรื่องมาตรฐานการรักษาความมั่นคงปลอดภัยสำหรับเว็บไซต์ พ.ศ. 2568 ข้อ 6.2.2 — ncsa.or.th
- Verizon, 2025 Data Breach Investigations Report — verizon.com/dbir
- IBM Security, Cost of a Data Breach Report 2025 — ibm.com