SA-Me.life

เป็นรายการที่จัดทำโดยโครงการ Open Worldwide Application Security Project (OWASP) เพื่อระบุและจัดอันดับความเสี่ยงด้านความปลอดภัยที่สำคัญที่สุดในแอปพลิเคชันเว็บและ API โดยอัปเดตเป็นระยะเพื่อสะท้อนถึงภัยคุกคามที่เปลี่ยนแปลงไ

📡 OWASP API Security Top 10 (2023)

1. 🔓 Broken Object Level Authorization

การอนุญาตระดับวัตถุที่ไม่เหมาะสม
คือ: API ยอมให้ผู้ใช้เข้าถึง/แก้ไข object ที่ไม่ควรเข้าถึง เช่น ข้อมูลของคนอื่น โดยไม่ตรวจสอบ ownership หรือ role

GET /api/v1/users/12345

User A ใช้ token ของตัวเองเรียกดูข้อมูลของ User B (12345) ได้ เพราะ API ไม่ตรวจสอบว่า user A เป็นเจ้าของหรือไม่

✅ ควรทำ: ตรวจสอบ userId หรือ ownerId ทุกครั้งใน backend

2. 🚫 Broken Authentication

การตรวจสอบสิทธิ์ที่ไม่ปลอดภัย
คือ: ระบบมีช่องโหว่ด้าน authentication เช่น JWT ปลอมได้, login ไม่มี rate limit, หรือ token หมดอายุแต่ยังใช้งานได้

ตัวอย่าง:

• ระบบไม่ตรวจสอบ JWT signature
• Token ไม่มี expiration
• Login endpoint ไม่มี rate limit → brute force ได้ง่าย

✅ ควรทำ: ใช้ JWT ที่เซ็นด้วย HMAC256 หรือ RS256 และตั้งเวลา expire ชัดเจน

3. 🧩 Broken Object Property Level Authorization

การอนุญาตระดับคุณสมบัติวัตถุที่ไม่เหมาะสม
คือ: ผู้ใช้สามารถแก้ไขฟิลด์ที่ไม่ควรเข้าถึง เช่น เปลี่ยน role ของตัวเองเป็น admin

ตัวอย่าง:

PATCH /api/v1/users/12345
{
“email”: “hacker@example.com”,
“role”: “admin”
}

✅ ควรทำ: ตรวจสอบทุก field ก่อนอัปเดต และ whitelist เฉพาะ field ที่แก้ไขได้

4. 🧃 Unrestricted Resource Consumption

การใช้ทรัพยากรโดยไม่จำกัด
คือ: API อนุญาตให้ request ใช้ทรัพยากรเกินจำเป็น → DDoS ง่าย เช่นโหลดข้อมูล 100,000 records

ตัวอย่าง:

GET /api/v1/logs?limit=100000

✅ ควรทำ:

• กำหนด rate limit, pagination, และ request size limit
• ใช้ caching + timeout

5. ⚙️ Broken Function Level Authorization

การอนุญาตระดับฟังก์ชันที่ไม่เหมาะสม
คือ: API ยอมให้ user ธรรมดาเรียก endpoint ที่ควรจำกัดแค่ admin

ตัวอย่าง:

DELETE /api/v1/users/99

User ธรรมดา (ไม่ใช่ admin) สามารถลบผู้ใช้อื่นได้ เพราะ backend ไม่ตรวจ role

✅ ควรทำ: เช็ก role หรือ permission ทุก endpoint สำคัญ

6. 🧾 Unrestricted Access to Sensitive Business Flows

การเข้าถึงกระบวนการทางธุรกิจที่ละเอียดอ่อนโดยไม่จำกัด
คือ: ผู้ใช้สามารถเรียกใช้ flow พิเศษที่ควรอยู่หลัง firewall หรือควบคุมพิเศษ เช่น การถอนเงิน, อนุมัติเอกสาร ฯลฯ

ตัวอย่าง:

POST /api/v1/payment/confirm

ไม่มีการ validate ว่า user ได้สิทธิ์หรือสถานะตรงกับ business logic หรือไม่

✅ ควรทำ: ตรวจสอบ logic เฉพาะของ flow + status ก่อนอนุญาตให้ดำเนินการ

7. 🕵️ Server Side Request Forgery (SSRF)

การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์
คือ: API ที่รับ URL หรือ IP แล้วไปเรียกโดยตรง → attacker ใช้เจาะระบบภายใน

ตัวอย่าง:

✅ ควรทำ:

• ปิด internal access (127.0.0.1, metadata IP)
• ใช้ allowlist domain เท่านั้น

8. 🛠 Security Misconfiguration

การกำหนดค่าความปลอดภัยที่ไม่เหมาะสม
คือ: ใช้ default config, เปิด port ไม่จำเป็น, เปิด error message เต็ม

ตัวอย่าง:

• API ส่ง stack trace เมื่อเกิด exception
• CORS policy อนุญาต * (เปิดหมดทุก domain)

✅ ควรทำ:

• ปิด debug mode บน production
• ตรวจ audit log และตรวจ config เป็นประจำ

9. 📦 Improper Inventory Management¹

การจัดการสิค้าคงคลัง API ไม่เหมาะสม
คือ: API ที่ deploy ไว้แต่ไม่มีคนดูแล → เก่า, ล้าสมัย, เปราะบาง

ตัวอย่าง:

• /api/v1/test/debug ยังเปิดอยู่ใน production
• API ไม่มี documentation / version control

✅ ควรทำ:

มี inventory API ที่ชัดเจน

ใช้ API Gateway หรือ Service Discovery

10. ☠️ Unsafe Consumption of APIs

การใช้ API อย่างไม่ปลอดภัย
คือ: API เชื่อถือข้อมูลจากภายนอกมากเกินไป เช่น 3rd party API โดยไม่ validate response

ตัวอย่าง:

• API ตอบกลับ status 200 แต่ส่ง payload อันตราย → โค้ด frontend เชื่อทันที
• เชื่อ JSON structure โดยไม่ตรวจ field

✅ ควรทำ:

• Sanitize และ validate response จาก external source
• ใส่ fallback / timeout / schema check