บทความ 13

ออกแบบ Security สำหรับ Web, Mobile และ API ก่อนเปิด Production

อธิบาย Authentication, Authorization, Token, Session, TLS, Input Validation, Rate Limit, Secret, Mobile Storage และ Logging ตั้งแต่พื้นฐาน พร้อมตัวอย่างช่องโหว่ที่เกิดเมื่อ API เชื่อผู้ใช้มากเกินไป

21 นาที Product Owner, Developer, Mobile Developer, QA และ Tech Lead 2026-07-17

Infographic ภาพรวม

Browser

Mobile

APIAuth · Limit

Application

Database

จุดที่มักเข้าใจผิด

ลองเริ่มจากเหตุการณ์ที่คนทำงานพบจริง

ซ่อนปุ่มในหน้าจอไม่ได้แปลว่า API ปฏิเสธการกระทำนั้น

Web และ Mobile เป็น client ที่ผู้ใช้ควบคุมได้ เขาเปิด Developer Tools, ดัก request, เปลี่ยนค่า หรือใช้โปรแกรมอื่นเรียก API โดยไม่ผ่านหน้าจอได้ ดังนั้นข้อมูลจาก client ทุกอย่างต้องถือว่ายังไม่น่าเชื่อถือ Server ต้องตรวจตัวตน สิทธิ์ รูปแบบข้อมูล และเงื่อนไขธุรกิจใหม่ทุกครั้ง เช่น ผู้ใช้แก้ orderId ใน URL ไม่ควรอ่านใบสั่งซื้อของคนอื่นได้ แม้เขาจะ login ถูกต้องแล้วก็ตาม

คำที่คุณจะเจอในบทความ

แต่ละคำหมายถึงอะไร และเกี่ยวข้องกับระบบตรงไหน

ไม่ต้องจำทั้งหมดในครั้งเดียว อ่านเพื่อให้รู้หน้าที่คร่าว ๆ ก่อน แล้วค่อยกลับมาเทียบเมื่อเจอคำนั้นในเนื้อหา

Authentication: กระบวนการพิสูจน์ตัวตน เช่น password + MFA, passkey หรือ SSO
Authorization: การตัดสินว่าตัวตนนั้นมีสิทธิ์ทำ action กับ resource ที่ระบุหรือไม่
Session: สถานะฝั่ง Server ที่ผูกการใช้งานต่อเนื่องกับผู้ใช้ มักอ้างผ่าน cookie แบบสุ่ม
Access Token: หลักฐานอายุสั้นที่ client ส่งให้ API เพื่อแสดงสิทธิ์ที่ได้รับ ไม่ใช่รหัสผ่านและไม่ควรเก็บถาวร
BOLA / IDOR: ช่องโหว่ที่ API ตรวจว่า login แล้ว แต่ไม่ตรวจว่าผู้ใช้เป็นเจ้าของหรือมีสิทธิ์กับ object ID ที่ร้องขอ
Input Validation: การตรวจชนิด ขนาด รูปแบบ ช่วงค่า และกติกาธุรกิจของข้อมูลก่อนนำไปใช้
CORS: นโยบายของ Browser ว่า JavaScript จาก origin ใดอ่าน response ได้ ไม่ใช่ระบบยืนยันตัวตนและไม่ป้องกัน Mobile App
Threat Model: การระบุสิ่งที่ต้องป้องกัน ผู้ที่อาจโจมตี ช่องทาง และ control ที่ใช้ลดความเสี่ยง

ถ้าคุณไม่ได้ทำงานสายเทคนิค ให้เริ่มจากส่วนนี้

ออกแบบ Security สำหรับ Web, Mobile และ API ก่อนเปิด Production

Authentication ตอบว่าเป็นใคร ส่วน Authorization ตอบว่าคนนี้ทำสิ่งนี้กับข้อมูลชิ้นนี้ได้หรือไม่ ต้องมีทั้งคู่

