OWASP Top 10:2025 ฉบับเข้าใจง่ายสำหรับมือใหม่

ตอนเริ่มเขียนเว็บแรกๆ เราคิดแค่ว่า “ขอให้มันทำงานได้ก่อน” ใช่ไหม? ฟอร์มส่งข้อมูลได้ ล็อกอินผ่าน ดึงข้อมูลจากดาต้าเบสมาโชว์ได้ จบ แฮปปี้ แต่พอทำไปเรื่อยๆ ก็เริ่มมีคำถามตามมา “เอ๊ะ แล้วถ้ามีคนแอบยิงข้อมูลแปลกๆ เข้ามาล่ะ?” “ถ้ามีคนเดา URL แล้วเข้าถึงข้อมูลคนอื่นได้ จะเป็นยังไง?”

คำถามพวกนี้แหละคือจุดเริ่มต้นของเรื่อง ความปลอดภัยเว็บ (Web Security) และมีเอกสารตัวหนึ่งที่รวบรวมคำตอบไว้ให้แบบเป็นระบบ นั่นคือ OWASP Top 10

OWASP Top 10 คืออะไร?

OWASP (Open Worldwide Application Security Project) เป็นองค์กรไม่แสวงหากำไรที่ทำเรื่องความปลอดภัยของซอฟต์แวร์มานานมาก และของขึ้นชื่อที่สุดของเขาคือเอกสารชื่อ Top 10 เป็นลิสต์ที่บอกว่า “10 ความเสี่ยงด้านความปลอดภัยที่เจอบ่อยและอันตรายที่สุดสำหรับเว็บแอป มีอะไรบ้าง”

มองง่ายๆ มันเหมือน “เช็กลิสต์รวมจุดที่เว็บมักจะพังด้านความปลอดภัย” ที่เดฟทั่วโลกใช้เป็นมาตรฐานอ้างอิงกัน ไม่ใช่กฎหมาย ไม่ใช่ใบรับรอง แต่เป็นเหมือนคู่มือเตือนสติว่า “อย่าลืมดูตรงนี้นะ”

จุดที่ทำให้ลิสต์นี้น่าเชื่อถือคือมันไม่ได้นั่งเทียนเดา แต่มาจากการเก็บข้อมูลจริง รอบปี 2025 นี้ OWASP วิเคราะห์จากแอปพลิเคชันกว่า 2.8 ล้านตัว และไล่ดูข้อมูลช่องโหว่ (CVE) ราวๆ 175,000 รายการ แล้วค่อยจัดกลุ่มออกมาเป็น 10 หมวด

ทำไมเดฟทุกคนควรรู้?

ถ้าคุณคิดว่า “ผมแค่เขียน frontend / ผมทำแค่เว็บเล็กๆ คงไม่โดนหรอก” อันนี้ต้องบอกตรงๆ ว่าเป็นกับดักความคิดที่อันตราย เพราะบอทสแกนหาช่องโหว่มันไม่ได้เลือกว่าเว็บคุณใหญ่หรือเล็ก มันยิงทุกอย่างที่เจอ

เวลาเราปล่อยเรื่องความปลอดภัยไว้ทีหลังเนี่ย ความรู้สึกมันประมาณนี้แหละ นั่งบอกตัวเองว่า “ไม่เป็นไรหรอก” ทั้งที่รอบตัวเริ่มไฟลุกแล้ว

ข้อดีของการรู้ Top 10 คือมันทำให้เรา คิดเผื่อ ตั้งแต่ตอนเขียนโค้ด ไม่ใช่ไปไล่แก้ทีหลังตอนโดนแฮ็กแล้ว และพูดตามตรง พอเข้าใจหลักการพวกนี้ โค้ดเราจะดูเป็นมืออาชีพขึ้นเยอะเลย

มีอะไรใหม่ในเวอร์ชัน 2025?

ลิสต์นี้ไม่ได้อยู่นิ่งๆ เขาอัปเดตทุกๆ ไม่กี่ปีตามภัยที่เปลี่ยนไป เวอร์ชัน 2025 (ออกปลายปี 2025 ต่อต้นปี 2026) มาแทนเวอร์ชัน 2021 เก่า โดยมีของใหม่ที่น่าสนใจคือ

