OWASP Top 10 in Practice

รายงาน Security จำนวนมากสรุปว่า “ผ่าน OWASP Top 10” หลัง scanner ไม่พบ injection หรือ header ที่ขาด แต่ระบบยังอาจอนุญาตให้ account หนึ่งอ่าน statement ของอีก account หรือ deploy artifact ที่ไม่เคย verify signature ได้ เพราะ OWASP Top 10 ไม่ใช่ test suite และ scanner 1 ชนิด มองไม่เห็น design/business logic ทั้งหมด

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

OWASP Top 10 เป็น awareness document ที่รวบรวมกลุ่มความเสี่ยงสำคัญของ web application เพื่อสร้างภาษากลางและจุดเริ่มต้นของ security program ไม่ใช่:

• รายการช่องโหว่ทั้งหมด
• risk ranking ที่เหมือนกันทุกระบบ
• penetration-test methodology
• verification standard หรือ certification
• หลักฐานว่า scanner ครอบคลุม application

สำหรับ requirement/evidence ใช้ OWASP ASVS 5.0.0 เป็น baseline แล้วเพิ่ม threat model, business invariant และข้อกำกับของระบบจริง

OWASP Top 10:2025#

A01: Broken Access Control#

เกิดเมื่อระบบไม่บังคับว่า subject ทำ action ใดกับ resource/property ใดได้ภายใต้ context ปัจจุบัน

รูปแบบที่พบบ่อย:

• BOLA/IDOR: เปลี่ยน object ID
• เรียก admin function ด้วย user role
• mass assignment เปลี่ยน status, role, tenant_id
• CORS หรือ frontend visibility ถูกใช้แทน authorization
• multi-tenant isolation ขาดใน cache, export หรือ background job
• maker-checker ไม่ตรวจ independent actor/transaction version

control หลักคือ server-side default deny, complete mediation และ policy/test matrix ตาม Authorization ไม่ใช่ UUID ที่เดายาก

A02: Security Misconfiguration#

ระบบและ cloud มี configuration surface จำนวนมาก ค่า default หรือ environment drift จึงเปิดช่องได้:

• debug/metrics/admin endpoint เปิดจาก Internet
• sample account/default credential ยังอยู่
• error แสดง stack trace, secret หรือ internal topology
• CORS/CSP/cache header กว้างเกิน
• bucket/database/network rule เปิด public
• service/feature/plugin ที่ไม่ใช้ยังทำงาน
• production และ non-production ใช้ trust/credential ร่วมกัน

ป้องกันด้วย hardened baseline, Infrastructure as Code, peer review, automated policy checks, inventory, drift detection และ verification ใน environment จริง พร้อม exception ที่หมดอายุ

A03: Software Supply Chain Failures#

หมวดนี้กว้างกว่า dependency ที่มี CVE ครอบคลุม source, maintainer, registry, IDE, CI runner, build script, transitive dependency, container base image, artifact และ deployment

SBOM ช่วย inventory แต่ไม่พิสูจน์ว่า component ปลอดภัย ส่วน signature พิสูจน์ signer/integrity ตาม policy แต่ artifact ที่ signer ตั้งใจสร้างยังอาจมี malicious code ได้

control ต้องเชื่อมกัน:

• protect repository/CI identity และ branch/release policy
• pin/lock dependency และกำหนด trusted source
• isolate build และลด token privilege
• generate SBOM/provenance ผูกกับ artifact digest
• sign และ verify artifact ก่อน deploy
• monitor/adapt เมื่อ dependency หรือ build system compromise

A04: Cryptographic Failures#

failure ไม่ได้มีเพียง algorithm เก่า:

• ใช้ encoding แทน encryption
• encrypt แต่ไม่มี integrity/authentication
• key อยู่ข้าง ciphertext หรือ permission decrypt กว้าง
• nonce/IV reuse
• certificate validation ถูกปิด
• password ใช้ fast hash
• metadata/log/backup ไม่อยู่ใน encryption design
• rotation ทำให้ข้อมูลเก่าเปิดไม่ได้หรือ key compromise ยังใช้ต่อ

เริ่มจาก data classification และ security property แล้วออกแบบ key/protocol lifecycle ตาม Cryptography

A05: Injection#

Injection เกิดเมื่อข้อมูลถูกตีความเป็นส่วนของคำสั่งหรือโปรแกรม:

validation ช่วยจำกัดรูปแบบแต่ไม่แทน parameterized API หรือ context-aware output encoding บทถัดไปจะลงรายละเอียด canonicalization และ sink แต่ละชนิด

A06: Insecure Design#

implementation อาจตรง spec ทุกบรรทัด แต่ spec/design เองไม่รักษา security property เช่น:

• account recovery ใช้ข้อมูลที่หาได้สาธารณะ
• transfer flow ไม่มี idempotency/concurrency invariant
• promotion ไม่มี abuse/velocity limit
• privileged operator คนเดียวสร้าง อนุมัติ และลบ audit ได้
• third-party callback มี signature แต่ไม่มี replay state
• data collection ไม่มี retention/deletion design