Mobile App และ JavaScript ไม่สามารถเก็บ Secret ของบริษัทแบบลับถาวรได้ เพราะผู้ใช้ครอบครองตัวโปรแกรม

API ต้อง validate input, จำกัด request, ป้องกัน object-level authorization และไม่ส่งข้อมูลเกินจำเป็น

Security ต้องอยู่ใน design, code review, automated test, dependency scan, penetration test และ monitoring ตลอดวงจร

ภาพขยายความแบบเคลื่อนไหว

ดูความสัมพันธ์ของแต่ละขั้น ก่อนลงรายละเอียด

เลือกแต่ละขั้นเพื่อดูว่าเกิดอะไรขึ้น ต้องตรวจข้อมูลใด และผลจากขั้นหนึ่งส่งต่อไปยังขั้นถัดไปอย่างไร

ขั้น 01 / 06

01 / รู้ว่าเชื่ออะไรได้

ถือว่า Browser และ Mobile App เป็นเครือข่ายภายนอก แม้เป็น App ของเราเอง

โค้ดฝั่ง client ถูกดูและแก้พฤติกรรมได้ จึงห้ามฝัง database password, private API key หรือกฎที่สำคัญไว้เฉพาะหน้าจอ Client validation ช่วยประสบการณ์ผู้ใช้ แต่ Server validation เป็นผู้บังคับจริง วาด data flow ว่าข้อมูลเดินจากผู้ใช้ผ่าน API ไป database และ third party ใดบ้าง ทำเครื่องหมายจุดที่ข้าม trust boundary แล้วถามเรื่อง spoofing, tampering, data disclosure, denial of service และการปฏิเสธความรับผิดในแต่ละจุด

รายละเอียดเชิงลึก

ค่อย ๆ ดูทีละส่วนว่าเกิดอะไรขึ้น และควรเตรียมอย่างไร

เราเริ่มจากผลที่คนใช้งานหรือธุรกิจจะพบ แล้วจึงอธิบายว่าทีมเทคนิคต้องตรวจอะไร มีตัวอย่างแบบไหน และจุดใดไม่ควรปล่อยให้เดาเอง

01 / รู้ว่าเชื่ออะไรได้

ถือว่า Browser และ Mobile App เป็นเครือข่ายภายนอก แม้เป็น App ของเราเอง

02 / ตัวตนและสิทธิ์

Login สำเร็จเป็นเพียงจุดเริ่มต้น ทุก request ยังต้องตรวจสิทธิ์ต่อ resource

Authentication ควรใช้บริการหรือ protocol ที่พิสูจน์แล้ว เช่น OIDC/OAuth 2.0 ตาม use case, รองรับ MFA สำหรับความเสี่ยงสูง และป้องกัน brute force หลัง login ให้ Server ตรวจ role, permission, tenant และ ownership จากข้อมูลที่เชื่อถือได้ ไม่รับ userId หรือ role จาก client มาเชื่อตรง ๆ หากใช้ token ให้มีอายุสั้น ระบุ audience/issuer และวาง refresh/revocation; หากใช้ cookie session ให้ตั้ง HttpOnly, Secure, SameSite และป้องกัน CSRF ตามรูปแบบการใช้งาน

BOLA example

GET /orders/8421

อย่าตรวจแค่ว่า request มี token ให้ query ด้วย tenant/user จาก session แล้วตอบเฉพาะ order ที่ caller มีสิทธิ์ หากไม่พบหรือไม่มีสิทธิ์ให้ตอบแบบไม่เปิดเผยว่าข้อมูลนั้นมีอยู่

03 / ข้อมูลเข้าและออก

กำหนด schema, ขนาด และ business rule พร้อมตอบข้อมูลเท่าที่จำเป็น