• มี 2 หมวดใหม่ถอดด้าม คือ Software Supply Chain Failures (ความเสี่ยงจากซอฟต์แวร์/ไลบรารีที่เราเอามาใช้) และ Mishandling of Exceptional Conditions (การจัดการ error/กรณีพิเศษพลาด)
• SSRF ถูกยุบรวม เข้าไปอยู่ในหมวด Broken Access Control แล้ว
• หลายหมวด เปลี่ยนชื่อและสลับอันดับ เช่น Security Misconfiguration เด้งจากอันดับ 5 ขึ้นมาอันดับ 2

เอาล่ะ มาดูทีละข้อกัน ขอเล่าแบบภาษาคน ไม่ใช่ศัพท์เทคนิคล้วนๆ

ความเสี่ยงทั้ง 10 ข้อ ฉบับเข้าใจง่าย

A01 Broken Access Control (การควบคุมสิทธิ์การเข้าถึงพัง)

แชมป์เก่ายังครองอันดับ 1 เหมือนเดิม ปัญหานี้คือ “ผู้ใช้ทำในสิ่งที่ไม่ควรมีสิทธิ์ทำได้” เช่น user ธรรมดาเปลี่ยน URL จาก /orders/123 เป็น /orders/124 แล้วเห็นออเดอร์ของคนอื่นเลย หรือเรียก API admin ได้ทั้งที่ไม่ใช่แอดมิน บทเรียนสั้นๆ คือ อย่าเชื่อ user ต้องเช็กสิทธิ์ที่ฝั่ง server ทุกครั้ง ไม่ใช่แค่ซ่อนปุ่มใน UI อ่านรายละเอียดที่หน้าทางการ

หน้าตาของแต่ละหมวดบน owasp.org จะประมาณนี้ มีทั้งสถิติ คำอธิบาย ตัวอย่างการโจมตีจริง และวิธีป้องกัน อ่านไม่ยากอย่างที่คิด

A02 Security Misconfiguration (ตั้งค่าความปลอดภัยผิด)

ขึ้นมาแรงจากอันดับ 5 เป็นอันดับ 2 อันนี้คือเรื่องของ “ลืมตั้งค่า” หรือ “ใช้ค่า default” เช่น เปิดหน้า debug ทิ้งไว้บน production, ใช้รหัสผ่าน admin/admin ที่มากับระบบ, หรือเผลอเปิด permission ของ cloud storage เป็น public ทั้งถัง ของพวกนี้แฮ็กไม่ยากเลยเพราะมันเปิดประตูทิ้งไว้เอง ดูเพิ่มเติม

A03 Software Supply Chain Failures (ห่วงโซ่ซอฟต์แวร์มีปัญหา) หมวดใหม่

นี่คือหมวดน้องใหม่ที่สำคัญมากในยุคนี้ สมัยนี้เราแทบไม่ได้เขียนทุกอย่างเอง เรา npm install กันรัวๆ ใช้ไลบรารีคนอื่นเป็นร้อยตัว แล้วถ้าไลบรารีตัวใดตัวหนึ่งโดนฝังโค้ดร้ายล่ะ? เว็บเราก็พังไปด้วยทั้งที่โค้ดเราไม่ได้ผิดอะไรเลย หมวดนี้เตือนให้ระวังของที่เราหยิบมาใช้ ทั้ง dependency, build tool, ไปจนถึง CI/CD อ่านที่นี่

A04 Cryptographic Failures (การเข้ารหัสล้มเหลว)

เรื่องของการปกป้องข้อมูลสำคัญ เช่น รหัสผ่าน เลขบัตร ข้อมูลส่วนตัว ถ้าเก็บรหัสผ่านเป็น plain text (ตัวอักษรธรรมดาอ่านออก) หรือใช้วิธีเข้ารหัสเก่าๆ ที่ถอดได้ง่าย พอดาต้าเบสหลุดขึ้นมาก็จบเลย หลักง่ายๆ คือข้อมูลอ่อนไหวต้อง เข้ารหัสทั้งตอนส่งและตอนเก็บ และใช้วิธี hash รหัสผ่านที่ทันสมัย รายละเอียด