scanner ไม่สามารถสรุป design เหล่านี้ได้ ต้องใช้ threat modeling, abuse cases, secure requirements, architecture review และ invariant tests ตั้งแต่ก่อน code

A07: Authentication Failures#

ครอบคลุม identity/session lifecycle ไม่ใช่ password field เท่านั้น:

• credential stuffing/brute force ไม่มี rate control
• password policy อ่อนหรือผลักให้ reuse
• authenticator/recovery อ่อนกว่า login หลัก
• session ID ไม่ rotate หลัง login
• token ตรวจ issuer/audience/type ไม่ครบ
• logout/recovery/password change ไม่ revoke session
• MFA ที่ใช้ยังถูก phishing/relay ได้แต่ถูกอ้างว่า phishing-resistant

ใช้แนวทางจากIdentity, Strong Authentication และ Session Security เป็น lifecycle เดียวกัน

A08: Software or Data Integrity Failures#

หมวดนี้เน้นการเชื่อ software/data ที่ควรมี integrity/provenance control เช่น:

• auto-update รับ package โดยไม่ verify source/signature/policy
• deserialize object ที่ attacker ควบคุมแล้วเกิด side effect
• webhook/event ถูกแก้หรือ replay
• client-controlled field ถูกใช้เป็น approval/price/status truth
• artifact/data migration ไม่มี integrity verification
• cache/replica ส่ง stale state แล้ว operation สำคัญไม่ recheck

Signature ไม่กัน replay โดยตัวมันเอง และ software signing ไม่พิสูจน์ว่า source ปลอดภัย ต้อง verify context, version, identity, freshness และ state invariant ร่วมกัน

A09: Security Logging and Alerting Failures#

การมี log ไม่เท่ากับ detect/respond ได้ Failure อาจเกิดเมื่อ:

• event สำคัญไม่ถูกบันทึกหรือขาด actor/resource/outcome
• log เก็บ token/PII ทำให้เกิด data breach ใหม่
• timestamp/correlation ข้าม service ไม่ได้
• attacker แก้หรือลบ evidence ได้
• alert ไม่มี owner/runbook หรือ noise สูงจนถูกปิด
• retention ไม่พอสำหรับเวลาที่ใช้ตรวจพบ
• response action ไม่มี permission หรือไม่เคยซ้อม

ออกแบบจาก detection use case ย้อนกลับมาหา telemetry แล้วทดสอบ end-to-end ตั้งแต่ event ถึงคน/automation ที่ containment ได้

A10: Mishandling of Exceptional Conditions#

error, timeout และ partial failure เป็นเส้นทาง Security เต็มรูปแบบ:

• policy service timeout แล้ว application allow
• parser error กิน CPU/memory จน DoS
• bank timeout หลัง side effect ทำให้ retry จ่ายซ้ำ
• log/KMS/fraud dependency ล่มแล้ว critical operation เดินต่อโดยไม่มี policy
• exception เปิด stack/secret หรือข้าม cleanup
• malformed third-party response ทำ state ค้าง
• concurrent request ชนะ TOCTOU window

ต้องกำหนด fail/degraded behavior, bounded resource, timeout/retry/idempotency, atomic transition, safe error และ recovery path โดยให้ human owner ตัดสิน trade-off ที่กระทบเงิน/availability

ใช้ Top 10 ให้เกิด Engineering Evidence#

กระบวนการที่เหมาะสม:

1. ใช้ Top 10 สร้าง awareness และตรวจ blind spot ระดับหมวด
2. ใช้ threat model หา risk เฉพาะ architecture/business flow
3. เลือก ASVS 5.0.0 requirements พร้อมระบุ version
4. เพิ่ม domain invariants และ abuse cases
5. map requirement → control → test/evidence → owner
6. บันทึก residual risk/exception ที่มี expiry
7. ส่ง incident/finding กลับไปแก้ requirement และ paved road

ตัวอย่าง mapping:

Review Checklist#

• เอกสาร/รายงานระบุ OWASP Top 10:2025 ไม่ปนรายการปี 2021
• ใช้ Top 10 เป็น awareness ไม่ claim certification/complete coverage
• A01 ครอบคลุม object, function, property และ tenant
• A03 ครอบคลุม source/build/artifact/deploy ไม่ใช่ CVE อย่างเดียว
• A04 ผูก key/protocol/lifecycle ไม่ใช่ชื่อ algorithm อย่างเดียว
• A06 ใช้ threat model/abuse case หา design flaw
• A09 ทดสอบ alert-to-response ไม่ใช่แค่ตรวจว่ามี log
• A10 มี failure/degraded/recovery semantics สำหรับ critical dependency
• ASVS requirement ระบุ version และมี evidence
• business invariant และ residual risk มี owner ที่ชัดเจน

Further Reading#

• OWASP Top 10:2025
• OWASP Top 10:2025 — Modern Application Security Program
• OWASP ASVS 5.0.0