สรุปเน้น ๆ OWASP Top 10:2025 — อัปเดตครั้งนี้ มีช่องโหว่ไหนที่ทีม Dev และ Security ควรรู้
ถ้าถามว่ามาตรฐานไหนที่คนทำเว็บทั่วโลกใช้เป็น "คัมภีร์" ในการตรวจสอบความปลอดภัย ชื่อแรกที่ทุกคนนึกถึงคงหนีไม่พ้น OWASP Top 10 เพราะมันคือการรวบรวม 10 อันดับช่องโหว่ที่เจอบ่อยที่สุดในชีวิตจริงมาสรุปไว้
ล่าสุดในปีปลายปี 2025 ที่ผ่านมานี้ OWASP ได้ปล่อย OWASP Top 10:2025 ออกมา โดยมีการจัดอันดับใหม่จากข้อมูลจริงและ Feedback จาก Community ด้าน Application Security ทั่วโลก จุดที่น่าสนใจคือหลายหัวข้อยังคงอยู่จากปี 2021 แต่บางหัวข้อถูกขยายความหมายให้กว้างขึ้น บางหัวข้อถูกยุบรวม และมีหัวข้อใหม่ที่สะท้อนโลกของ Software Development ในปัจจุบันมากขึ้น โดยเฉพาะเรื่อง Software Supply Chain, Configuration, และ Error Handling
วันนี้ทาง Reconix เลยสรุปมาให้แบบเน้นๆ ทั้ง 10 ข้อ ว่ามีอะไรเปลี่ยนไปบ้าง และเราจะป้องกันระบบของเรายังไงให้ปลอดภัย
A01:2025 Broken Access Control – ปัญหาอมตะ "คุมสิทธิ์ไม่อยู่"
ข้อนี้ยังครองแชมป์อันดับ 1 เหมือนเดิม เพราะเรื่องการเช็กสิทธิ์ (Access Control) เป็นอะไรที่พลาดง่ายที่สุดแล้ว ไม่ว่าจะเป็นการปล่อยให้ User เข้าไปดูข้อมูลของ User อื่น หรือการที่ User ธรรมดาดันไปเรียกใช้ฟังก์ชันของ Admin ได้
ที่พิเศษคือปีนี้ทาง OWASP ได้เอา A10:2021 – Server-Side Request Forgery (SSRF) (ช่องโหว่ที่หลอกให้ Server ส่ง Request ไปยังเป้าหมายที่ผู้โจมตีต้องการ เช่น Internal-Only Services) มารวมไว้ในกลุ่มนี้ด้วย เพราะมองว่ามันคือการที่ระบบคุมสิทธิ์การเข้าถึงทรัพยากรภายในได้ไม่ดีพอนั่นเอง
ตัวอย่างเคสที่เจอในชีวิตจริง:
- แก้เลข ID ใน URL โดยตรง เช่น จาก
account/101เป็นaccount/102แล้วดันเห็นข้อมูลของ User อื่นที่เราไม่ควรจะเห็น (IDOR) - หน้าบ้าน (Frontend) ซ่อนปุ่ม Admin ไว้ แต่หลังบ้าน (Backend) ดันลืมเช็กสิทธิ์ ทำให้ใครก็ตามที่ยิง API มาก็ทำให้หมด
วิธีป้องกัน: ระบบต้องเช็กสิทธิ์ทุกครั้งที่รับ Request มา และต้องเช็กในฝั่งเซิร์ฟเวอร์เท่านั้น นอกจากนี้ในการกำหนดสิทธิ์ให้ใช้หลักการ "ให้สิทธิ์เท่าที่จำเป็น" (Least Privilege) จะปลอดภัยที่สุดครับ
A02:2025 Security Misconfiguration – ตกม้าตายเพราะ "ตั้งค่าพลาด"
ข้อนี้ขยับขึ้นมาเป็นอันดับ 2 แบบก้าวกระโดด เพราะเดี๋ยวนี้เราใช้ทั้ง Cloud, Docker, Kubernetes ฯลฯ แถมมี Config เต็มไปหมด พลาดนิดเดียวก็เปรียบเสมือนเปิดประตูบ้านทิ้งไว้เลย ข้อนี้ไม่ได้เกิดจากการเขียนโค้ดอย่างเดียว แต่เกี่ยวกับ "Environment" ที่เราใช้รันโค้ดด้วย
ตัวอย่างเคสที่เจอในชีวิตจริง:
- ลืมปิด Debug Mode บน Production จนแฮกเกอร์เห็น Error แบบละเอียด ไปจนถึงโครงสร้างโค้ด หรือโครงสร้าง Database
- ใช้ Default Password ที่ติดมากับระบบ (Admin/Admin) แล้วไม่ยอมเปลี่ยน
- เปิดพวก S3 Bucket (Cloud Storage ของ AWS) หรือ Storage เป็น Public จนข้อมูลรั่วไหลออกไปข้างนอก
- ไม่ได้ตั้งค่าให้เซิร์ฟเวอร์ส่ง Security Headers หรือตั้งค่าไว้แล้วแต่ Config ค่าไม่ปลอดภัย
วิธีป้องกัน: ทำลิสต์มาตรฐานการตั้งค่า (Hardening Guide) ไว้เสมอ และใช้เครื่องมือพวก Automated Scan คอยตรวจว่ามีจุดไหนที่ลืมปิดหรือตั้งค่าทิ้งไว้หรือเปล่า
ความยากของข้อนี้คือ Misconfiguration มักไม่ได้ดูอันตรายตอนแรก แต่เมื่อระบบใหญ่ขึ้นและมีหลาย Environment โอกาสพลาดก็สูงมากขึ้น ทางทีมจึงควรมี Baseline Configuration, Automated Scan และ Review Setting สำคัญก่อนขึ้น Production เสมอ
A03:2025 Software Supply Chain Failures – ภัยเงียบที่มากับการสร้างซอฟต์แวร์
ข้อนี้ถูกเปลี่ยนชื่อและขยายขอบเขตจาก A06:2021 Vulnerable and Outdated Components ให้กว้างขึ้น จากเดิมที่เน้นแค่ Library หรือ Component ที่มีช่องโหว่ แต่ปีนี้ได้มองต่อจากเดิมไปถึงทุกอย่างที่อยู่ใน Supply Chain ทั้งหมด ตั้งแต่ Dependencies ที่เราดึงมาใช้ ระบบ CI/CD ที่ไม่ปลอดภัย ไปจนถึงเครื่องมือพัฒนาที่ใช้ Build และ Deploy ดังนั้น ทุกส่วนใน Supply Chain มีผลต่อความปลอดภัยของระบบทั้งสิ้น
ตัวอย่างเคสที่เจอในชีวิตจริง:
- ผู้พัฒนาอาจไปลง Library ปลอมที่ชื่อคล้ายของจริง (Typosquatting) แล้วในนั้นมีมัลแวร์แฝงอยู่
- ระบบ Build (CI/CD) โดนเจาะ ทำให้โค้ดที่ส่งออกไปหาลูกค้าถูกแอบแก้ระหว่างทาง
วิธีป้องกัน: ตรวจสอบ Library ที่ใช้เสมอว่าต้องมาจากแหล่งที่เชื่อถือ ใช้เครื่องมือ Scan Dependency และควรมี Software Bill of Materials (SBOM) เพื่อให้รู้ว่าในซอฟต์แวร์เรามีส่วนประกอบอะไรบ้างและมีอะไรซ่อนอยู่หรือไม่
A04:2025 Cryptographic Failures – ข้อมูลหลุดเพราะการเข้ารหัสไม่แกร่งพอ
ข้อนี้แม้ว่าอันดับลดลงมาจาก A02:2021 มาเป็น A04:2025 แต่เรื่องการเก็บความลับหรือปกป้องข้อมูลยังคงสำคัญเหมือนเดิม ปัญหาส่วนใหญ่คือการเลือกใช้ Encryption หรือ Hashing ไม่ถูกต้อง ใช้ Algorithm ที่ไม่ปลอดภัย จัดการ Key ได้ไม่ดีพอ หรือส่งข้อมูลสำคัญผ่านการเชื่อมต่อที่ไม่ปลอดภัย
ตัวอย่างเคสที่เจอในชีวิตจริง:
- ระบบเก็บ Password ด้วย MD5 หรือ SHA-1
- รับส่งข้อมูลสำคัญผ่าน HTTP ธรรมดา (ไม่ใช้ HTTPS) ทำให้โดนดักอ่านข้อมูลกลางทางได้ง่ายๆ
- เขียน Key สำหรับเข้ารหัสไว้ในโค้ด (Hardcoded)
วิธีป้องกัน: เลือกใช้อัลกอริทึมที่ได้มาตรฐานปัจจุบัน (เช่น เก็บรหัสผ่านด้วย Argon2 หรือ SHA-512) และการส่งข้อมูลสำคัญควรส่งผ่าน Secure Protocol (เช่น TLS Ver.>=1.2) เท่านั้น และที่สำคัญคือระบบจัดการ Key ที่ปลอดภัย
A05:2025 Injection – ท่ามาตรฐานที่ยังคงใช้ได้ผล
Injection มีอันดับลดจาก A03:2021 มาเป็น A05:2025 แต่ยังเป็นช่องโหว่คลาสสิกที่อันตรายมากเช่นเคย เพราะถ้าพลาดอาจถูกดึงข้อมูลหรือควบคุมระบบได้เลยทีเดียว โดยช่องโหว่นี้เกิดจากการนำ Input ที่ไม่น่าเชื่อถือไปใช้เป็นคำสั่งโดยตรงโดยไม่ตรวจสอบให้ดีก่อน เช่น SQL, NoSQL, OS Command, LDAP, ORM หรือ Expression Language
แม้ว่าการใช้ Framework จะช่วยลดความเสี่ยงนี้ลง แต่อาจยังมีช่องโหว่ Injection อยู่ โดยเฉพาะในระบบที่มี Dynamic Query, Custom Filter หรือจุดที่มีการต่อคำสั่งด้วย String จาก User Input โดยไม่ได้ถูก Validate, Filter หรือ Sanitize ให้ดีก่อน
ตัวอย่างเคสที่เจอในชีวิตจริง:
- เอาชื่อ User มาต่อใน SQL Query โดยตรง ทำให้แฮกเกอร์ควบคุมคำสั่ง Query ได้ เช่น พิมพ์คำสั่ง
' OR 1=1--เข้ามา Bypass หน้า Login - การรับ Input ไปรันคำสั่งในระบบ (Command Injection) ทำให้เครื่องเซิร์ฟเวอร์โดนยึด
วิธีป้องกัน: ให้พยายามแยกข้อมูลออกจากคำสั่ง เช่น ใช้ Parameterized Queries / Prepared Statements เพื่อให้ User Input ถูกมองว่าเป็นข้อมูลหนึ่ง ไม่ใช่ส่วนหนึ่งของคำสั่ง และอย่าลืม Validate ข้อมูลที่รับเข้ามาเสมอ
A06:2025 Insecure Design – พังตั้งแต่ออกแบบ (เขียนโค้ดยังไงก็ไม่รอด)
ข้อนี้มีอันดับขยับจาก A04:2021 มาเป็น A06:2025 เป็นช่องโหว่ที่ต่างจากข้ออื่นตรงที่ ช่องโหว่นี้เกิดมาจากการออกแบบระบบที่ไม่ดีมาตั้งแต่แรก ต่อให้เขียนโค้ดดีแค่ไหน แต่ถ้า Logic ของระบบมันผิด ระบบก็ยังคงมีช่องโหว่อยู่
ตัวอย่างเคสที่เจอในชีวิตจริง:
- ระบบโอนเงินของธนาคารไม่ได้ป้องกัน Race Condition ไว้ ทำให้ระบบจัดการ Transaction ได้ไม่ดีพอ เช่น User ที่มีเงินอยู่ในบัญชี 1,000 บาท สามารถส่งคำขอโอนเงิน 1,000 บาทพร้อม ๆ กัน 10 ครั้งในเสี้ยววินาที ทำให้ระบบสับสนและอ่านยอดเงินคงเหลือว่ามีเพียงพอสำหรับทุก Transaction ทำให้สามารถดึงเงินออกไปได้ถึง 10,000 บาท ทั้ง ๆ ที่มีเงินในบัญชีต้นทางแค่ 1,000 บาท
- ระบบกู้คืนรหัสผ่าน (Reset Password) ที่ตั้งคำถามง่ายเกินไป หรือเป็นคำถามทั่ว ๆ ไปเดาหรือหาคำตอบได้ง่าย
- ระบบซื้อของออนไลน์ไม่ได้ออกแบบระบบป้องกัน BOT เป็นช่องทางให้กลุ่มพ่อค้าคนกลางกว้านซื้อสินค้าทั้งหมด แล้วนำไปประมูลหรือขายต่อในราคาที่สูง จึงเป็นตัวทำกำไรชั้นดี แต่ก็สร้างความไม่พอใจให้กับผู้บริโภคที่ต้องการซื้อสินค้าจริง ๆ ได้มาเลยทีเดียว
วิธีป้องกัน: ต้องทำ Threat Modeling หรือวางแผนเรื่อง Security ตั้งแต่ตอนเริ่มออกแบบระบบ เช่น วิเคราะห์ภัยคุกคามที่น่าจะเกิดขึ้น หรือกรณีไหนที่ระบบอาจถูกใช้ในทางที่ผิดได้ และต้องป้องกันอย่างไร
A07:2025 Authentication Failures – หน้าด่านยืนยันตัวตนที่ไม่แข็งแรง
ข้อนี้ถูกปรับชื่อมาจาก Identification and Authentication Failures ให้กระชับขึ้น โดยเกี่ยวข้องกับการยืนยันตัวตนที่ไม่ปลอดภัย ทำให้แฮกเกอร์เข้าถึงทุกอย่างได้ง่าย ซึ่งครอบคลุมตั้งแต่การตั้ง Password การ Login โดยใช้ MFA ไปจนถึงการจัดการ Session ที่ไม่ดีพอ
ตัวอย่างเคสที่เจอในชีวิตจริง:
- ระบบยอมให้ User ตั้ง Password ง่ายเกินไป หรือระบบ Login ไม่มีระบบป้องกันการสุ่มรหัสผ่าน (Brute Force)
- ไม่ได้ทำระบบ Multi-Factor Authentication (MFA) ทำให้พอ Password หลุด User นั้นก็จะถูกยึดในทันที
- Session ไม่หมดอายุ (Timeout) ทำให้คนอื่นมาสวมรอยใช้ต่อได้
- ระบบไม่ได้เปลี่ยน Session ID หลังจากที่ผู้ใช้เข้าสู่ระบบสำเร็จ (Session Fixation)
วิธีป้องกัน: เช่น กำหนด Password Policy ให้รัดกุม, ไม่ใช้ Default Password ของระบบ, ถ้าเป็นไปได้ควรบังคับใช้ MFA เสมอ, จัดการ Session ให้หมดอายุตามเวลาที่เหมาะสม, สร้าง Session ID ใหม่ทุกครั้งหลังเข้าสู่ระบบสำเร็จ เป็นต้น
A08:2025 Software or Data Integrity Failures – เชื่อใจกันมากเกินไปจนโดนโจมตี
ข้อนี้ถูกแก้ชื่อเล็กน้อยจาก Software and Data Integrity Failures เพื่อให้ความหมายชัดขึ้น มันคือการที่ระบบเชื่อถือ Software, Data หรือ Serialized Object โดยไม่มีการตรวจสอบความถูกต้องหรือยืนยันแหล่งที่มาก่อนนำมาใช้งาน
ตัวอย่างเคสที่เจอในชีวิตจริง:
- ระบบ Auto-update ที่ไปโหลดไฟล์มาลงเครื่องเอง โดยไม่ตรวจสอบว่าไฟล์นั้นถูกแอบแก้มาหรือไม่ (ไม่ได้ตรวจสอบ Signature หรือ Checksum ของไฟล์)
- Application รับ Serialized Object จาก Client แล้ว Deserialize ตรง ๆ ซึ่งอาจนำไปสู่ Remote Code Execution ได้ เพราะ Serialized Object ที่รับมา อาจถูกแฮกเกอร์แอบแก้เพื่อให้เครื่องเรารันโค้ดอันตราย (Insecure Deserialization)
วิธีป้องกัน: ควรตรวจสอบ Digital Signature หรือ Checksum ทุกครั้งที่รับไฟล์สำคัญ เพื่อยืนยันว่าข้อมูลไม่ถูกแก้ไขระหว่างทาง และหลีกเลี่ยงการรับข้อมูลที่ซับซ้อนมาประมวลผลตรง ๆ โดยไม่ Verify ก่อน
A09:2025 Security Logging and Alerting Failures – โดนเจาะแล้วแต่ไม่มีใครรู้ตัว
ข้อนี้ถูกเปลี่ยนชื่อจาก Security Logging and Monitoring Failures เพื่อเน้นว่าแค่มี Log ในระบบยังไม่พอ ต้องมี Alert ที่ทำให้ทีมรับรู้และ Response กับ Incident ที่เกิดขึ้นจริงได้ เพราะในข้อนี้ปัญหาไม่ได้อยู่ที่การโดนแฮก แต่อยู่ที่ "โดนแฮกมานานแล้วแต่เราไม่รู้" เพราะระบบไม่มี Log ที่ดีพอ หรือมี Log ที่ดีแล้ว แต่ไม่มีระบบแจ้งเตือน (Alert) เวลามีอะไรผิดปกติเกิดขึ้น ดังนั้น Log และ Alert จะต้องมาคู่กัน
ตัวอย่างเคสที่เจอในชีวิตจริง:
- มีคนพยายาม Login พลาดเป็นพันครั้งในหนึ่งนาที แต่ระบบนิ่งเฉย ไม่มีการแจ้งเตือน Admin
- เมื่อมี Incident เกิดขึ้นจริง แต่ Log ที่เก็บมาไม่มีข้อมูลอะไรที่เป็นประโยชน์เลย เพราะไม่ได้เก็บข้อมูลสำคัญไว้
วิธีป้องกัน: ควรเก็บ Log เหตุการณ์สำคัญไว้ด้วย (เช่น Login ผิดพลาด, การเปลี่ยนสิทธิ์) และตั้ง Alert ให้ทีมงานรู้ทันทีเมื่อมีพฤติกรรมน่าสงสัย
A10:2025 Mishandling of Exceptional Conditions – จัดการ Error ไม่ดี จนข้อมูลหลุด
เป็นหัวข้อใหม่ใน OWASP Top 10:2025 มันคือการที่เวลาระบบเกิด Error, Exception หรือเจอกรณีที่ผิดปกติ แล้วระบบจัดการไม่ดีพอ จนทำให้ระบบใช้งานไม่ได้ หรือแสดง Error ที่มีข้อมูลสำคัญออกมาสู่ภายนอก
ตัวอย่างเคสที่เจอในชีวิตจริง:
- กรณีที่เว็บนี้ Database ใช้งานไม่ได้ หน้าเว็บนี้จึงแสดงหน้า Stack Trace ที่บอก Path ภายใน Server, ข้อมูลและโครงสร้าง Database ที่ใช้ (Internal-Information Leakage)
- ระบบ Error ตอนกำลังทำ Transaction แล้วไม่ได้สั่ง Rollback ทำให้ข้อมูลในระบบผิดเพี้ยนไป
วิธีป้องกัน: ควรเขียน Error Exception ในทุกจุดที่สามารถเกิด Error ได้ และจัดการ Error นั้นให้เหมาะสม หรือออกแบบ Error Handling ให้เป็นแบบ Fail-safe อย่าแสดงรายละเอียดหลังบ้านให้ User ทั่วไปเห็น และตรวจสอบสถานะระบบให้เรียบร้อยทุกครั้งที่เกิด Error
หมายเหตุ: สำหรับใครที่อยากจะศึกษาวิธีป้องกันช่องโหว่ สามารถเข้าไปศึกษาเพิ่มเติมได้จาก OWASP Cheat Sheet Series
สรุป: ต้องปรับตัวยังไงบ้าง
จะเห็นว่า OWASP Top 10:2025 เน้นไปที่ภาพรวมของระบบมากขึ้น ไม่ใช่แค่เรื่องการเขียนโค้ด (Coding) อย่างเดียว แต่รวมไปถึงการออกแบบ (Design), การตั้งค่า (Configuration) และความปลอดภัยของ Components ต่าง ๆ ที่เราหยิบมาใช้ในการพัฒนาซอฟต์แวร์ (Supply Chain)
ตารางเปรียบเทียบ OWASP Top 10 ปี 2021 vs 2025
| 2021 | 2025 | จุดที่เปลี่ยนไป |
|---|---|---|
| A01: Broken Access Control | A01: Broken Access Control | ยังคงเป็นอันดับ 1 และมีการควบรวมหัวข้อ SSRF เข้ามา |
| A02: Cryptographic Failures | A04: Cryptographic Failures | อันดับลดลง แต่ยังเป็นพื้นฐานสำคัญในการปกป้องข้อมูล |
| A03: Injection | A05: Injection | อันดับลดลงเนื่องจาก Framework มีระบบป้องกันที่ดีขึ้น |
| A04: Insecure Design | A06: Insecure Design | ยังติดอันดับท็อป เน้นย้ำความสำคัญของ Security ตั้งแต่ขั้นตอนการออกแบบ |
| A05: Security Misconfiguration | A02: Security Misconfiguration | ขยับขึ้นเป็นอันดับ 2 สะท้อนความเสี่ยงจากการตั้งค่าระบบ Cloud และ Container |
| A06: Outdated Components | A03: Supply Chain Failures | ขยายขอบเขตครอบคลุมความปลอดภัยของวงจรการผลิตซอฟต์แวร์ทั้งหมด (Supply Chain) |
| A07: Authentication Failures | A07; Authentication Failures | อันดับคงเดิม เน้นการใช้ MFA และการจัดการ Session ที่รัดกุม |
| A08: Integrity Failures | A08: Integrity Failures | เน้นการตรวจสอบความถูกต้องของซอฟต์แวร์และข้อมูลจากภายนอก |
| A09: Logging and Monitoring | A09: Logging and Alerting | ปรับชื่อเพื่อเน้นย้ำความสำคัญของระบบการแจ้งเตือน (Alerting) |
| A10: SSRF | (ย้ายไปรวมใน A01) | ถูกยุบไปรวมกับหมวด A01 Broken Access Control |
| n/a | A10: Mishandling Exceptions | หัวข้อใหม่ เน้นความปลอดภัยในการจัดการ Error และสถานะผิดปกติของระบบ |
การทำระบบให้ปลอดภัยไม่ใช่เรื่องที่ทำเสร็จได้ในวันเดียว แต่มันคือการตรวจสอบและพัฒนาอย่างต่อเนื่อง หากคุณหรือองค์กรกำลังกังวลเรื่องความปลอดภัยของระบบ และต้องการปรึกษาผู้เชี่ยวชาญมาช่วยทำ Security Audit หรือ Penetration Testing (ทดสอบเจาะระบบ) ทีม Reconix พร้อมดูแลและให้คำปรึกษาเพื่อให้ธุรกิจของคุณเดินหน้าต่อไปได้อย่างปลอดภัยครับ
ข้อมูลอ้างอิง:
- OWASP Top 10:2025
- OWASP Top 10:2025 Introduction
- OWASP Top 10:2021
- A01:2025 Broken Access Control
- A02:2025 Security Misconfiguration
- A03:2025 Software Supply Chain Failures
- A04:2025 Cryptographic Failures
- A05:2025 Injection
- A06:2025 Insecure Design
- A07:2025 Authentication Failures
- A08:2025 Software or Data Integrity Failures
- A09:2025 Security Logging and Alerting Failures
- A10:2025 Mishandling of Exceptional Conditions