A05 Injection (การฉีดโค้ด)

ตำนานที่อยู่ในลิสต์มาตลอด เกิดจากการที่เราเอา input ของ user ไปยัดในคำสั่งโดยตรงโดยไม่กรอง ที่ดังสุดคือ SQL Injection user พิมพ์โค้ด SQL ลงในช่องค้นหาแล้วมันถูกรันจริง ทางแก้คลาสสิกคือใช้ parameterized query อย่าเอา string มาต่อกันตรงๆ

// อย่าทำแบบนี้ เปิดช่องให้ injection
db.query("SELECT * FROM users WHERE email = '" + email + "'");

// ทำแบบนี้ ปลอดภัยกว่าเยอะ
db.query("SELECT * FROM users WHERE email = ?", [email]);

อ่านต่อ

A06 Insecure Design (ออกแบบไม่ปลอดภัยตั้งแต่แรก)

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

A07 Authentication Failures (ระบบยืนยันตัวตนพลาด)

เรื่องของ “การพิสูจน์ว่าคุณคือคุณจริงๆ” ถ้าระบบล็อกอินอ่อนแอ เช่น ยอมให้ลองรหัสผ่านกี่ครั้งก็ได้ (เปิดช่อง brute force), ปล่อยให้ใช้รหัสง่ายๆ อย่าง 123456, หรือจัดการ session ไม่ดี ก็จะโดนสวมรอยได้ง่าย ยุคนี้ควรมี MFA (ยืนยันตัวตนหลายชั้น) และจำกัดจำนวนครั้งที่ลองล็อกอินผิด อ่านที่นี่

A08 Software or Data Integrity Failures (ความถูกต้องของซอฟต์แวร์/ข้อมูลพัง)

ข้อนี้เกี่ยวกับการ “เชื่อใจของที่ไม่ได้ตรวจสอบ” เช่น โหลดอัปเดตซอฟต์แวร์มาจากแหล่งที่ไม่ได้เซ็นรับรอง หรือดึงสคริปต์จาก CDN ภายนอกโดยไม่เช็กว่าไฟล์ถูกแก้ไขมาหรือเปล่า ถ้าตัวกลางถูกแฮ็ก ของที่เราโหลดมาก็อาจมีของแถมที่เราไม่ต้องการ รายละเอียด

A09 Security Logging and Alerting Failures (บันทึกและแจ้งเตือนไม่ดีพอ)

ลองนึกภาพบ้านโดนงัดแต่ไม่มีกล้องวงจรปิดเลย นั่นแหละข้อนี้ ถ้าระบบไม่เก็บ log เหตุการณ์สำคัญ หรือเก็บแต่ไม่มีใครคอยดู/แจ้งเตือน พอโดนโจมตีก็จะไม่รู้ตัว กว่าจะรู้ก็สายไปแล้ว เวอร์ชัน 2025 เน้นคำว่า “Alerting” เข้ามาด้วย เพราะแค่เก็บ log เฉยๆ ไม่พอ ต้องเตือนให้ทันด้วย ดูเพิ่มเติม

A10 Mishandling of Exceptional Conditions (จัดการกรณีพิเศษพลาด) หมวดใหม่

อีกหนึ่งหมวดน้องใหม่ของปี 2025 พูดถึงตอนที่ระบบเจอสถานการณ์ที่ไม่คาดคิด เช่น error, input แปลกๆ, หรือเงื่อนไขที่ลืมคิดถึง แล้ว “จัดการมันแบบพลาดๆ” เช่น error message โชว์รายละเอียดภายในระบบให้คนนอกเห็น (พวก stack trace เต็มๆ) หรือพอเจอ error แล้วโปรแกรมดันไปทำงานต่อในสถานะที่ไม่ปลอดภัย หลักคือควรจัดการ error ให้เรียบร้อยและไม่เผยข้อมูลเกินจำเป็น อ่านที่นี่

