OWASP Top 10 สำหรับเว็บแอป: สรุปสำหรับผู้บริหารและทีมพัฒนา

OWASP Top 10 คือรายการหมวดความเสี่ยงด้านความปลอดภัยของเว็บแอปพลิเคชัน 10 หมวด (เว็บแอปพลิเคชันคือโปรแกรมที่ใช้งานผ่านเบราว์เซอร์) จัดทำโดย OWASP ซึ่งเป็นชุมชนที่ทำงานด้านความปลอดภัยของแอปพลิเคชัน หน้าทางการเรียกรายการนี้ว่าเอกสารสร้างความตระหนักรู้ (awareness) สำหรับนักพัฒนา ฉบับล่าสุดคือ OWASP Top 10:2025 บทความนี้สรุปทั้ง 10 หมวด สิ่งที่เปลี่ยนจากฉบับ 2021 และสิ่งที่ผู้บริหารกับทีมพัฒนาควรทำต่อ

OWASP Top 10 คืออะไร และไม่ใช่อะไร

OWASP Top 10 เป็นรายการหมวดความเสี่ยงที่พบบ่อย ไม่ใช่รายการตรวจที่ทำครบแล้วถือว่าแอปปลอดภัย หน้าทางการของ OWASP ระบุว่า Top 10 เป็นเพียงเกณฑ์ขั้นต่ำ ถ้าต้องการกำหนดข้อกำหนดด้านความปลอดภัยของแอป ให้ใช้ ASVS (Application Security Verification Standard คือมาตรฐานของ OWASP ที่รวมข้อกำหนดซึ่งตรวจสอบและทดสอบได้)

ฉบับ 2025 ใช้ข้อมูลจากแอปมากกว่า 2.8 ล้านตัว ทีมงานวิเคราะห์ CWE (Common Weakness Enumeration คือรายการมาตรฐานที่แยกประเภทจุดอ่อนของซอฟต์แวร์) ทั้งหมด 589 รายการ และ 10 หมวดครอบคลุม 248 รายการ สองในสิบหมวดถูกเลือกจากผลสำรวจความเห็นของชุมชน เพื่อครอบคลุมความเสี่ยงที่ข้อมูลจากการทดสอบอาจสะท้อนไม่ครบ ได้แก่ A03 ว่าด้วยห่วงโซ่อุปทานซอฟต์แวร์ (supply chain คือโค้ด เครื่องมือ และส่วนประกอบของผู้อื่นที่ซอฟต์แวร์ของเราพึ่งพา) และ A09 ว่าด้วยการบันทึกและแจ้งเตือนเหตุการณ์

ทั้ง 10 ข้อในฉบับ 2025

รายการตามหน้าทางการของ OWASP มีดังนี้:

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

อะไรเปลี่ยนจากฉบับ 2021

ตามหน้าแนะนำของ OWASP การเปลี่ยนแปลงหลักมีดังนี้:

• SSRF ถูกรวมเข้า A01: SSRF (Server-Side Request Forgery คือการหลอกให้เซิร์ฟเวอร์ไปเรียกที่อยู่ที่ผู้โจมตีกำหนด) อยู่ใน Broken Access Control ซึ่งยังเป็นอันดับ 1
• A03 ขยายขอบเขต: Software Supply Chain Failures ขยายมาจากหมวด A06:2021 Vulnerable and Outdated Components (ส่วนประกอบที่มีช่องโหว่และล้าสมัย) ให้ครอบคลุมการโจมตีผ่าน dependency (ไลบรารีที่แอปเรียกใช้) ระบบ build (ระบบที่ประกอบโค้ดเป็นซอฟต์แวร์) และช่องทางแจกจ่ายซอฟต์แวร์
• A10 เป็นหมวดใหม่: Mishandling of Exceptional Conditions มี 24 CWE ครอบคลุมการจัดการข้อผิดพลาดที่ผิด ข้อผิดพลาดทางตรรกะ และการปล่อยผ่านเมื่อระบบล้มเหลว (failing open)
• อันดับเปลี่ยน: A02 Security Misconfiguration ขึ้นจากอันดับ 5 เป็นอันดับ 2 ส่วน A04, A05 และ A06 ลดลงหมวดละสองอันดับ จากอันดับ 2, 3 และ 4 เป็นอันดับ 4, 5 และ 6
• เปลี่ยนชื่อ: A07 เปลี่ยนชื่อเป็น Authentication Failures และ A09 เปลี่ยนชื่อเป็น Security Logging and Alerting Failures เพื่อเน้นเรื่องการแจ้งเตือน