กำหนด request/response contract ด้วย schema ตรวจ type, enum, length, file type, file size และค่าที่สัมพันธ์กัน ใช้ parameterized query หรือ ORM อย่างถูกต้องเพื่อลด injection และ encode output ตามบริบท ห้ามส่ง database model ทั้งก้อนเพราะอาจมี field ภายในหลุดมา เช่น password hash, cost หรือ internal note สำหรับ upload ให้เปลี่ยนชื่อไฟล์ ตรวจ content จริง เก็บนอก web root และสแกน malware ตามความเสี่ยง Error response ไม่ควรส่ง stack trace, SQL หรือ secret แต่ต้องมี error code/request ID ที่ support ใช้ตามหา log ได้

04 / ป้องกันการใช้เกิน

Rate Limit ต้องมองทั้ง IP, บัญชี, API key และต้นทุนของ operation

การจำกัดต่อ IP อย่างเดียวทำร้ายผู้ใช้หลัง NAT และหลบได้ด้วย botnet ควรมีหลายชั้น เช่น ต่อ account สำหรับ login, ต่อ API key สำหรับ partner, ต่อ resource สำหรับงานสร้าง report และเพดานรวมเพื่อป้องกันระบบ ใช้ timeout, request body limit, pagination และ queue สำหรับงานหนัก พร้อม idempotency key ใน operation ที่ client อาจ retry การตอบ 429 ควรบอกเวลาลองใหม่อย่างเหมาะสม และ alert เมื่อ pattern เปลี่ยนโดยไม่ log token หรือข้อมูลส่วนบุคคลเกินจำเป็น

05 / เก็บข้อมูลฝั่ง Client

เลือกที่เก็บ Token ตามภัยคุกคาม และอย่าถือว่า Mobile App ซ่อน Secret ได้

Web ที่ใช้ same-origin มักได้ประโยชน์จาก HttpOnly secure session cookie เพราะ JavaScript อ่านไม่ได้ แต่ต้องจัดการ CSRF และ XSS ส่วน Mobile ควรเก็บ credential ใน Keychain/Keystore ใช้ token อายุสั้น และไม่บันทึกลง log, clipboard หรือ backup โดยไม่ตั้งใจ Certificate pinning อาจช่วยบาง threat model แต่มีความเสี่ยงทำ App ใช้งานไม่ได้เมื่อหมุน Certificate จึงต้องมีแผนสำรอง Public API key ที่ติดมากับ App ให้ถือว่าค้นพบได้และจำกัดสิทธิ์/โดเมน/โควตา ห้ามใช้เป็นหลักฐานว่า request มาจาก App จริงเพียงอย่างเดียว

06 / ตรวจตลอดวงจร

Security Review ครั้งเดียวก่อน Go-live ไม่ทันกับโค้ดและช่องโหว่ที่เปลี่ยนทุกวัน

กำหนด secure coding standard และ abuse case ตั้งแต่ refinement ทำ peer review ในส่วนสิทธิ์และข้อมูลสำคัญ ใช้ SAST, dependency/SCA, secret scan, container scan และ IaC scan ใน pipeline พร้อมนโยบายจัดการผลที่พบ ทำ DAST/API test และ mobile test ตาม OWASP ASVS, API Security Top 10 และ MASVS ที่เหมาะสม ก่อน release สำคัญทำ penetration test โดยผู้ทดสอบที่เข้าใจ business logic หลังเปิดใช้ต้อง monitor authentication anomaly, access denied, rate-limit event และ dependency advisory พร้อมกำหนด SLA การ patch ตามความรุนแรง

ก่อนนำไปใช้ ลองตรวจทีละข้อนี้

ทำ Data flow และ threat model

แยก Authentication กับ Authorization

ตรวจ tenant/owner ทุก object

ใช้ TLS ทุกเส้นทาง

กำหนด request/response schema

จำกัดขนาด upload และ request

ตั้ง rate limit หลายมิติ

ใช้ token/session อายุเหมาะสม

ไม่ฝัง private secret ใน Web/Mobile

mask ข้อมูลสำคัญใน log

สแกน code/dependency/secret/IaC