แล้วจะเริ่มยังไงดี?

ไม่ต้องกดดันตัวเองว่าต้องทำให้ครบทุกข้อในวันเดียว ลองทำแบบนี้

1. อ่านผ่านทั้ง 10 ข้อให้พอเห็นภาพ แค่รู้ว่ามีอะไรบ้างก็ช่วยได้เยอะ
2. เริ่มจากข้อที่ใกล้ตัวที่สุด ถ้าเขียน backend ที่ต่อดาต้าเบส ก็เริ่มจาก Injection กับ Access Control ก่อน
3. ลองเล่นของจริง อ่านอย่างเดียวมันไม่ติด ต้องลงมือเจาะดูเอง

ฝึกมือกับ OWASP Juice Shop

ข้อ 3 ขอแยกมาเล่าหน่อยเพราะมันสนุกมาก OWASP มีโปรเจกต์ชื่อ Juice Shop เป็นเว็บร้านขายน้ำผลไม้ปลอมๆ ที่ “จงใจยัดช่องโหว่” เอาไว้เต็มไปหมด ตั้งแต่ระดับง่ายๆ ไปจนถึงโหดมาก ให้เราเข้าไปลองหาและเจาะเล่นได้แบบ ถูกกฎหมาย (เพราะมันเป็นเว็บฝึกของเราเอง ไม่ได้ไปยุ่งกับเว็บคนอื่น)

ดีตรงที่ช่องโหว่ในนั้นล้อกับ OWASP Top 10 เป๊ะๆ เจอ SQL Injection จริง เจอ Broken Access Control จริง พอเจาะผ่านแต่ละด่านมันมีระบบให้คะแนนเหมือนเล่นเกม ทำให้เราเข้าใจว่า “อ๋อ ช่องโหว่ข้อนี้มันถูกใช้งานจริงแบบนี้นี่เอง” ซึ่งมันคนละเรื่องกับการอ่านทฤษฎีเฉยๆ เลย รันบนเครื่องตัวเองได้ผ่าน Docker คำสั่งเดียว แนะนำให้ลองจริงๆ

อยากเริ่มอ่านฉบับเต็ม เข้าไปที่ owasp.org/Top10/2025 ได้เลย แต่ละหมวดมีตัวอย่างและวิธีป้องกันละเอียดกว่านี้เยอะ

ขอแชร์ตามตรงในมุมของเรานะ เราเองก็เพิ่งมาเริ่มสนใจเรื่องนี้แบบจริงจังเมื่อไม่นานมานี้เอง ก่อนหน้านั้นคำว่า “OWASP” เป็นแค่ชื่อที่ได้ยินผ่านๆ ในคลิป ในบทความ แล้วก็เลื่อนผ่านไปเพราะรู้สึกว่า “เดี๋ยวค่อยอ่านก็ได้” หรือ “มันคงเป็นเรื่องของสาย security เขา” พอได้มานั่งอ่านจริงๆ ถึงรู้สึกเสียดายที่ไม่ได้แตะมันตั้งแต่แรก

และตอนแรกที่เห็นคำว่า “OWASP Top 10” เราก็รู้สึกว่ามันดูซีเรียสและน่ากลัวมาก เหมือนเป็นเรื่องของ security engineer เท่านั้น แต่พอลองเปิดไล่อ่านเองดู กลับพบว่ามันคือสามัญสำนึกที่เดฟทุกคนควรมีติดตัว หลายข้อพอรู้แล้วจะแบบ “อ๋อ มันก็แค่นี้เอง” และมันเปลี่ยนวิธีคิดเวลาเขียนโค้ดของเราไปเลย จากที่เคยถามแค่ “มันทำงานไหม” กลายเป็นถามต่อว่า “แล้วถ้ามีคนตั้งใจใช้มันผิดวิธีล่ะ”

และคำถามหลังนี่แหละ คือเส้นที่แยกโค้ดเล่นๆ ออกจากโค้ดที่เอาไปใช้งานจริง ใครที่ยังลังเลแบบเราเมื่อก่อน ลองเริ่มวันนี้เลย ไม่สายหรอก