เครื่องมือสแกนบางตัวยังอ้างอิงฉบับ 2021 ตัวอย่างคือเครื่องสแกนเว็บฟรีของ DynaSec ที่ webscan.dynasec.pro ซึ่งจับคู่ผลสแกนกับ OWASP Top 10 (2021) หมวดส่วนใหญ่เทียบกันได้ แต่หมวดที่ชื่อหรือขอบเขตเปลี่ยน เช่น SSRF ต้องจับคู่ด้วยมือ ไม่ว่าจะอ่านรายงานใด ให้ดูก่อนว่ารายงานนั้นอ้างฉบับไหน

สามข้อที่ควรเข้าใจเป็นพิเศษ

A01 Broken Access Control ยังเป็นอันดับ 1 หน้าทางการรายงานว่าแอปที่ทดสอบ 100% พบปัญหาในหมวดนี้อย่างใดอย่างหนึ่ง และเป็นหมวดที่พบจำนวนครั้งมากที่สุดในข้อมูลที่ได้รับ OWASP แนะนำหลักป้องกัน เช่น ปฏิเสธการเข้าถึงโดยค่าเริ่มต้น ยกเว้นทรัพยากรสาธารณะ ตรวจสิทธิ์ในโค้ดฝั่งเซิร์ฟเวอร์ที่ผู้โจมตีแก้ไม่ได้ ผูกสิทธิ์กับเจ้าของข้อมูล และใส่การตรวจสิทธิ์ไว้ในการทดสอบอัตโนมัติ

A03 Software Supply Chain Failures คือความล้มเหลวในกระบวนการสร้าง แจกจ่าย หรืออัปเดตซอฟต์แวร์ มักเกิดจากช่องโหว่หรือการแก้ไขที่เป็นอันตรายในโค้ด เครื่องมือ หรือ dependency ของบุคคลที่สาม หน้าทางการระบุว่าหมวดนี้ได้อันดับ 1 ในผลสำรวจของชุมชน OWASP แนะนำให้สร้างและดูแล SBOM (Software Bill of Materials คือรายการส่วนประกอบทั้งหมดที่อยู่ในซอฟต์แวร์) ลบ dependency ที่ไม่ใช้ รับส่วนประกอบจากแหล่งที่เชื่อถือได้ และป้องกันที่เก็บโค้ด (code repository) กับ pipeline CI/CD (ขั้นตอนอัตโนมัติที่ build และปล่อยซอฟต์แวร์) อ่านต่อได้ที่ SBOM และความปลอดภัยของห่วงโซ่อุปทานซอฟต์แวร์ และ DevSecOps: SAST, DAST และ SCA

A10 Mishandling of Exceptional Conditions เกิดเมื่อซอฟต์แวร์ป้องกัน ตรวจจับ หรือรับมือสถานการณ์ผิดปกติได้ไม่ถูกต้อง หน้าทางการยกตัวอย่าง 3 แบบ แบบแรกคือแอปไม่คืนทรัพยากรหลังเกิดข้อผิดพลาด จนบริการหยุดทำงาน แบบที่สองคือข้อความ error ที่ละเอียดเกินไปจนเผยรายละเอียดภายในระบบ แบบที่สามคือธุรกรรมหลายขั้นตอนที่ถูกขัดจังหวะ แล้วระบบไม่ย้อนกลับ (rollback) ทั้งชุด ซึ่งอาจทำให้เงินสูญหาย

มองจากมุมผู้บริหารและทีมพัฒนา

ผู้บริหารถามทีมได้ 4 ข้อนี้ ซึ่งเป็นข้อเสนอของเราเอง โดยอิงแนวทางของ OWASP ในการสร้างโปรแกรมความปลอดภัยแอปพลิเคชัน:

• แอปและ API ใดสำคัญต่อธุรกิจที่สุด และมีบัญชีรายการครบหรือไม่
• ทีมพัฒนาต้องทำตามมาตรฐานความปลอดภัยใด เช่น ASVS และใครเป็นผู้ตรวจ
• ทีมพัฒนาได้รับการอบรมด้านความปลอดภัยตามบทบาทของตนหรือไม่
• มีตัวชี้วัดที่ติดตามได้หรือไม่ เช่น จำนวนช่องโหว่ที่พบและแก้ไขแล้ว และจำนวนแอปที่ผ่านการทดสอบ

ทีมพัฒนานำหลักป้องกันที่ OWASP ระบุไว้ในแต่ละหมวดไปใช้ได้ทันที ตัวอย่างเช่น:

• ปฏิเสธการเข้าถึงโดยค่าเริ่มต้น และตรวจสิทธิ์ในโค้ดฝั่งเซิร์ฟเวอร์ (A01)
• สร้าง SBOM และลบ dependency ที่ไม่ได้ใช้ (A03)
• จัดการข้อผิดพลาดตรงจุดที่เกิด มีตัวจัดการข้อผิดพลาดส่วนกลาง (global exception handler) และย้อนกลับธุรกรรมที่ทำไม่จบให้ครบทั้งชุด (A10)
• บันทึกการเข้าถึงที่ถูกปฏิเสธ และแจ้งผู้ดูแลเมื่อเกิดซ้ำหลายครั้ง (A01, A09)

WAF (web application firewall คือไฟร์วอลล์ที่กรองคำขอเว็บ) ช่วยกรองคำขออันตรายได้บางแบบ แต่ใช้แทนการแก้โค้ดไม่ได้ เพราะช่องโหว่ในแอปยังอยู่ ดูความต่างของอุปกรณ์แต่ละชนิดได้ที่ NGFW, UTM และ WAF ต่างกันอย่างไร ส่วนความเสี่ยงของช่องทาง API โดยเฉพาะ อ่านที่ API Security และ OWASP API Top 10

ข้อผิดพลาดที่พบบ่อย

• ใช้ Top 10 เป็นรายการตรวจรับที่ครบถ้วน: OWASP ระบุว่าเป็นเพียงเกณฑ์ขั้นต่ำ
• อ้างฉบับ 2021 ในนโยบายหรือสัญญาโดยไม่ตรวจว่ามีฉบับใหม่: ฉบับล่าสุดคือ 2025 และบางหมวดเปลี่ยนไป
• แก้ทีละช่องโหว่ที่สแกนเจอ โดยไม่แก้ที่กระบวนการพัฒนา: ช่องโหว่แบบเดิมจะกลับมาอีก
• คิดว่า WAF หรือไฟร์วอลล์ใช้แทนการแก้โค้ดได้: ช่องโหว่ในแอปยังอยู่
• มองข้าม dependency และระบบ build เพราะโค้ดของทีมเองไม่มีปัญหา: A03 เกิดจากส่วนที่ทีมไม่ได้เขียนเอง

ขั้นแรกที่ทำได้ทันที

• ตรวจว่านโยบาย สัญญา และเครื่องมือสแกนอ้างฉบับ 2021 หรือ 2025
• ทำบัญชีรายการแอปและ API เรียงตามความสำคัญต่อธุรกิจ
• ตรวจการควบคุมสิทธิ์ (A01) ในแอปที่สำคัญที่สุดก่อน
• สร้าง SBOM และรายการ dependency ของแอปเหล่านั้น
• ตั้งตัวชี้วัดที่ผู้บริหารดูได้ เช่น จำนวนช่องโหว่ที่พบและแก้ไขแล้ว

ดูว่าองค์กรอยู่ตรงไหนได้ที่ แบบประเมินตนเอง

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• OWASP Top 10:2025: หน้าหลักของฉบับ 2025 พร้อมรายการ 10 หมวด
• Introduction (2025): สิ่งที่เปลี่ยนจากฉบับ 2021 และที่มาของข้อมูล
• A01:2025 Broken Access Control: คำอธิบายและวิธีป้องกัน A01
• A03:2025 Software Supply Chain Failures: คำอธิบายและวิธีป้องกัน A03
• A10:2025 Mishandling of Exceptional Conditions: คำอธิบายและตัวอย่างของ A10
• Establishing a Modern Application Security Program: แนวทางสร้างโปรแกรมความปลอดภัยแอป และบทบาทของ ASVS
• OWASP Top 10:2021: ฉบับก่อนหน้า สำหรับเทียบกับ 2025
• OWASP Application Security Verification Standard (ASVS): มาตรฐานข้อกำหนดที่ตรวจสอบได้
• OWASP Cheat Sheet Series: แนวปฏิบัติสำหรับนักพัฒนาแยกตามหัวข้อ